From serb at openjdk.org  Sun Jan  1 05:01:53 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 1 Jan 2023 05:01:53 GMT
Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException
 [v6]
In-Reply-To: <KT4cRLlj5JPnlQwPm0xJerUnna5m1l7bmcC8e88x6lY=.4ea68de6-1e62-41cf-b9a7-8d225e3e15aa@github.com>
References: <ABJ79VQJ9Z_V9wB6JJTykhwJlGXac6aKHoe0Tdc5PNI=.bba61627-c1bc-40b0-a039-ac1bf918d22c@github.com>
 <KT4cRLlj5JPnlQwPm0xJerUnna5m1l7bmcC8e88x6lY=.4ea68de6-1e62-41cf-b9a7-8d225e3e15aa@github.com>
Message-ID: <tBMvPyGsM5IPirOzKLGfT09Q3NlJHns7KHI7-AnCirY=.e8ee5b22-86a4-4e34-be84-dd5c31d50062@github.com>

On Tue, 22 Nov 2022 14:31:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If getDefaultEditor() is called before the JTable model is setup, it results in NPE.
>> 
>> This is because when JTable sets its model, which ends up firing a table changed event. The testcase is listening for tableChanged events and querying the editor. But the editor isn't installed until after the model is set which results in NPE.
>> Fix is to ensure initializeLocalVars() which initializes default editor is setup before JTable sets its model.
>> 
>> No regression is observed in jtreg/jck testsuite with this change.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.org  Sun Jan  1 05:02:49 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 1 Jan 2023 05:02:49 GMT
Subject: RFR: 8298449: Unnecessary Vector usage in
 MetaData.ProxyPersistenceDelegate
In-Reply-To: <EuE_osZPhPoAjRSX6B_WMCzdf6NwjBARBLitLQIgeEQ=.37af7798-a198-4e7f-b5d5-4e6427b2057b@github.com>
References: <EuE_osZPhPoAjRSX6B_WMCzdf6NwjBARBLitLQIgeEQ=.37af7798-a198-4e7f-b5d5-4e6427b2057b@github.com>
Message-ID: <rAQQJvgQb-UGROyt5Ci-O_VxBDFmqvs-UMR3jpDxacM=.de20cf4d-2a0b-44fc-a1cf-fcb8a355629d@github.com>

On Fri, 11 Nov 2022 07:00:52 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Vector<Object> args` is used only in single method and then it converted to `Object[]`.
> So we can avoid usage of legacy synchronized `Vector` here and use `ArrayList` instead.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.org  Sun Jan  1 05:20:51 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 1 Jan 2023 05:20:51 GMT
Subject: RFR: 8298447: Unnecessary Vector usage in DocPrintJob
 implementations
In-Reply-To: <JJ3LrpITZ7EaKjvUzOZH0s-dlR9JjZ02glhUVEWFrp8=.17a11333-83c9-4a52-a0e7-30052ecbebb6@github.com>
References: <JJ3LrpITZ7EaKjvUzOZH0s-dlR9JjZ02glhUVEWFrp8=.17a11333-83c9-4a52-a0e7-30052ecbebb6@github.com>
Message-ID: <J1zKzIIg2_eVIjShhrdCjj4s_XDmsehDntYBZFSkhEs=.70ea2339-6001-45ac-8352-954340d5a596@github.com>

On Mon, 5 Dec 2022 08:23:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There are 3 implementations of javax.print.DocPrintJob in the JDK (It seems they were copy-pasted from each other):
> 1. PSStreamPrintJob
> 2. UnixPrintJob
> 3. Win32PrintJob
> 
> They have Vector fields 'jobListeners', 'attrListeners', 'listenedAttributeSets', but they are always accessed only under synchronized(this) blocks. It means we can safely replace them with ArrayList.
> 
> BTW. 'attrListeners' and 'listenedAttributeSets' seems unused.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.org  Sun Jan  1 05:24:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 1 Jan 2023 05:24:50 GMT
Subject: RFR: 8298921: Create a regression test for JDK-8139581
In-Reply-To: <lkasNa1F7wgDFUbBBlSzzve1p3DmJHqmyV6ELZd_BQs=.51d1cbf0-3c97-40d4-8892-d6c214674d94@github.com>
References: <lkasNa1F7wgDFUbBBlSzzve1p3DmJHqmyV6ELZd_BQs=.51d1cbf0-3c97-40d4-8892-d6c214674d94@github.com>
Message-ID: <v0a4AeUCwqFLTYM1DvG0_vWlK5NrLrFTlDdPO3lrW2k=.a3ce9235-a101-4df2-a606-32b64b022e57@github.com>

On Fri, 16 Dec 2022 10:21:35 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create a regression test for JDK-8139581
> 
> As described in JDK-8139581, when an AWT panel with AWT components, for example "java.awt.Button", is removed from AWT frame and added again to the same frame, then some AWT components contained in the panel are not drawn, however, clicking in the area of not drawn button leads to drawing of the button.
> 
> Test has a swing and awt component in a panel. It then removes and adds back the panel from/into the frame, to verify that they are repainted back properly.

test/jdk/java/awt/Component/ComponentRedrawnTest.java line 163:

> 161:             });
> 162:         } catch (Exception e) {
> 163:             e.printStackTrace();

It is better to rethrow this exception and do not skip it, since the later part of the code will not make any sense after this exception.

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

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


From duke at openjdk.org  Mon Jan  2 04:41:15 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Mon, 2 Jan 2023 04:41:15 GMT
Subject: RFR: 8299296: Write a test to verify the components selection
 sends ItemEvent [v2]
In-Reply-To: <0HgEcWPfdikEgz9Qiq5C579YlTEaZ6-UG4wWXS0p7oA=.73a00672-386c-4a78-8bf6-619598a23dbd@github.com>
References: <0HgEcWPfdikEgz9Qiq5C579YlTEaZ6-UG4wWXS0p7oA=.73a00672-386c-4a78-8bf6-619598a23dbd@github.com>
Message-ID: <G_5l1dW0jkTapR5OVHV5VZeDRbAiHW41a2plRl12rRo=.6daebb72-9cc1-44c8-97fa-536068f5deae@github.com>

> This testcase verifies the following assertions
> 
> a. Selecting an item in the Choice using mouse generates ItemEvent.
> b. Single-click on an Checkbox generates ItemEvent.
> 
> 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:

  8299296: Review Fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11786/files
  - new: https://git.openjdk.org/jdk/pull/11786/files/0f436cad..e02b3d27

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

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

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


From abhiscxk at openjdk.org  Mon Jan  2 06:07:00 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 2 Jan 2023 06:07:00 GMT
Subject: Integrated: 4912623: GTK L&F: Folder list of the JFileChooser is
 allowing multiple selection unlike native
In-Reply-To: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
Message-ID: <viQrIVnu8KSPJpAwuo3AZi_B7TTgMtv1zofYwFNMPh8=.8bc1d13c-86f9-44a9-9ce0-e5355f35b7ac@github.com>

On Mon, 12 Dec 2022 05:56:38 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> It is not possible to select all files on press of Ctrl+A in JFileChooser for GTK LAF where as all folders can be selected. 
> In native side on press of Ctrl+A, able to select all files as well as folders.
> 
> Proposed fix is to enable `multiselection `property by default for JFileChooser in GTK LAF to mimic native side behavior.
> 
> An automated test case is implemented and tested in CI. CI job links are attached in JBS.

This pull request has now been integrated.

Changeset: 2ee34f14
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ee34f14880cccca02e2933f80b000979f33c6d1
Stats:     230 lines in 2 files changed: 230 ins; 0 del; 0 mod

4912623: GTK L&F: Folder list of the JFileChooser is allowing multiple selection unlike native

Reviewed-by: psadhukhan, jdv, serb

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

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


From serb at openjdk.org  Mon Jan  2 07:59:28 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 2 Jan 2023 07:59:28 GMT
Subject: RFR: 8299430: Cleanup: delete unnecessary semicolons in java.desktop
 module
Message-ID: <P8_b3ITMyyrFNPDjlKT0aLGCrR4OJTRwpU5i3dseCWA=.651b6d35-034a-4a29-a0a2-7cb8ec6c4fbc@github.com>

Small cleanup, unnecessary semicolons are deleted here and there.

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

Commit messages:
 - 8299430: Cleanup: delete unnecessary semicolons in java.desktop module

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

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


From psadhukhan at openjdk.org  Mon Jan  2 08:33:20 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 2 Jan 2023 08:33:20 GMT
Subject: RFR: 8298876: Swing applications do not get repainted coming out of
 sleep on Windows 10
Message-ID: <4Rwd2whqzEDkIp18wA5Gug64zbPWMzrRUNLyJ4GVJE8=.81f3f83c-df7d-40cf-9e22-25e5035435ad@github.com>

This is a revert of commit https://github.com/openjdk/jdk/commit/415bf44191632cd8dbcc158c0ff0992c0b61c3ba
which was a fix for 8275715: D3D pipeline processes multiple PaintEvent at initial drawing 
as it is causing some repaint issue and also since the regression test is known to fail in some systems and is currently problemlisted which suggests the fix was half-baked.

Raised a new issue for the same https://bugs.openjdk.org/browse/JDK-8299436

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

Commit messages:
 - 8298876: Swing applications do not get repainted coming out of sleep on Windows 10

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

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


From duke at openjdk.org  Mon Jan  2 08:42:58 2023
From: duke at openjdk.org (Tibor Malanik)
Date: Mon, 2 Jan 2023 08:42:58 GMT
Subject: RFR: 8297191: [macos] printing page range "page 2 to 2" or
 "page 2 to 4" on macOS leads to not print
In-Reply-To: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
Message-ID: <ez2nIrw-TV-NYnzwJCLxnr-PdUYhf_AZm2MiMHiF9hI=.4bc5d42a-0b5a-4e42-a4be-fa66f2b8af2d@github.com>

On Mon, 21 Nov 2022 14:32:50 GMT, Christian Heilmann <duke at openjdk.org> wrote:

> 8297191: [macos] printing page range "page 2 to 2" or "page 2 to 4" on macOS leads to not print

The problem is noticeable when setPageable on java.awt.print.PrinterJob is used. In that case the pageIndex 0 will be used in "PageFormat getPageFormat(int pageIndex)" even though user select page 2 to 2 (or 3, 4, ..).
JavaFX printing is based on the given page index, which is in that case wrong.

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

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


From psadhukhan at openjdk.org  Mon Jan  2 09:54:03 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 2 Jan 2023 09:54:03 GMT
Subject: Integrated: 6257207: JTable.getDefaultEditor throws
 NullPointerException
In-Reply-To: <ABJ79VQJ9Z_V9wB6JJTykhwJlGXac6aKHoe0Tdc5PNI=.bba61627-c1bc-40b0-a039-ac1bf918d22c@github.com>
References: <ABJ79VQJ9Z_V9wB6JJTykhwJlGXac6aKHoe0Tdc5PNI=.bba61627-c1bc-40b0-a039-ac1bf918d22c@github.com>
Message-ID: <BQ37ayn8d9OltWM-u0T3zYudje22Xfvi-E5SkMTvQ9E=.57e246c0-2c73-4a8c-b902-f5527cafa548@github.com>

On Wed, 26 Oct 2022 10:28:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> If getDefaultEditor() is called before the JTable model is setup, it results in NPE.
> 
> This is because when JTable sets its model, which ends up firing a table changed event. The testcase is listening for tableChanged events and querying the editor. But the editor isn't installed until after the model is set which results in NPE.
> Fix is to ensure initializeLocalVars() which initializes default editor is setup before JTable sets its model.
> 
> No regression is observed in jtreg/jck testsuite with this change.

This pull request has now been integrated.

Changeset: 18ff1f5a
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18ff1f5a055deb29f56f16e0fb6bbe3f5c7e4169
Stats:     142 lines in 2 files changed: 141 ins; 1 del; 0 mod

6257207: JTable.getDefaultEditor throws NullPointerException

Reviewed-by: tr, dnguyen, aivanov, serb

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

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


From serb at openjdk.org  Mon Jan  2 10:40:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 2 Jan 2023 10:40:50 GMT
Subject: RFR: 8298876: Swing applications do not get repainted coming out
 of sleep on Windows 10
In-Reply-To: <4Rwd2whqzEDkIp18wA5Gug64zbPWMzrRUNLyJ4GVJE8=.81f3f83c-df7d-40cf-9e22-25e5035435ad@github.com>
References: <4Rwd2whqzEDkIp18wA5Gug64zbPWMzrRUNLyJ4GVJE8=.81f3f83c-df7d-40cf-9e22-25e5035435ad@github.com>
Message-ID: <LxSJUVROadhWOGRnKXC_-zT4rum73_57MGE15jhQ2p0=.39fa84cd-b1cb-4ccf-b75b-44a678b0a2f3@github.com>

On Mon, 2 Jan 2023 08:24:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This is a revert of commit https://github.com/openjdk/jdk/commit/415bf44191632cd8dbcc158c0ff0992c0b61c3ba
> which was a fix for 8275715: D3D pipeline processes multiple PaintEvent at initial drawing 
> as it is causing some repaint issue and also since the regression test is known to fail in some systems and is currently problemlisted which suggests the fix was half-baked.
> 
> Raised a new issue for the same https://bugs.openjdk.org/browse/JDK-8299436

I suggest getting confirmation from Andy that this change will actually fix the problem.

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

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


From tamasflaviu at gmail.com  Mon Jan  2 13:00:00 2023
From: tamasflaviu at gmail.com (Flaviu Tamas)
Date: Mon, 2 Jan 2023 08:00:00 -0500
Subject: [PATCH] Paste fails when X clipboard is in a certain state
Message-ID: <CAKCn7JHPUDzbPZvPyT3rHjU8rhsnVOTnr=WSNLSBdd5emdPg7g@mail.gmail.com>

Sometimes, the X clipboard is in some state that causes pastes to fail
with the following, or similar, stack traces:

java.lang.NullPointerException
: Failed to retrieve atom name.
    at java.desktop/sun.awt.X11.XlibWrapper.XGetAtomName(Native Method)
    at java.desktop/sun.awt.X11.XAtom.getName(XAtom.java:189)
    at java.desktop/sun.awt.X11.XDataTransferer.getTargetNameForAtom(XDataTransferer.java:172)
    at java.desktop/sun.awt.X11.XDataTransferer.getNativeForFormat(XDataTransferer.java:161)
    at java.desktop/sun.awt.datatransfer.DataTransferer.getFlavorsForFormatsAsSet(DataTransferer.java:487)
    at java.desktop/sun.awt.datatransfer.SunClipboard.formatArrayAsDataFlavorSet(SunClipboard.java:342)
    at java.desktop/sun.awt.datatransfer.SunClipboard.isDataFlavorAvailable(SunClipboard.java:185)

This is a widespread issue and very frustrating issue, see:

- https://youtrack.jetbrains.com/issue/JBR-438/Clipboard-operations-arent-working-in-certain-state-of-Xorg-selection-buffers
- https://www.google.com/search?q="Failed+to+retrieve+atom+name"+"DataTransferer"

Frankly, I don't understand how X works at all, or how this issue
arises. However, this same workaround was applied to Mozilla in 2010:
https://hg.mozilla.org/releases/mozilla-1.9.1/rev/62f3d28797e2, and I
don't see any reasonable behavior that having this workaround in place
would break. The workaround works by simply skipping native formats
that don't have a name.

Verified to work by running IntelliJ Clion under the modified VM and
verifying that paste from my terminal, which previously did not work,
now works. I'm not familiar with OpenJDK unit testing conventions, but
I believe this change falls under the "highly platform-dependent"
exception.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fixes-failed-paste-when-X-clipboard-is-in-a-certain-.patch
Type: text/x-patch
Size: 2723 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230102/107bd7f8/0001-Fixes-failed-paste-when-X-clipboard-is-in-a-certain-.patch>

From stsypanov at openjdk.org  Mon Jan  2 16:24:47 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 2 Jan 2023 16:24:47 GMT
Subject: RFR: 8299430: Cleanup: delete unnecessary semicolons in
 java.desktop module
In-Reply-To: <P8_b3ITMyyrFNPDjlKT0aLGCrR4OJTRwpU5i3dseCWA=.651b6d35-034a-4a29-a0a2-7cb8ec6c4fbc@github.com>
References: <P8_b3ITMyyrFNPDjlKT0aLGCrR4OJTRwpU5i3dseCWA=.651b6d35-034a-4a29-a0a2-7cb8ec6c4fbc@github.com>
Message-ID: <eEZRLupOEzh27L03HUw75Qs8vk7nU6wgKiwD5jNNm2s=.c4d09386-6c7c-4633-b78a-9d0be3c6143d@github.com>

On Mon, 2 Jan 2023 07:20:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Small cleanup, unnecessary semicolons are deleted here and there.

Marked as reviewed by stsypanov (Author).

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

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


From aj at openjdk.org  Mon Jan  2 17:35:43 2023
From: aj at openjdk.org (Anto J)
Date: Mon, 2 Jan 2023 17:35:43 GMT
Subject: RFR: 8296934: Write a test to verify whether Undecorated Frame can be
 iconified or not
Message-ID: <r2i1ZTPfV1ptIZgIklDtQNuR_vt4plnRmEYXxO6BWD0=.46373c1c-cc38-4a85-bcd5-097e577477ff@github.com>

This test case verifies that Undecorated Frame can be iconified or not
Using mouse click events generated WINDOW_ACTIVATED, WINDOW_ICONIFIED, WINDOW_DEACTIVATED, and WINDOW_DEICONIFIED and tested whether it is iconified or not.

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

Commit messages:
 - 8296934: Write a test to verify whether Undecorated Frame can be iconified or not
 - 8296934: Write a test to verify whether Undecorated Frame can be iconified or not
 - 8296934: Write a test to verify whether Undecorated Frame can be iconified or not

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

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


From serb at openjdk.org  Tue Jan  3 01:17:49 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 3 Jan 2023 01:17:49 GMT
Subject: RFR: 8296934: Write a test to verify whether Undecorated Frame can
 be iconified or not
In-Reply-To: <r2i1ZTPfV1ptIZgIklDtQNuR_vt4plnRmEYXxO6BWD0=.46373c1c-cc38-4a85-bcd5-097e577477ff@github.com>
References: <r2i1ZTPfV1ptIZgIklDtQNuR_vt4plnRmEYXxO6BWD0=.46373c1c-cc38-4a85-bcd5-097e577477ff@github.com>
Message-ID: <G5yEyQoGtc1T1dSbOKguAf-__bQBtq5OhnPtSB7oEt0=.4f760719-be42-4193-a121-4e2e145875cb@github.com>

On Mon, 2 Jan 2023 16:09:35 GMT, Anto J <aj at openjdk.org> wrote:

> This test case verifies that Undecorated Frame can be iconified or not
> Using mouse click events generated WINDOW_ACTIVATED, WINDOW_ICONIFIED, WINDOW_DEACTIVATED, and WINDOW_DEICONIFIED and tested whether it is iconified or not.

>Integration blocker
>??? Failed to retrieve information on issue 8296934. Please make sure it exists and is accessible.

Looks like the JBS issue is not open.

test/jdk/java/awt/Frame/Iconify/IconifyTest.java line 105:

> 103:     }
> 104: 
> 105:     public static void main(String[] args) throws AWTException, InvocationTargetException, InterruptedException {

Please split the long lines to have 80 chars per line.

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

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


From serb at openjdk.org  Tue Jan  3 01:23:52 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 3 Jan 2023 01:23:52 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel [v2]
In-Reply-To: <IUkFswHdUwx2qx6lj6pEWtsAd6yS7N6EQj4G4iV_OMM=.d3edd5a8-6bbe-4540-b1b5-0be110f1410a@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
 <IUkFswHdUwx2qx6lj6pEWtsAd6yS7N6EQj4G4iV_OMM=.d3edd5a8-6bbe-4540-b1b5-0be110f1410a@github.com>
Message-ID: <9YWHXTWcAEWeM_tWUzbqxwN1EZjmsgbH4H1PYuo0KRA=.82e80c86-42da-4066-a1f8-31c8f1a383cc@github.com>

On Thu, 22 Dec 2022 10:35:32 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> In case of GTK LAF, the current selected element was not visible due to arrowbutton is rendered in entire display area of Combobox.
>> 
>> The proposed fix is to set the `squareButton `property of combobox to `false `so that the arrowbutton didn't take entire combobox display area for rendering. The `getMinimumSize `method is overridden in `SynthComboBoxUI `to consider **arrowbutton insets** for combobox minimum size. 
>> 
>> The JCK tests mentioned in JBS seems fine with the fix. 
>> An automated test case is implemented to test in Nimbus and GTK LAF. The text color check is to ensure the current selected item is visible.
>> 
>> When clientlibs tests are run with LAF set to Nimbus and GTK LAF, few test failures observed. 
>> 
>> `javax/swing/JComboBox/4523758/bug4523758.java` test failed with current fix in GTK LAF.
>> `open/test/jdk/javax/swing/JComboBox/TestComboBoxHeight.java` test passes if run in GTK LAF with current fix.
>> 
>> In Nimbus LAF, the failures before and after fix has no issues as such.
>> 
>> Although CI jobs looks ok with tests run in their default set LAFs.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Review comment update
>  - Merge
>  - Merge
>  - Combobox componnet rendering fix

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java line 372:

> 370:                             arrowButton.getPreferredSize().width;
> 371:         //adjust the size based on the button width
> 372:         size.height += insets.top + insets.bottom + arrowInsets.top

Are you sure that the arrow insets should be applied on top of the component's insets, probably the maximum of both should be selected?

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

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


From serb at openjdk.org  Tue Jan  3 02:31:52 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 3 Jan 2023 02:31:52 GMT
Subject: RFR: 8299296: Write a test to verify the components selection
 sends ItemEvent [v2]
In-Reply-To: <G_5l1dW0jkTapR5OVHV5VZeDRbAiHW41a2plRl12rRo=.6daebb72-9cc1-44c8-97fa-536068f5deae@github.com>
References: <0HgEcWPfdikEgz9Qiq5C579YlTEaZ6-UG4wWXS0p7oA=.73a00672-386c-4a78-8bf6-619598a23dbd@github.com>
 <G_5l1dW0jkTapR5OVHV5VZeDRbAiHW41a2plRl12rRo=.6daebb72-9cc1-44c8-97fa-536068f5deae@github.com>
Message-ID: <spEEBaK40_90KdQGknRrrZeAMLb7UX2YXyzkaj_X4HQ=.e4774dcb-d396-4157-be83-07bae6715bb9@github.com>

On Mon, 2 Jan 2023 04:41:15 GMT, Ravi Gupta <duke at openjdk.org> wrote:

>> This testcase verifies the following assertions
>> 
>> a. Selecting an item in the Choice using mouse generates ItemEvent.
>> b. Single-click on an Checkbox generates ItemEvent.
>> 
>> 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:
> 
>   8299296: Review Fixes

Marked as reviewed by serb (Reviewer).

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

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


From abhiscxk at openjdk.org  Tue Jan  3 04:48:51 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 3 Jan 2023 04:48:51 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel [v2]
In-Reply-To: <9YWHXTWcAEWeM_tWUzbqxwN1EZjmsgbH4H1PYuo0KRA=.82e80c86-42da-4066-a1f8-31c8f1a383cc@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
 <IUkFswHdUwx2qx6lj6pEWtsAd6yS7N6EQj4G4iV_OMM=.d3edd5a8-6bbe-4540-b1b5-0be110f1410a@github.com>
 <9YWHXTWcAEWeM_tWUzbqxwN1EZjmsgbH4H1PYuo0KRA=.82e80c86-42da-4066-a1f8-31c8f1a383cc@github.com>
Message-ID: <Zx1H0KCLjuJTmOQi5hBOlZUmdKVHJfmxC3Sy7u7yLxI=.f2ecbd9b-e889-4b9f-8960-704b2aeffded@github.com>

On Tue, 3 Jan 2023 01:21:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Review comment update
>>  - Merge
>>  - Merge
>>  - Combobox componnet rendering fix
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java line 372:
> 
>> 370:                             arrowButton.getPreferredSize().width;
>> 371:         //adjust the size based on the button width
>> 372:         size.height += insets.top + insets.bottom + arrowInsets.top
> 
> Are you sure that the arrow insets should be applied on top of the component's insets, probably the maximum of both should be selected?

For combobox text to render correctly arrow inset need to be applied otherwise the combobox editor shows "..." even for a smaller text. 

Since component inset's return (0, 0, 0, 0) in GTK and Nimbus LAF, didn't take the maximum of both into consideration.

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

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


From tr at openjdk.org  Tue Jan  3 05:22:51 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 3 Jan 2023 05:22:51 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <DD5uVC90-DPgmwfJXNEgnLj_wxHGTD7_uKMZBwNLHa8=.6a564a17-23d4-4da8-8381-c882b852aaaa@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
 <DD5uVC90-DPgmwfJXNEgnLj_wxHGTD7_uKMZBwNLHa8=.6a564a17-23d4-4da8-8381-c882b852aaaa@github.com>
Message-ID: <c4Qx6gF9iiaJdMaOybsl_4cNgqu8KPNOQQH2zBDAOzU=.a72f2f21-5212-4337-b3f3-ccff0a39c728@github.com>

On Sun, 25 Dec 2022 05:30:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Did we check how the native code works w/o using JFileChooser, buy FileSystemView, or by the native example? Is it possible that it is intermittent because of timing related to "com" thread?



> 

I have tested in headful system multiple time, never reproduced this issue...... Can timing affect headless......?

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

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


From psadhukhan at openjdk.org  Tue Jan  3 06:07:38 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 3 Jan 2023 06:07:38 GMT
Subject: RFR: 4934362: see also refers to self
Message-ID: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>

Some methods and constants has a hyperreference to self in javadoc which is rectified to reference proper methods

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

Commit messages:
 - 4934362: see also refers to self

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

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


From tr at openjdk.org  Tue Jan  3 07:18:32 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 3 Jan 2023 07:18:32 GMT
Subject: RFR: 8299306: Test
 "javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java" fails on
 Windows 10 x64 because there are some buttons did not display button name
Message-ID: <nb2XebuqQTexBaybLdEjdtlaG4ZlcH8WQNuLHKEcQQk=.a66207c5-f6cf-411f-b302-1d57dd5be1b7@github.com>

When JFilechooser is added to a frame, the control buttons are disabled. Since in the test the control buttons are not required since JFilechooser is added to a JFrame and in turn frame disposal is handled by PassFailJFrame. The fix is to disable JFileChooser control buttons.

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

Commit messages:
 - Fix

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

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


From psadhukhan at openjdk.org  Tue Jan  3 07:39:27 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 3 Jan 2023 07:39:27 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v2]
In-Reply-To: <iYA9P9YljBfvinZEbBIF8tWJXtZLXgBxdcBmgLKb7CU=.79a7273a-cb2e-4a80-8c29-18347a9de767@github.com>
References: <iYA9P9YljBfvinZEbBIF8tWJXtZLXgBxdcBmgLKb7CU=.79a7273a-cb2e-4a80-8c29-18347a9de767@github.com>
Message-ID: <Scc8KQ4HtOWbXTPeR0GKZDVY7joh65CvO4RUsAw4Te4=.67bf9abd-86be-4f00-b4d9-a6f53e548c4b@github.com>

> Label.foreground UIProperty is not honored by Nimbus L&F. It needs to be Label[Enabled].textForeground which is the corresponding Synth property
> Added support for setting JLabel foreground color for Nimbus L&F

Prasanta Sadhukhan 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/11660/files
  - new: https://git.openjdk.org/jdk/pull/11660/files/67095667..cbc6bc0f

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

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

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


From psadhukhan at openjdk.org  Tue Jan  3 07:39:28 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 3 Jan 2023 07:39:28 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v2]
In-Reply-To: <4gqr14XlcRb72oqMKCnMQuWGBPoNgJOLGjgAnMx7WnY=.776a4f31-56c0-4f5c-8911-d70d8f2c2635@github.com>
References: <iYA9P9YljBfvinZEbBIF8tWJXtZLXgBxdcBmgLKb7CU=.79a7273a-cb2e-4a80-8c29-18347a9de767@github.com>
 <4gqr14XlcRb72oqMKCnMQuWGBPoNgJOLGjgAnMx7WnY=.776a4f31-56c0-4f5c-8911-d70d8f2c2635@github.com>
Message-ID: <eDKGVkNxt-u6_UeffXMTibi3EidR92Ksseo3ZObS-AY=.29a78458-327c-4608-b560-b9401db5bee1@github.com>

On Wed, 14 Dec 2022 11:43:50 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove commented line
>
> test/jdk/javax/swing/plaf/nimbus/TestNimbusLabel.java line 77:
> 
>> 75:                                             java.awt.Color.red);
>> 76:                 label =
>> 77:                     //new JLabel("This text should be in red");
> 
> Commented code can be removed.

ok

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

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


From psadhukhan at openjdk.org  Tue Jan  3 08:30:50 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 3 Jan 2023 08:30:50 GMT
Subject: RFR: 8299306: Test
 "javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java" fails on
 Windows 10 x64 because there are some buttons did not display button name
In-Reply-To: <nb2XebuqQTexBaybLdEjdtlaG4ZlcH8WQNuLHKEcQQk=.a66207c5-f6cf-411f-b302-1d57dd5be1b7@github.com>
References: <nb2XebuqQTexBaybLdEjdtlaG4ZlcH8WQNuLHKEcQQk=.a66207c5-f6cf-411f-b302-1d57dd5be1b7@github.com>
Message-ID: <x1NOds2aVXl88WQCk_uAzDcbqjovunSe_cezHbOas7c=.c99f1e55-79de-45a5-84fa-c59344e3cc11@github.com>

On Tue, 3 Jan 2023 07:08:13 GMT, Tejesh R <tr at openjdk.org> wrote:

> When JFilechooser is added to a frame, the control buttons are disabled. Since in the test the control buttons are not required since JFilechooser is added to a JFrame and in turn frame disposal is handled by PassFailJFrame. The fix is to disable JFileChooser control buttons.

Any idea why "Open" button is not shown whereas "Cancel" button is shown? Seems to be some product issue w.r.t button size for "Open" button...

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

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


From tr at openjdk.org  Tue Jan  3 08:56:48 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 3 Jan 2023 08:56:48 GMT
Subject: RFR: 8299306: Test
 "javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java" fails on
 Windows 10 x64 because there are some buttons did not display button name
In-Reply-To: <x1NOds2aVXl88WQCk_uAzDcbqjovunSe_cezHbOas7c=.c99f1e55-79de-45a5-84fa-c59344e3cc11@github.com>
References: <nb2XebuqQTexBaybLdEjdtlaG4ZlcH8WQNuLHKEcQQk=.a66207c5-f6cf-411f-b302-1d57dd5be1b7@github.com>
 <x1NOds2aVXl88WQCk_uAzDcbqjovunSe_cezHbOas7c=.c99f1e55-79de-45a5-84fa-c59344e3cc11@github.com>
Message-ID: <p1j1Yz4YyuSEpbMBbpYXIGQNXQE_RTA5elJ8q1b0Q3I=.4d99841c-33e1-4584-95f2-943168df4e6c@github.com>

On Tue, 3 Jan 2023 08:28:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Any idea why "Open" button is not shown whereas "Cancel" button is shown? Seems to be some product issue w.r.t button size for "Open" button...

Didn't analyse it yet. Thought of handling that as a separate issue. Since in this test the control buttons inside JFrame are disabled.

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

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


From tr at openjdk.org  Tue Jan  3 09:04:48 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 3 Jan 2023 09:04:48 GMT
Subject: RFR: 8299306: Test
 "javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java" fails on
 Windows 10 x64 because there are some buttons did not display button name
In-Reply-To: <x1NOds2aVXl88WQCk_uAzDcbqjovunSe_cezHbOas7c=.c99f1e55-79de-45a5-84fa-c59344e3cc11@github.com>
References: <nb2XebuqQTexBaybLdEjdtlaG4ZlcH8WQNuLHKEcQQk=.a66207c5-f6cf-411f-b302-1d57dd5be1b7@github.com>
 <x1NOds2aVXl88WQCk_uAzDcbqjovunSe_cezHbOas7c=.c99f1e55-79de-45a5-84fa-c59344e3cc11@github.com>
Message-ID: <gZCCB4nnt8kKsl8T0hP5Bh1L1TjhFNNQ9aLrCenMEls=.343268ac-3fe2-4d0d-b522-33741191dc83@github.com>

On Tue, 3 Jan 2023 08:28:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JFilechooser is added to a frame, the control buttons are disabled. Since in the test the control buttons are not required since JFilechooser is added to a JFrame and in turn frame disposal is handled by PassFailJFrame. The fix is to disable JFileChooser control buttons.
>
> Any idea why "Open" button is not shown whereas "Cancel" button is shown? Seems to be some product issue w.r.t button size for "Open" button...

@prsadhuk the size issue isn't affecting anything since it is disabled inside a JFrame, should it be looked into in a separate bug?

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

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


From psadhukhan at openjdk.org  Tue Jan  3 09:08:50 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 3 Jan 2023 09:08:50 GMT
Subject: RFR: 8299306: Test
 "javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java" fails on
 Windows 10 x64 because there are some buttons did not display button name
In-Reply-To: <x1NOds2aVXl88WQCk_uAzDcbqjovunSe_cezHbOas7c=.c99f1e55-79de-45a5-84fa-c59344e3cc11@github.com>
References: <nb2XebuqQTexBaybLdEjdtlaG4ZlcH8WQNuLHKEcQQk=.a66207c5-f6cf-411f-b302-1d57dd5be1b7@github.com>
 <x1NOds2aVXl88WQCk_uAzDcbqjovunSe_cezHbOas7c=.c99f1e55-79de-45a5-84fa-c59344e3cc11@github.com>
Message-ID: <2dj638xFLkguW2Z4nELjgDoAKOfvGM3zM_a4wNttCu0=.65ee7dfc-c287-414e-bbc4-25620c460743@github.com>

On Tue, 3 Jan 2023 08:28:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JFilechooser is added to a frame, the control buttons are disabled. Since in the test the control buttons are not required since JFilechooser is added to a JFrame and in turn frame disposal is handled by PassFailJFrame. The fix is to disable JFileChooser control buttons.
>
> Any idea why "Open" button is not shown whereas "Cancel" button is shown? Seems to be some product issue w.r.t button size for "Open" button...

> @prsadhuk the size issue isn't affecting anything since it is disabled inside a JFrame, should it be looked into in a separate bug?

I dont see it disabled..It is just not shown, that too for one button whereas other button is shown...Agreed it has no bearing for this test...so it can be looked into as separate issue..you can raise a JBS issue and point to that bug here..

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

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


From aj at openjdk.org  Tue Jan  3 10:59:36 2023
From: aj at openjdk.org (Anto J)
Date: Tue, 3 Jan 2023 10:59:36 GMT
Subject: RFR: 8296934: Write a test to verify whether Undecorated Frame can
 be iconified or not [v2]
In-Reply-To: <r2i1ZTPfV1ptIZgIklDtQNuR_vt4plnRmEYXxO6BWD0=.46373c1c-cc38-4a85-bcd5-097e577477ff@github.com>
References: <r2i1ZTPfV1ptIZgIklDtQNuR_vt4plnRmEYXxO6BWD0=.46373c1c-cc38-4a85-bcd5-097e577477ff@github.com>
Message-ID: <siYfHryfixaisS_j3q0QEFvx6LUGUI5CbgkTCQnzUzM=.02d20f7b-d621-411d-bba8-897186edaf5d@github.com>

> This test case verifies that Undecorated Frame can be iconified or not
> Using mouse click events generated WINDOW_ACTIVATED, WINDOW_ICONIFIED, WINDOW_DEACTIVATED, and WINDOW_DEICONIFIED and tested whether it is iconified or not.

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

  8296934: Write a test to verify whether Undecorated Frame can be iconified or not

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11812/files
  - new: https://git.openjdk.org/jdk/pull/11812/files/863484b0..cb24853e

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

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

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


From tr at openjdk.org  Tue Jan  3 11:24:48 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 3 Jan 2023 11:24:48 GMT
Subject: RFR: 8299306: Test
 "javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java" fails on
 Windows 10 x64 because there are some buttons did not display button name
In-Reply-To: <2dj638xFLkguW2Z4nELjgDoAKOfvGM3zM_a4wNttCu0=.65ee7dfc-c287-414e-bbc4-25620c460743@github.com>
References: <nb2XebuqQTexBaybLdEjdtlaG4ZlcH8WQNuLHKEcQQk=.a66207c5-f6cf-411f-b302-1d57dd5be1b7@github.com>
 <x1NOds2aVXl88WQCk_uAzDcbqjovunSe_cezHbOas7c=.c99f1e55-79de-45a5-84fa-c59344e3cc11@github.com>
 <2dj638xFLkguW2Z4nELjgDoAKOfvGM3zM_a4wNttCu0=.65ee7dfc-c287-414e-bbc4-25620c460743@github.com>
Message-ID: <hBaTaBUxsX0-uOodL9vElR_5jo22RrJPuv0TTASfH_A=.763328de-6d8c-4317-abaf-e7bbe5ede208@github.com>

On Tue, 3 Jan 2023 09:05:54 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Any idea why "Open" button is not shown whereas "Cancel" button is shown? Seems to be some product issue w.r.t button size for "Open" button...
>
>> @prsadhuk the size issue isn't affecting anything since it is disabled inside a JFrame, should it be looked into in a separate bug?
> 
> I dont see it disabled..It is just not shown, that too for one button whereas other button is shown...Agreed it has no bearing for this test...so it can be looked into as separate issue..you can raise a JBS issue and point to that bug here..

@prsadhuk Further to add to the analysis, the issue is observed when CUSTOM Dialogue type is set without setting the approve button string.

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

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


From aghaisas at openjdk.org  Tue Jan  3 11:32:50 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 3 Jan 2023 11:32:50 GMT
Subject: RFR: 8299430: Cleanup: delete unnecessary semicolons in
 java.desktop module
In-Reply-To: <P8_b3ITMyyrFNPDjlKT0aLGCrR4OJTRwpU5i3dseCWA=.651b6d35-034a-4a29-a0a2-7cb8ec6c4fbc@github.com>
References: <P8_b3ITMyyrFNPDjlKT0aLGCrR4OJTRwpU5i3dseCWA=.651b6d35-034a-4a29-a0a2-7cb8ec6c4fbc@github.com>
Message-ID: <sTfbuI6Yq-StUdBAazFOaWEQC895zTLfI2WeRH0Wbf4=.c1cc3fb7-ab69-45d9-ab78-fc2893a70d07@github.com>

On Mon, 2 Jan 2023 07:20:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Small cleanup, unnecessary semicolons are deleted here and there.

I see that this PR touches only java files.
A few native files have these type of typos as well. I think, it is worth cleaning them as well.

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

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


From abhiscxk at openjdk.org  Tue Jan  3 12:05:52 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 3 Jan 2023 12:05:52 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v2]
In-Reply-To: <Scc8KQ4HtOWbXTPeR0GKZDVY7joh65CvO4RUsAw4Te4=.67bf9abd-86be-4f00-b4d9-a6f53e548c4b@github.com>
References: <iYA9P9YljBfvinZEbBIF8tWJXtZLXgBxdcBmgLKb7CU=.79a7273a-cb2e-4a80-8c29-18347a9de767@github.com>
 <Scc8KQ4HtOWbXTPeR0GKZDVY7joh65CvO4RUsAw4Te4=.67bf9abd-86be-4f00-b4d9-a6f53e548c4b@github.com>
Message-ID: <khi7qxHGfmXGpnh4dI8xvdF7Vhk8VGNEvAXnApSCX_4=.7ab787b4-3233-452e-b7f6-2ee699a2befe@github.com>

On Tue, 3 Jan 2023 07:39:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Label.foreground UIProperty is not honored by Nimbus L&F. It needs to be Label[Enabled].textForeground which is the corresponding Synth property
>> Added support for setting JLabel foreground color for Nimbus L&F
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove commented line

Test case passed even without doing changes in `skin.laf`. 
Tested in Windows11.

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

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


From aivanov at openjdk.org  Tue Jan  3 16:41:54 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 3 Jan 2023 16:41:54 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
Message-ID: <AUYFQt32SdX4sXakmr3GP8F5_KmY6Y6_Vu8qFsZSnmE=.1c859c8f-983e-4027-9b6c-c38839010353@github.com>

On Tue, 11 Oct 2022 14:17:42 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
> 
> Fix:
> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
> Also updated the screen capture code, made frame undecorated, added some prints for better debugging.

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 42:

> 40: import java.util.stream.IntStream;
> 41: import javax.imageio.ImageIO;
> 42: import javax.swing.SwingUtilities;

Remove the unused imports: `AtomicReference` and `SwingUtilities`.

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 59:

> 57:     private static Robot robot;
> 58:     private static Frame frame;
> 59:     private static Rectangle currentScreenBounds;

Suggestion:

    private static Rectangle screenBounds;

I think it's still clear enough yet shorter.

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 72:

> 70:             currentScreenBounds = gc.getBounds();
> 71:             Point point = new Point(currentScreenBounds.x, currentScreenBounds.y);
> 72:             Insets insets = Toolkit.getDefaultToolkit().getScreenInsets(gc);

Suggestion:

            Insets insets = Toolkit.getDefaultToolkit().getScreenInsets(gc);
            Point point = new Point(currentScreenBounds.x + insets.left, currentScreenBounds.y + insets.top);


The initial position of the frame should take the insets into account.

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 129:

> 127:         Point pt = frame.getLocationOnScreen();
> 128:         int x = pt.x + frame.getWidth() / 2;
> 129:         int y = pt.y + 50;

I suggest creating a constant `OFFSET` with the value of `50`. It would allow changing the position of the click easily.

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 143:

> 141:             throw new RuntimeException(
> 142:                     "Failed, Not received the PopupMenu ActionEvent yet on " +
> 143:                     "frame= "+frame+", isFocused = "+frame.isFocused());

Suggestion:

                    "Failed, didn't receive the PopupMenu ActionEvent on " +
                    "frame= " + frame + ", isFocused = " + frame.isFocused());

Grammar and spaces around the `+` operator.

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 153:

> 151:                           new File("screen1.png"));
> 152:         } catch (Exception exception) {
> 153:             exception.printStackTrace();

Suggestion:

        } catch (Exception e) {
            e.printStackTrace();

Why not use the standard name for the exception variable? Spelling the entire word doesn't add any value.

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 155:

> 153:             exception.printStackTrace();
> 154:         }
> 155:         action = false;

Suggestion:


It's unneeded here and rather confusing.

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

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


From aivanov at openjdk.org  Tue Jan  3 16:41:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 3 Jan 2023 16:41:59 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <bCjlBewHa7tXT7d5mtQmLxcMbGDApK2ZvtN3RSnCpCM=.fb8b14dd-1585-44d7-a153-9ec72ac20670@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
 <bCjlBewHa7tXT7d5mtQmLxcMbGDApK2ZvtN3RSnCpCM=.fb8b14dd-1585-44d7-a153-9ec72ac20670@github.com>
Message-ID: <bxzrjMDW_3h7vTjV8AL5ziDpF1fsujnTd1yojkhadbs=.f72d0e06-08b8-4cbc-9953-efe05647b20b@github.com>

On Tue, 29 Nov 2022 01:07:11 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
>> 
>> Fix:
>> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
>> Also updated the screen capture code, made frame undecorated, added some prints for better debugging.
>
> test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 75:
> 
>> 73:             while (point.y < currentScreenBounds.y + currentScreenBounds.height - insets.bottom - SIZE) {
>> 74:                 while (point.x <
>> 75:                            currentScreenBounds.x + currentScreenBounds.width - insets.right - SIZE) {
> 
> This might not be the most elegant way to abide by the rule to create a new line for long lines. I believe the line limit is 80 characters, which this still violates. And since it looks like you're trying to fix that here, might as well do it correctly.

I agree, the first `while` condition doesn't fit 80-column limit anyway, so the second may violate it too, and I think the readability only improves. Especially if you use `ScreenBounds` instead of `currentScreenBounds`.

Please, correct the positions of the closing braces: all of them are moved four spaces too far from their level, including the one which closes `main` method implementation.

> test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 114:
> 
>> 112:                 private void show(MouseEvent e) {
>> 113:                     if (e.isPopupTrigger()) {
>> 114:                         System.out.println("Going to show popup "+pm+" on "+frame);
> 
> There seems to be a lack of consistency with spacing throughout the test. Spacing out the "+" from the quotations and the vars makes it cleaner.

Right; add the spaces around binary operators.

However, I'd probably drop this print as well as the one from the `ActionListener`. Yet I admit these may help identifying what went wrong if the test fails.

> test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 133:
> 
>> 131:         robot.mousePress(InputEvent.BUTTON3_DOWN_MASK);
>> 132:         robot.mouseRelease(InputEvent.BUTTON3_DOWN_MASK);
>> 133:         robot.waitForIdle();
> 
> When testing locally on my macOS machine, this waitForIdle seems to be the culprit for why this test takes much longer per iteration. Maybe worth looking into why?

Yes, this `robot.waitForIdle` makes the test unbearably slow. Worth submitting a separate bug with the reproducer. At this point, the pop is shown on the screen and its first item is highlighted.

I replaced it with

robot.delay(200);

> test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 134:
> 
>> 132:         robot.mouseRelease(InputEvent.BUTTON3_DOWN_MASK);
>> 133:         robot.waitForIdle();
>> 134:          y = y+50;
> 
> Another instance of the spacing issue. There seems to be more in this test, so it's probably best to fix them all.

This line has wrong indentation. I suggest using a compact syntax:

Suggestion:

         y += 50;

or
Suggestion:

         y += OFFSET;

if you create the `OFFSET` constant as I suggested above.

> test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 151:
> 
>> 149:         try {
>> 150:             ImageIO.write(robot.createScreenCapture(currentScreenBounds), "png",
>> 151:                           new File("screen1.png"));
> 
> Is screen1.png the best name for the image? May be misleading if there are multiple screens, especially since this test iterates multiple locations.

It is definitely not. Either keep track of the current screen or use a generic `screen.png` file name.

I would also suggest, wrapping all the parameters to `write`:

            ImageIO.write(robot.createScreenCapture(screenBounds),
                          "png",
                          new File("screen1.png"));

This way the `"png"` doesn't get ?lost?.

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

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


From aivanov at openjdk.org  Tue Jan  3 16:49:01 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 3 Jan 2023 16:49:01 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
Message-ID: <z3JtNXaiKFA7HEvGGDj1_18JGSa6HVUDqe7rIAgfCx8=.204b76cc-b24a-4988-80d3-4cc291349f0b@github.com>

On Tue, 11 Oct 2022 14:17:42 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
> 
> Fix:
> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
> Also updated the screen capture code, made frame undecorated, added some prints for better debugging.

I also suggest removing the second asterisk at line 43, so that jtreg tags don't result javadoc warnings.

If you also remove `throws Exception` clause from `openPopup`, the test will become warning-free.

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

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


From philip.race at oracle.com  Tue Jan  3 19:10:13 2023
From: philip.race at oracle.com (Philip Race)
Date: Tue, 3 Jan 2023 11:10:13 -0800
Subject: OS/X GUI applications
In-Reply-To: <CA1D7F10-343A-4052-8E35-D21C32F9719B@gmail.com>
References: <CA1D7F10-343A-4052-8E35-D21C32F9719B@gmail.com>
Message-ID: <22d33eca-eb38-8401-291a-c7a62c25d1ee@oracle.com>



On 12/28/22 7:11 AM, Michael Hall wrote:
> I was wondering for some reason what version of the Scene Builder application I had. There was no application ?About? menu item.
> I noticed one of my own applications did have this but I didn?t remember how.
> I finally noticed on my jpackage options I was still using?
>
> -Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe
>
> Which I assume is enabling the feature.

I don't think so. I'd be surprised if anything later than Apple's JDK 6 
recognised that.

There's a property -Xdock:name
which sets the Application Name and jpackage sets that I think.
its handled in launcher code and passed to AWT code via an 
*implementation private* env. variable.
You can similarly use -Xdock:icon to set the dock icon.

If you specify your own About Handler using the Desktop API then I think 
(expect) these aren't used/needed



>
> I also include?
>
> -Dapple.laf.useScreenMenuBar=true -Dapple.awt.application.name=HalfPipe
>
> I am aware the jdk has replaced or eliminated some of this but I didn?t think still including them would cause any problems and more or less forgot they were there.
>
> Is it the intention to continue supporting any of these old Apple properties? Or are they planned to all be eliminated?

I don't know for sure without a really thorough grep but I suspect the 
latter is history.
The screen bar one persists (unfortunately) because it is so tied into 
Aqua (the only L&F
that supports it) that it wasn't something that fitted into the AWT 
Desktop class.
It'll be hard to get rid of, but that isn't the same a promise it'll 
stay since its clearly not ideal.
>
> I verified java.awt.Desktop does include?
>
> void	setAboutHandler?(AboutHandler aboutHandler)
>
> Which I would assume is the cross platform preferred and supported way of doing this. Although a bit more work to provide your own window.

Yes, but you can do more with it then.
>
> If java.awt,Desktop is still the preferred support encapsulating this platform specific functionality will javaFX at some point provide similar?

Providing an? FX equivalent of java.awt.Desktop is on the to-do list.
> This is possibly not the correct list for this. I suppose I should raise the question on the javaFX list as well as that it would be nice if SceneBuilder did have an ?about? menu item to check the version you have installed.

For FX apps .. you really should be asking on the FX list.
Most of the above - actually I suspect ALL of it is not relevant to FX.

-phil.



From philip.race at oracle.com  Tue Jan  3 19:15:44 2023
From: philip.race at oracle.com (Philip Race)
Date: Tue, 3 Jan 2023 11:15:44 -0800
Subject: OS/X GUI applications
In-Reply-To: <22d33eca-eb38-8401-291a-c7a62c25d1ee@oracle.com>
References: <CA1D7F10-343A-4052-8E35-D21C32F9719B@gmail.com>
 <22d33eca-eb38-8401-291a-c7a62c25d1ee@oracle.com>
Message-ID: <12bbb5e2-dc26-5bbe-22e5-816027ffc32b@oracle.com>

PS actually java launcher code still reads -Dapple.awt.application.name

-phil.

On 1/3/23 11:10 AM, Philip Race wrote:
>
>
> On 12/28/22 7:11 AM, Michael Hall wrote:
>> I was wondering for some reason what version of the Scene Builder 
>> application I had. There was no application ?About? menu item.
>> I noticed one of my own applications did have this but I didn?t 
>> remember how.
>> I finally noticed on my jpackage options I was still using?
>>
>> -Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe
>>
>> Which I assume is enabling the feature.
>
> I don't think so. I'd be surprised if anything later than Apple's JDK 
> 6 recognised that.
>
> There's a property -Xdock:name
> which sets the Application Name and jpackage sets that I think.
> its handled in launcher code and passed to AWT code via an 
> *implementation private* env. variable.
> You can similarly use -Xdock:icon to set the dock icon.
>
> If you specify your own About Handler using the Desktop API then I 
> think (expect) these aren't used/needed
>
>
>
>>
>> I also include?
>>
>> -Dapple.laf.useScreenMenuBar=true -Dapple.awt.application.name=HalfPipe
>>
>> I am aware the jdk has replaced or eliminated some of this but I 
>> didn?t think still including them would cause any problems and more 
>> or less forgot they were there.
>>
>> Is it the intention to continue supporting any of these old Apple 
>> properties? Or are they planned to all be eliminated?
>
> I don't know for sure without a really thorough grep but I suspect the 
> latter is history.
> The screen bar one persists (unfortunately) because it is so tied into 
> Aqua (the only L&F
> that supports it) that it wasn't something that fitted into the AWT 
> Desktop class.
> It'll be hard to get rid of, but that isn't the same a promise it'll 
> stay since its clearly not ideal.
>>
>> I verified java.awt.Desktop does include?
>>
>> void??? setAboutHandler?(AboutHandler aboutHandler)
>>
>> Which I would assume is the cross platform preferred and supported 
>> way of doing this. Although a bit more work to provide your own window.
>
> Yes, but you can do more with it then.
>>
>> If java.awt,Desktop is still the preferred support encapsulating this 
>> platform specific functionality will javaFX at some point provide 
>> similar?
>
> Providing an? FX equivalent of java.awt.Desktop is on the to-do list.
>> This is possibly not the correct list for this. I suppose I should 
>> raise the question on the javaFX list as well as that it would be 
>> nice if SceneBuilder did have an ?about? menu item to check the 
>> version you have installed.
>
> For FX apps .. you really should be asking on the FX list.
> Most of the above - actually I suspect ALL of it is not relevant to FX.
>
> -phil.
>



From prr at openjdk.org  Tue Jan  3 19:27:49 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 3 Jan 2023 19:27:49 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows [v2]
In-Reply-To: <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
 <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
Message-ID: <_2pJwsNDo0kDexbdYZpMADEEHXNAv_aa4cGsmVbd_Fk=.452bb33d-e576-4a1c-a290-d8d91b007c7e@github.com>

On Thu, 22 Dec 2022 10:57:15 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> **Environment**: 
>> GraalVM 22.3.0 with  jdk 19, Windows OS.
>> 
>> **Description**:
>> Create a native image of Swing application using GraalVM and run it with ` -Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> `java.lang.Error: java.home property not set` error is thrown.
>> 
>> For more details see https://github.com/oracle/graal/issues/4875.
>> 
>> **Solution**:
>> The error is thrown by the code from [FontConfiguration.findFontConfigFile()](https://github.com/openjdk/jdk19u/blob/c9d485792b99233f381dcdfd69838e7b973909bd/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L175) method.
>> GraalVM does not set `java.home`  property, that is why the `java.lang.Error: java.home property not set` is thrown.
>> `FontConfiguration.findFontConfigFile()` method compares `java.home` property to null before checking user provided `sun.awt.fontconfig` java property.
>> 
>> The proposed fix swaps the order of `java.home` and `sun.awt.fontconfig` properties checking to avoid using `java.home` property in case `sun.awt.fontconfig` is set.
>> 
>> 
>> **Steps to reproduce**:
>> - Download graal 22.3.0 jdk 19 for Windows from [GraalVM Community Edition 22.3.0](https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0) page.
>> - Install native-image
>> 
>> graalvm-ce-java19-22.3.0\bin\gu.cmd install native-image
>> 
>> - Create and compile `SwingSample.java` sample
>> 
>> import java.awt.*;
>> import javax.swing.*;
>> 
>> public class SwingSample {
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeAndWait(() -> {
>> 
>>             JFrame frame = new JFrame("Hello World");
>> 
>>             JButton button = new JButton("Hello");
>>             button.addActionListener(e -> {
>>                 System.out.printf("Hello, World!%n");
>>             });
>> 
>>             JPanel panel = new JPanel(new FlowLayout());
>>             panel.add(button);
>> 
>>             frame.add(panel);
>>             frame.setSize(400, 300);
>>             frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>             frame.setVisible(true);
>>         });
>>     }
>> }
>> 
>> - Run native-image-agent to generate configuration files
>> 
>> graalvm-ce-java19-22.3.0\bin\java.cmd -agentlib:native-image-agent=config-output-dir=conf-dir SwingSample
>> 
>> - Copy `graalvm-ce-java19-22.3.0\lib\fontconfig.properties.src` file to the sample dir
>> - Generate native image with configuration files and `-Djava.awt.headless=false `, `-Dsun.awt.fontconfig=fontconfig.properties.src` java properties
>> 
>> call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64"
>> graalvm-ce-java19-22.3.0\bin\native-image.cmd --no-fallback -Djava.awt.headless=false -Dsun.awt.fontconfig=fontconfig.properties.src -H:ResourceConfigurationFiles=conf-dir/resource-config.json -H:SerializationConfigurationFiles=conf-dir/serialization-config.json -H:ReflectionConfigurationFiles=conf-dir/reflect-config.json -H:JNIConfigurationFiles=conf-dir/jni-config.json SwingSample
>> 
>> - Run the native image with `-Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> 
>> swingsample.exe  -Dsun.awt.fontconfig=fontconfig.properties.src
>> 
>> Exception in thread "main" java.lang.reflect.InvocationTargetException
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371)
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346)
>>         at java.desktop at 19.0.1/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480)
>>         at SwingSample.main(SwingSample.java:7)
>> Caused by: java.lang.Error: java.home property not set
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
>>         at java.desktop at 19.0.1/sun.awt.windows.WFontConfiguration.<init>(WFontConfiguration.java:41)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize javaLib when a user fontconfig file is set

FYI here's an almost 9 year old bug report where I make clear the unsupported nature of that property. https://bugs.openjdk.org/browse/JDK-8038987

Seems this PR should be withdrawn and the bug report closed as external or not an issue.

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

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


From mik3hall at gmail.com  Tue Jan  3 19:59:23 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 3 Jan 2023 13:59:23 -0600
Subject: OS/X GUI applications
In-Reply-To: <22d33eca-eb38-8401-291a-c7a62c25d1ee@oracle.com>
References: <CA1D7F10-343A-4052-8E35-D21C32F9719B@gmail.com>
 <22d33eca-eb38-8401-291a-c7a62c25d1ee@oracle.com>
Message-ID: <E8CD9428-4214-4A51-BE32-8F0B526795D4@gmail.com>



> On Jan 3, 2023, at 1:10 PM, Philip Race <philip.race at oracle.com> wrote:
> 
> 
> 
>> FX list as well as that it would be nice if SceneBuilder did have an ?about? menu item to check the version you have installed.
> 
> For FX apps .. you really should be asking on the FX list.
> Most of the above - actually I suspect ALL of it is not relevant to FX.
> 
> -Phil.

I tried what FX seems to provide?

		MenuBar mb = new MenuBar();
		mb.setUseSystemMenuBar(true);

But it didn?t work. Maybe not how it should properly be used so I may ask yet.

It seems to come down to what happens in LWCToolkit. FX app?s don?t get some or any of the NSApplicationAWT code to run from it, while they normally do.
This gives you the menu item and the default Cocoa ?About? should work. Without it the code manages to run through although it appears to assume this has happened as shown before in ApplicationDelegate , so this seems almost lucky and actually a bug. .
I?m not sure I?ve given up just yet on figuring out what is different so the normal doesn?t happen. 

Thanks for the reply.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230103/75418ccf/attachment.htm>

From aivanov at openjdk.org  Tue Jan  3 20:07:41 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 3 Jan 2023 20:07:41 GMT
Subject: RFR: 8299553: Make ScaledEtchedBorderTest.java comprehensive
Message-ID: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>

The `ScaledEtchedBorderTest.java` test ([JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614)) verifies that the thickness of lines of `EtchedBorder` is consistent. The component inside had the same background color as the frame. Yet if there's another component the background of which is different, that background could be seen.

The updated test covers the scenario reported in [JDK-8294921](https://bugs.openjdk.org/browse/JDK-8294921).

The bug itself is fixed by refactoring [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) the border rendering code which uses a more precise coordinate calculation, see #11571. Thus, I contribute the test under a separate bugid.

I also modified `ScaledLineBorderTest.java` so that the location of the child panels is saved when they're created as done in `ScaledTextFieldBorderTest.java` in #11498. I removed the unused `Component` import after this modification from both tests.

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

Commit messages:
 - Drop the unused import: Component
 - Save panel locations when creating them
 - 8299553: Make ScaledEtchedBorderTest.java comprehensive

Changes: https://git.openjdk.org/jdk/pull/11836/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11836&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299553
  Stats: 280 lines in 3 files changed: 141 ins; 50 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/11836.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11836/head:pull/11836

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


From serb at openjdk.org  Tue Jan  3 20:31:49 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 3 Jan 2023 20:31:49 GMT
Subject: RFR: 8299553: Make ScaledEtchedBorderTest.java comprehensive
In-Reply-To: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>
References: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>
Message-ID: <toKcDqNfsiUhh0WCPTGwm1543c6cheEL6VwipEEd9lc=.ed8623a4-f650-4772-8edf-be2a30c25fb4@github.com>

On Tue, 3 Jan 2023 19:59:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The `ScaledEtchedBorderTest.java` test ([JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614)) verifies that the thickness of lines of `EtchedBorder` is consistent. The component inside had the same background color as the frame. Yet if there's another component the background of which is different, that background could be seen.
> 
> The updated test covers the scenario reported in [JDK-8294921](https://bugs.openjdk.org/browse/JDK-8294921).
> 
> The bug itself is fixed by refactoring [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) the border rendering code which uses a more precise coordinate calculation, see #11571. Thus, I contribute the test under a separate bugid.
> 
> I also modified `ScaledLineBorderTest.java` so that the location of the child panels is saved when they're created as done in `ScaledTextFieldBorderTest.java` in #11498. I removed the unused `Component` import after this modification from both tests.

Don't you need to close the [JDK-8294921](https://bugs.openjdk.org/browse/JDK-8294921) since it was fixed already?

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

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


From aivanov at openjdk.org  Tue Jan  3 20:44:49 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 3 Jan 2023 20:44:49 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v8]
In-Reply-To: <2foDWBaTP1qZxwNmj940TSWXfl3BkFr6lENO9ZG91qo=.f6c37ff2-f160-40e6-8e34-c531f565d97d@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
 <2foDWBaTP1qZxwNmj940TSWXfl3BkFr6lENO9ZG91qo=.f6c37ff2-f160-40e6-8e34-c531f565d97d@github.com>
Message-ID: <gbp2LEjg-1diRFit9Kqb3wXR01vAkBTISODQ3cHmdgY=.6acc50c3-cb7a-415c-983a-e90ed85425ad@github.com>

On Thu, 29 Dec 2022 06:52:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>>     javax.swing.text.html.parser.ParserDelegator
>>     javax.swing.LayoutComparator
>> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
>> 
>> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
>> Added the warning..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add <p> tag

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.org  Tue Jan  3 20:47:51 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 3 Jan 2023 20:47:51 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v8]
In-Reply-To: <2foDWBaTP1qZxwNmj940TSWXfl3BkFr6lENO9ZG91qo=.f6c37ff2-f160-40e6-8e34-c531f565d97d@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
 <2foDWBaTP1qZxwNmj940TSWXfl3BkFr6lENO9ZG91qo=.f6c37ff2-f160-40e6-8e34-c531f565d97d@github.com>
Message-ID: <bHuAoQXbcHOFxcpI1asePdZoQo36iIQ-eM38TTHRON8=.f758c04d-6c9d-4760-84f3-5add29e93acf@github.com>

On Thu, 29 Dec 2022 06:52:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>>     javax.swing.text.html.parser.ParserDelegator
>>     javax.swing.LayoutComparator
>> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
>> 
>> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
>> Added the warning..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add <p> tag

Does this change require updating the CSR?

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

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


From honkar at openjdk.org  Tue Jan  3 20:48:51 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 3 Jan 2023 20:48:51 GMT
Subject: RFR: 8299553: Make ScaledEtchedBorderTest.java comprehensive
In-Reply-To: <toKcDqNfsiUhh0WCPTGwm1543c6cheEL6VwipEEd9lc=.ed8623a4-f650-4772-8edf-be2a30c25fb4@github.com>
References: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>
 <toKcDqNfsiUhh0WCPTGwm1543c6cheEL6VwipEEd9lc=.ed8623a4-f650-4772-8edf-be2a30c25fb4@github.com>
Message-ID: <JF3AAQw1y2-Pw03k0ZLVtPKKWa0_1w8NfV3_z3cdsho=.a9b627c9-1927-4efa-9a3a-512d7cd2fd3a@github.com>

On Tue, 3 Jan 2023 20:28:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Don't you need to close the [JDK-8294921](https://bugs.openjdk.org/browse/JDK-8294921) since it was fixed already?

This issue has been closed now.

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

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


From serb at openjdk.org  Tue Jan  3 21:01:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 3 Jan 2023 21:01:50 GMT
Subject: RFR: 8299553: Make ScaledEtchedBorderTest.java comprehensive
In-Reply-To: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>
References: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>
Message-ID: <zzHVOtxFZIAphNkwk_-Ru84iE4VE0lQPud4R9_6_Cn0=.6ce7049a-a766-4183-9ba6-07e59d992cdb@github.com>

On Tue, 3 Jan 2023 19:59:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The `ScaledEtchedBorderTest.java` test ([JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614)) verifies that the thickness of lines of `EtchedBorder` is consistent. The component inside had the same background color as the frame. Yet if there's another component the background of which is different, that background could be seen.
> 
> The updated test covers the scenario reported in [JDK-8294921](https://bugs.openjdk.org/browse/JDK-8294921).
> 
> The bug itself is fixed by refactoring [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) the border rendering code which uses a more precise coordinate calculation, see #11571. Thus, I contribute the test under a separate bugid.
> 
> I also modified `ScaledLineBorderTest.java` so that the location of the child panels is saved when they're created as done in `ScaledTextFieldBorderTest.java` in #11498. I removed the unused `Component` import after this modification from both tests.

Marked as reviewed by serb (Reviewer).

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

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


From djelinski at openjdk.org  Tue Jan  3 22:19:48 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 3 Jan 2023 22:19:48 GMT
Subject: RFR: 8299261: Clean up AWT D3D exports
In-Reply-To: <dAxIVJYLOXHv0t-y1d21lQyPx8v2SM7WTRn5Hf0Q96Q=.a0c5f8ac-3c7d-4984-bf08-065a8e06364b@github.com>
References: <dAxIVJYLOXHv0t-y1d21lQyPx8v2SM7WTRn5Hf0Q96Q=.a0c5f8ac-3c7d-4984-bf08-065a8e06364b@github.com>
Message-ID: <oJBuFlIHJtZ3h4w-htX8ENsuzfiunnZXt4mXK6xdpbg=.0ca28ace-adc3-43f6-8236-e90a639778d8@github.com>

On Thu, 22 Dec 2022 10:01:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes unnecessary exports from awt.dll.
> 
> The exports were introduced in e4c9db984fe1a3a9d06fb60e333e92df3b165454, and as far as I could tell, they were never used; the exported functions are only used inside awt.dll.
> 
> Verified that:
> - debug and release builds finish successfully
> - mach5 client libs tests pass

Happy new year!
Thanks @mrserb for your review. Can I get a second opinion on this?

The patch removes 139 functions from the list of exports, and reduces the binary size by a few kilobytes.
The GHA failure is unrelated.

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

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


From honkar at openjdk.org  Tue Jan  3 23:14:51 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 3 Jan 2023 23:14:51 GMT
Subject: RFR: 8299553: Make ScaledEtchedBorderTest.java comprehensive
In-Reply-To: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>
References: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>
Message-ID: <QSyIqov-356WqucY324pu0ZJ6mjHlUc7VYyC3__yOno=.6a9637f7-d602-4e34-aa08-ef23350dea38@github.com>

On Tue, 3 Jan 2023 19:59:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The `ScaledEtchedBorderTest.java` test ([JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614)) verifies that the thickness of lines of `EtchedBorder` is consistent. The component inside had the same background color as the frame. Yet if there's another component the background of which is different, that background could be seen.
> 
> The updated test covers the scenario reported in [JDK-8294921](https://bugs.openjdk.org/browse/JDK-8294921).
> 
> The bug itself is fixed by refactoring [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) the border rendering code which uses a more precise coordinate calculation, see #11571. Thus, I contribute the test under a separate bugid.
> 
> I also modified `ScaledLineBorderTest.java` so that the location of the child panels is saved when they're created as done in `ScaledTextFieldBorderTest.java` in #11498. I removed the unused `Component` import after this modification from both tests.

Tested all 3 tests, it works as expected.
Minor inline suggestions added that are applicable for all 3 tests.

test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 239:

> 237:     }
> 238: 
> 239:     private enum State {

enum declaration can be moved before its first usage (before `checkBorder()`)

test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 250:

> 248:         throw new Error(
> 249:                 String.format("Wrong border thickness at %d, %d: %d vs %d",
> 250:                               x, y, borderThickness, thickness));

Same as above - including state value in error msg can be helpful here.

test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 256:

> 254:         throw new Error(
> 255:                 String.format("Unexpected color at %d, %d: %08x",
> 256:                               x, y, color));

Since `throwUnexpectedColor()` is called commonly for different state values, including the state value in the error msg could be useful for debugging purpose.

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

Changes requested by honkar (Committer).

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


From duke at openjdk.org  Wed Jan  4 01:25:56 2023
From: duke at openjdk.org (duke)
Date: Wed, 4 Jan 2023 01:25:56 GMT
Subject: Withdrawn: 8296535: Unnecessary Vector usage in
 AquaFileSystemModel.FilesLoader
In-Reply-To: <BnwPBR5cvLu6wUnOmapLuWRd2qDYn1csuAORWZTMEvw=.1f917ded-b8e6-4768-861c-f6bca31f59f4@github.com>
References: <BnwPBR5cvLu6wUnOmapLuWRd2qDYn1csuAORWZTMEvw=.1f917ded-b8e6-4768-861c-f6bca31f59f4@github.com>
Message-ID: <3QDRkSukR0V4XyWuwy1RDRPFQq_dU1KqntF6EhrC8CA=.b83fc6c0-896f-45f1-b98d-e25f4131ceb3@github.com>

On Wed, 2 Nov 2022 08:19:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of local variables in `com.apple.laf.AquaFileSystemModel.FilesLoader#run` are used only within the method from single thread. So we can avoid usage of legacy synchronized `Vector` here and use `ArrayList` instead.

This pull request has been closed without being integrated.

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

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


From psadhukhan at openjdk.org  Wed Jan  4 03:29:54 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 4 Jan 2023 03:29:54 GMT
Subject: Integrated: 7030853: JDK 7 Serializable Swing classes not compatible
 with JDK 6
In-Reply-To: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
Message-ID: <pyOw2m0QVBPgddgZLaBRvMaaNLcNVL2IC6Z7zJHI7V8=.5f01f083-dd2c-4185-8f04-249790803b57@github.com>

On Wed, 7 Dec 2022 16:35:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>     javax.swing.text.html.parser.ParserDelegator
>     javax.swing.LayoutComparator
> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
> 
> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
> Added the warning..

This pull request has now been integrated.

Changeset: 77ff1977
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/77ff19774651f1c41bbb1e59b2873d74522c8666
Stats:     22 lines in 3 files changed: 22 ins; 0 del; 0 mod

7030853: JDK 7 Serializable Swing classes not compatible with JDK 6

Reviewed-by: serb, aivanov

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

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


From duke at openjdk.org  Wed Jan  4 03:39:49 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Wed, 4 Jan 2023 03:39:49 GMT
Subject: RFR: 8299296: Write a test to verify the components selection
 sends ItemEvent [v2]
In-Reply-To: <G_5l1dW0jkTapR5OVHV5VZeDRbAiHW41a2plRl12rRo=.6daebb72-9cc1-44c8-97fa-536068f5deae@github.com>
References: <0HgEcWPfdikEgz9Qiq5C579YlTEaZ6-UG4wWXS0p7oA=.73a00672-386c-4a78-8bf6-619598a23dbd@github.com>
 <G_5l1dW0jkTapR5OVHV5VZeDRbAiHW41a2plRl12rRo=.6daebb72-9cc1-44c8-97fa-536068f5deae@github.com>
Message-ID: <2X9UUMtq7roYZGXgV16roDNF38rMlG70Hzp3tdD95PI=.b8d10584-9e77-45e6-abac-c9a8c8cd9748@github.com>

On Mon, 2 Jan 2023 04:41:15 GMT, Ravi Gupta <duke at openjdk.org> wrote:

>> This testcase verifies the following assertions
>> 
>> a. Selecting an item in the Choice using mouse generates ItemEvent.
>> b. Single-click on an Checkbox generates ItemEvent.
>> 
>> 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:
> 
>   8299296: Review Fixes

Any volunteers for a sponsor?

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

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


From aj at openjdk.org  Wed Jan  4 05:44:50 2023
From: aj at openjdk.org (Anto J)
Date: Wed, 4 Jan 2023 05:44:50 GMT
Subject: RFR: 8296934: Write a test to verify whether Undecorated Frame can
 be iconified or not [v2]
In-Reply-To: <G5yEyQoGtc1T1dSbOKguAf-__bQBtq5OhnPtSB7oEt0=.4f760719-be42-4193-a121-4e2e145875cb@github.com>
References: <r2i1ZTPfV1ptIZgIklDtQNuR_vt4plnRmEYXxO6BWD0=.46373c1c-cc38-4a85-bcd5-097e577477ff@github.com>
 <G5yEyQoGtc1T1dSbOKguAf-__bQBtq5OhnPtSB7oEt0=.4f760719-be42-4193-a121-4e2e145875cb@github.com>
Message-ID: <8HYK6ANqo7Mh9QEvCiYoLeh09J6S02wObMjiJqqnGNM=.0527dd82-c012-4ba3-985a-6ce1bf16066e@github.com>

On Tue, 3 Jan 2023 01:14:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Anto J has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8296934: Write a test to verify whether Undecorated Frame can be iconified or not
>
> test/jdk/java/awt/Frame/Iconify/IconifyTest.java line 105:
> 
>> 103:     }
>> 104: 
>> 105:     public static void main(String[] args) throws AWTException, InvocationTargetException, InterruptedException {
> 
> Please split the long lines to have 80 chars per line.

Done the changes

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

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


From abhiscxk at openjdk.org  Wed Jan  4 11:00:49 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 4 Jan 2023 11:00:49 GMT
Subject: RFR: 8081507: Open or Save button in JFileChooser has OK title in
 GTK LaF
In-Reply-To: <asK1gGR8S-lk1vrFrmLRGg57jpbqclqqmJiKKVk8iFw=.7597cd9d-6391-4eea-af2b-607e9e283a79@github.com>
References: <xiAzTly59fGFbv79RPrpnePFxG42TRYmGXrikg8DUKQ=.96d809a6-379e-4943-9e6d-41ac46fbc01f@github.com>
 <asK1gGR8S-lk1vrFrmLRGg57jpbqclqqmJiKKVk8iFw=.7597cd9d-6391-4eea-af2b-607e9e283a79@github.com>
Message-ID: <7HtP2kpf63K6xXcI2CVkvy5X3Ci_lwwWfEOf2C6zeBA=.d6729c42-d3d8-4dfc-ad02-ed925c6c35b0@github.com>

On Thu, 29 Dec 2022 03:40:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Open or Save button in JFileChooser has OK title in GTK LAF. The open/save button text modified as per the native FileChooser. Manual test case is added.
>> 
>> `open/test/jdk/sanity/client/SwingSet/src/FileChooserDemoTest.java` failed with the current fix with an exception `**Wait AbstractButton with text "OK" loaded.**` Updated the test for GTK LAF and tested in CI which is OK now.
>> 
>> CI link is added in JBS.
>
> Marked as reviewed by serb (Reviewer).

@mrserb Can you please sponsor this PR?

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

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


From aivanov at openjdk.org  Wed Jan  4 12:20:50 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 4 Jan 2023 12:20:50 GMT
Subject: RFR: 8299553: Make ScaledEtchedBorderTest.java comprehensive
In-Reply-To: <QSyIqov-356WqucY324pu0ZJ6mjHlUc7VYyC3__yOno=.6a9637f7-d602-4e34-aa08-ef23350dea38@github.com>
References: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>
 <QSyIqov-356WqucY324pu0ZJ6mjHlUc7VYyC3__yOno=.6a9637f7-d602-4e34-aa08-ef23350dea38@github.com>
Message-ID: <1-FmC9Ye3Mk3tCurDOy-orOU25STPBapYIbuVFvHLB4=.f8d88846-1eae-40c1-8748-bee6c354526c@github.com>

On Tue, 3 Jan 2023 23:05:53 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The `ScaledEtchedBorderTest.java` test ([JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614)) verifies that the thickness of lines of `EtchedBorder` is consistent. The component inside had the same background color as the frame. Yet if there's another component the background of which is different, that background could be seen.
>> 
>> The updated test covers the scenario reported in [JDK-8294921](https://bugs.openjdk.org/browse/JDK-8294921).
>> 
>> The bug itself is fixed by refactoring [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) the border rendering code which uses a more precise coordinate calculation, see #11571. Thus, I contribute the test under a separate bugid.
>> 
>> I also modified `ScaledLineBorderTest.java` so that the location of the child panels is saved when they're created as done in `ScaledTextFieldBorderTest.java` in #11498. I removed the unused `Component` import after this modification from both tests.
>
> test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 256:
> 
>> 254:         throw new Error(
>> 255:                 String.format("Unexpected color at %d, %d: %08x",
>> 256:                               x, y, color));
> 
> Since `throwUnexpectedColor()` is called commonly for different state values, including the state value in the error msg could be useful for debugging purpose.

I don't think it's needed: the stack trace of the exception contains the line number which uniquely identifies the state.

For example, an excerpt of test output when it fails:

Scaling: 1.00
java.lang.Error: Unexpected color at 62, 24: ffffffff
        at ScaledEtchedBorderTest.throwUnexpectedColor(ScaledEtchedBorderTest.java:255)
        at ScaledEtchedBorderTest.checkBorder(ScaledEtchedBorderTest.java:231)
        at ScaledEtchedBorderTest.checkVerticalBorders(ScaledEtchedBorderTest.java:131)
        at ScaledEtchedBorderTest.verifyBorderRendering(ScaledEtchedBorderTest.java:99)
        at ScaledEtchedBorderTest.testScaling(ScaledEtchedBorderTest.java:87)
        at ScaledEtchedBorderTest.lambda$main$0(ScaledEtchedBorderTest.java:77)
	at ?


https://github.com/openjdk/jdk/blob/b78389e8c1e23cb83338387ba20091bf705480e1/test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java#L221-L232

Line 231 corresponds to the `RIGHT_HIGHLIGHT` state. If you open the `test1.00.png` image, you quickly see, there's _a white line_ below the highlight line which shouldn't be there.

Therefore, passing the additional parameter doesn't add much value.

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

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


From aivanov at openjdk.org  Wed Jan  4 12:30:48 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 4 Jan 2023 12:30:48 GMT
Subject: RFR: 8299553: Make ScaledEtchedBorderTest.java comprehensive
In-Reply-To: <QSyIqov-356WqucY324pu0ZJ6mjHlUc7VYyC3__yOno=.6a9637f7-d602-4e34-aa08-ef23350dea38@github.com>
References: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>
 <QSyIqov-356WqucY324pu0ZJ6mjHlUc7VYyC3__yOno=.6a9637f7-d602-4e34-aa08-ef23350dea38@github.com>
Message-ID: <_kFCEuDXFvEDD937e2xCWlUL1VZ-iuTBa19pfWgds8Y=.ae298835-29b8-440e-b1a9-0e63f02c6600@github.com>

On Tue, 3 Jan 2023 23:06:16 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The `ScaledEtchedBorderTest.java` test ([JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614)) verifies that the thickness of lines of `EtchedBorder` is consistent. The component inside had the same background color as the frame. Yet if there's another component the background of which is different, that background could be seen.
>> 
>> The updated test covers the scenario reported in [JDK-8294921](https://bugs.openjdk.org/browse/JDK-8294921).
>> 
>> The bug itself is fixed by refactoring [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) the border rendering code which uses a more precise coordinate calculation, see #11571. Thus, I contribute the test under a separate bugid.
>> 
>> I also modified `ScaledLineBorderTest.java` so that the location of the child panels is saved when they're created as done in `ScaledTextFieldBorderTest.java` in #11498. I removed the unused `Component` import after this modification from both tests.
>
> test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 239:
> 
>> 237:     }
>> 238: 
>> 239:     private enum State {
> 
> enum declaration can be moved before its first usage (before `checkBorder()`)

I agree here, the `State` enum is declared before `checkBorder` in `ScaledTextFieldBorderTest.java`, yet it's after the method in both `ScaledLineBorderTest.java` and `ScaledEtchedBorderTest.java`.

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

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


From djelinski at openjdk.org  Wed Jan  4 13:24:30 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 4 Jan 2023 13:24:30 GMT
Subject: RFR: 8299592: Fix and reenable warnings in java.desktop native code
 compilation
Message-ID: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@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.

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

Commit messages:
 - 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=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299592
  Stats: 185 lines in 11 files changed: 2 ins; 121 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/11841.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11841/head:pull/11841

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


From aivanov at openjdk.org  Wed Jan  4 16:26:24 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 4 Jan 2023 16:26:24 GMT
Subject: RFR: 8299553: Make ScaledEtchedBorderTest.java comprehensive [v2]
In-Reply-To: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>
References: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>
Message-ID: <ujLI0WtXpnGG_bCU0akrzCCiI5c1BiRwvV2XGHIVesg=.21dea1ce-b4d3-4ce6-95fa-f472bfbc22cf@github.com>

> The `ScaledEtchedBorderTest.java` test ([JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614)) verifies that the thickness of lines of `EtchedBorder` is consistent. The component inside had the same background color as the frame. Yet if there's another component the background of which is different, that background could be seen.
> 
> The updated test covers the scenario reported in [JDK-8294921](https://bugs.openjdk.org/browse/JDK-8294921).
> 
> The bug itself is fixed by refactoring [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) the border rendering code which uses a more precise coordinate calculation, see #11571. Thus, I contribute the test under a separate bugid.
> 
> I also modified `ScaledLineBorderTest.java` so that the location of the child panels is saved when they're created as done in `ScaledTextFieldBorderTest.java` in #11498. I removed the unused `Component` import after this modification from both tests.

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

  Move State enum before checkBorder where it's used

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11836/files
  - new: https://git.openjdk.org/jdk/pull/11836/files/b78389e8..f7783e43

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

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

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


From honkar at openjdk.org  Wed Jan  4 17:09:55 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 4 Jan 2023 17:09:55 GMT
Subject: RFR: 8299553: Make ScaledEtchedBorderTest.java comprehensive [v2]
In-Reply-To: <ujLI0WtXpnGG_bCU0akrzCCiI5c1BiRwvV2XGHIVesg=.21dea1ce-b4d3-4ce6-95fa-f472bfbc22cf@github.com>
References: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>
 <ujLI0WtXpnGG_bCU0akrzCCiI5c1BiRwvV2XGHIVesg=.21dea1ce-b4d3-4ce6-95fa-f472bfbc22cf@github.com>
Message-ID: <5Neh0Q-y-nVJNazrWUFOIQCzzhyWX4K-FfQ3r6l2jN8=.d45367b6-8016-459a-a0ec-ad15065a7aeb@github.com>

On Wed, 4 Jan 2023 16:26:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The `ScaledEtchedBorderTest.java` test ([JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614)) verifies that the thickness of lines of `EtchedBorder` is consistent. The component inside had the same background color as the frame. Yet if there's another component the background of which is different, that background could be seen.
>> 
>> The updated test covers the scenario reported in [JDK-8294921](https://bugs.openjdk.org/browse/JDK-8294921).
>> 
>> The bug itself is fixed by refactoring [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) the border rendering code which uses a more precise coordinate calculation, see #11571. Thus, I contribute the test under a separate bugid.
>> 
>> I also modified `ScaledLineBorderTest.java` so that the location of the child panels is saved when they're created as done in `ScaledTextFieldBorderTest.java` in #11498. I removed the unused `Component` import after this modification from both tests.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move State enum before checkBorder where it's used

Marked as reviewed by honkar (Committer).

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

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


From duke at openjdk.org  Wed Jan  4 17:21:49 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Wed, 4 Jan 2023 17:21:49 GMT
Subject: RFR: 8299296: Write a test to verify the components selection
 sends ItemEvent [v2]
In-Reply-To: <spEEBaK40_90KdQGknRrrZeAMLb7UX2YXyzkaj_X4HQ=.e4774dcb-d396-4157-be83-07bae6715bb9@github.com>
References: <0HgEcWPfdikEgz9Qiq5C579YlTEaZ6-UG4wWXS0p7oA=.73a00672-386c-4a78-8bf6-619598a23dbd@github.com>
 <G_5l1dW0jkTapR5OVHV5VZeDRbAiHW41a2plRl12rRo=.6daebb72-9cc1-44c8-97fa-536068f5deae@github.com>
 <spEEBaK40_90KdQGknRrrZeAMLb7UX2YXyzkaj_X4HQ=.e4774dcb-d396-4157-be83-07bae6715bb9@github.com>
Message-ID: <QKHz_epOSlQoP-R2VHVwOLHtxT88QJWOspdEfF_rZjA=.ce5a5962-f352-4b09-a710-86f469eb5adf@github.com>

On Tue, 3 Jan 2023 02:29:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8299296: Review Fixes
>
> Marked as reviewed by serb (Reviewer).

@mrserb requesting you to please sponsor.

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

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


From tr at openjdk.org  Wed Jan  4 17:45:50 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 4 Jan 2023 17:45:50 GMT
Subject: RFR: 8081507: Open or Save button in JFileChooser has OK title in
 GTK LaF
In-Reply-To: <xiAzTly59fGFbv79RPrpnePFxG42TRYmGXrikg8DUKQ=.96d809a6-379e-4943-9e6d-41ac46fbc01f@github.com>
References: <xiAzTly59fGFbv79RPrpnePFxG42TRYmGXrikg8DUKQ=.96d809a6-379e-4943-9e6d-41ac46fbc01f@github.com>
Message-ID: <Qpq9TfWNhWPtK-c14krps-MNY9JlHbJLwnYY7OqOvO0=.efcb5d55-8534-4889-a011-ee56a2ae2aad@github.com>

On Tue, 27 Dec 2022 19:05:10 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Open or Save button in JFileChooser has OK title in GTK LAF. The open/save button text modified as per the native FileChooser. Manual test case is added.
> 
> `open/test/jdk/sanity/client/SwingSet/src/FileChooserDemoTest.java` failed with the current fix with an exception `**Wait AbstractButton with text "OK" loaded.**` Updated the test for GTK LAF and tested in CI which is OK now.
> 
> CI link is added in JBS.

Fix is tested and working fine.

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

Marked as reviewed by tr (Committer).

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


From aivanov at openjdk.org  Wed Jan  4 19:38:00 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 4 Jan 2023 19:38:00 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v3]
In-Reply-To: <lYAXVRfHlBD3wxhnlk68b5PyjhL0xwIVs9G0weqJ3Y8=.69e8b1d4-13b3-4ce1-ab23-7cdc4df1c097@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <lYAXVRfHlBD3wxhnlk68b5PyjhL0xwIVs9G0weqJ3Y8=.69e8b1d4-13b3-4ce1-ab23-7cdc4df1c097@github.com>
Message-ID: <212vFogi6FjVFiexmbfBPZd-4GywAUKQIMZbr3l3wIs=.e3b7a827-7427-4b46-acad-290d3d4e65c3@github.com>

On Wed, 21 Dec 2022 22:09:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as parameter to method.  
>> 
>> Following are the usual steps for any border scaling -
>> 
>> - Resetting transform.
>> - Calculating new width, height, x & y-translations.
>> - Perform the required border rendering.
>> - And at the end restore the previous transform.
>> 
>> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
>> 
>> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
>> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
>> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
>> 
>> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.
>
> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - minor changes
>  - Merge branch 'master' into RefactorBorder_8294484
>  - Merge branch 'master' into RefactorBorder_8294484
>  - review changes
>  - Refactoring changes
>  - Merge branch 'master' into RefactorBorder_8294484
>  - revert MetalBorder changes
>  - merge master
>  - refactoring changes - initial commit

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 151:

> 149:         void paintUnscaledBorder(Component c, Graphics g, int x, int y,
> 150:                                  int w, int h, double scale, int strokeWidth);
> 151:     }

I think the word _interface_ is redundant in the type name. `UnscaledBorderPainter` is a better name which is more specific and is consistent with Java naming conventions.

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 154:

> 152: 
> 153:     public static void paintBorder(Component c, Graphics g, int x, int y,
> 154:                             int w, int h, PaintInterface paintFunction) {

`painter` could be a better name than `paintFunction`.

Even though a method reference is used as the parameter, here it's still an object that implements the specified interface.

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 157:

> 155: 
> 156:         //STEP 1: RESET TRANSFORM
> 157:         //save old values

Comments usually have a space after the start of comment delimiter.
Suggestion:

        // Step 1: Reset Transform
        
        // Save old values


Avoid capitals, text in all capitals is harder to read.

I suggest adding a blank line between the two comment lines to separate the section header from a comment which goes to a shorter block of code. Or rather remove the second line, this should be self-explanatory.

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 173:

> 171:              * pixel coordinate system instead of the logical coordinate system.
> 172:              */
> 173:             resetTransform = ((at.getShearX() == 0) && (at.getShearY() == 0));

@rajamah's code in `LineBorder.java` used a better condition: if the scale is 1, resetting transform can be safely skipped.

https://github.com/openjdk/jdk/blob/9911405e543dbe07767808bad88534abbcc03c5a/src/java.desktop/share/classes/javax/swing/border/LineBorder.java#L152-L156

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 179:

> 177:                 stkWidth = c instanceof JInternalFrame ?
> 178:                         clipRound(scaleFactor) : (int) Math.floor(scaleFactor);
> 179:                 g2d.setStroke(new BasicStroke((float) stkWidth));

This is supposed to be a generic helper. If `strokeWidth` depends on the type of component, it's better to handle it in each component separately.

`EtchedBorder` uses the stoke, `LineBorder` doesn't use it; however, it uses the value.

So, my suggestion is to calculate the `strokeWidth` (can't we spell it out, it's easier to read this way, isn't it?) as `Math.floor(scaleFactor)`. The stroke itself isn't created, nor is set here.

The stroke can still be restored here as a convenience. What do others think?

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 27:

> 25: package javax.swing.border;
> 26: 
> 27: import com.sun.java.swing.SwingUtilities3;

In JDK code, the convention is to put `com.*` and `sun.*` packages after the standard public API ones under `java.*` and `javax.*`.

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 159:

> 157:         paintBorderShadow(g, (etchType == LOWERED) ? getHighlightColor(c)
> 158:                                                    : getShadowColor(c),
> 159:                           w, h, stroke);

Perhaps, you can preserve the name of the parameter, this will reduce the number of different lines as well as use consistent name in the source file: both `paintBorderShadow` and `paintBorderHighlight` use `stkWidth` as the name for this parameter.

src/java.desktop/share/classes/javax/swing/border/LineBorder.java line 151:

> 149:     private void paintUnscaledBorder(Component c, Graphics g, int x, int y,
> 150:                                      int w, int h, double scale, int stroke) {
> 151:         if (this.thickness > 0) {

I believe this condition should remain the same:


if ((this.thickness > 0) && (g instanceof Graphics2D)) {


After all, the border will not be painted if `g` isn't a `Graphics2D`, as such it makes sense to skip calculating the width and paths.

If you like, pattern matching for `instanceof` can still be used. I'm pretty sure @rajamah didn't use it to ease backporting.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 274:

> 272:             // Draw the bulk of the border
> 273:             for (int i = 0; i <= thickness; i++) {
> 274:                 g.drawRect(i, i, w - (i * 2), h - (i * 2));

The keep the old code intact, use `width` and `height` as parameter names in `paintUnscaledBorder` method.

The same is true for `scaleFactor` above.

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

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


From aivanov at openjdk.org  Wed Jan  4 19:38:02 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 4 Jan 2023 19:38:02 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v3]
In-Reply-To: <mEHRRK-Qn1MbPW6Yp5gy6CAJ3v0suw1GlTMkVEh9Pa0=.be8cc27f-8c96-4aa7-a0eb-a08ca6def622@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <mEHRRK-Qn1MbPW6Yp5gy6CAJ3v0suw1GlTMkVEh9Pa0=.be8cc27f-8c96-4aa7-a0eb-a08ca6def622@github.com>
Message-ID: <1Zw2hxq3TVKSkvlNa1dkDCGJPYahfGgIgKsMsg1kIz0=.35b69048-11e8-4180-ad9e-d887487bd8ad@github.com>

On Sat, 10 Dec 2022 23:08:48 GMT, Rajat Mahajan <duke at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - minor changes
>>  - Merge branch 'master' into RefactorBorder_8294484
>>  - Merge branch 'master' into RefactorBorder_8294484
>>  - review changes
>>  - Refactoring changes
>>  - Merge branch 'master' into RefactorBorder_8294484
>>  - revert MetalBorder changes
>>  - merge master
>>  - refactoring changes - initial commit
>
> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 174:
> 
>> 172: 
>> 173:             if (resetTransform) {
>> 174:                 g2d.setTransform(new AffineTransform());
> 
> Can we keep the original comment about this:
>                 /* Deactivate the HiDPI scaling transform,
>                  * so we can do paint operations in the device
>                  * pixel coordinate system instead of the logical coordinate system.
>                  */

I believe @rajamah meant to put this comment before resetting the transform to explain why it's done.

https://github.com/openjdk/jdk/blob/9911405e543dbe07767808bad88534abbcc03c5a/src/java.desktop/share/classes/javax/swing/border/LineBorder.java#L165-L169

The original comment above for `resetTransform` variable could also be preserved, it explains why we don't reset the transform when shear and/or rotation are used.

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

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


From aivanov at openjdk.org  Wed Jan  4 19:38:04 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 4 Jan 2023 19:38:04 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v3]
In-Reply-To: <r-fO1cAyEc9jKgiS-Ahp9vBTqhbGK8CHl9BNMTTp0vs=.a58fcf2b-3391-4399-99dc-c99a5f7b9d33@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <mEHRRK-Qn1MbPW6Yp5gy6CAJ3v0suw1GlTMkVEh9Pa0=.be8cc27f-8c96-4aa7-a0eb-a08ca6def622@github.com>
 <EqwXPy5ojUzBW9L3qEX1D06C8_OPUwzXy6HEoYMYtMU=.2dfca9d9-66a9-470b-bd78-6511d6080da3@github.com>
 <r-fO1cAyEc9jKgiS-Ahp9vBTqhbGK8CHl9BNMTTp0vs=.a58fcf2b-3391-4399-99dc-c99a5f7b9d33@github.com>
Message-ID: <eGfw0na0LvULd9fxlnQHdDpuXwOG0HxjdhnjeaLuWEk=.8863f886-e328-4965-b969-3e9e9ae4f2c9@github.com>

On Mon, 12 Dec 2022 20:43:39 GMT, Rajat Mahajan <duke at openjdk.org> wrote:

>> @rajamah In-order to paint the border even when g is not a Graphics2D object I have added the `resetTransform` check here again and additionally to keep the if & else block close-by, which is easier to understand rather than having the blocks separated.
>
> sure, makes sense. Thanks

Still, I think it makes sense to combine this block with the above one.

If `resetTransform` is true, the transform is reset and variables are set to the values as calculated in this block; otherwise, the variables are initialised with the default values.

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

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


From achung at openjdk.org  Wed Jan  4 19:56:55 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 4 Jan 2023 19:56:55 GMT
Subject: RFR: 8299553: Make ScaledEtchedBorderTest.java comprehensive [v2]
In-Reply-To: <ujLI0WtXpnGG_bCU0akrzCCiI5c1BiRwvV2XGHIVesg=.21dea1ce-b4d3-4ce6-95fa-f472bfbc22cf@github.com>
References: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>
 <ujLI0WtXpnGG_bCU0akrzCCiI5c1BiRwvV2XGHIVesg=.21dea1ce-b4d3-4ce6-95fa-f472bfbc22cf@github.com>
Message-ID: <ejx_IqshMKsHdXyZMoLL5X01_tSfa7ain1WCgnipGk4=.aaa8e26e-701b-4d28-a3ac-168574d14142@github.com>

On Wed, 4 Jan 2023 16:26:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The `ScaledEtchedBorderTest.java` test ([JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614)) verifies that the thickness of lines of `EtchedBorder` is consistent. The component inside had the same background color as the frame. Yet if there's another component the background of which is different, that background could be seen.
>> 
>> The updated test covers the scenario reported in [JDK-8294921](https://bugs.openjdk.org/browse/JDK-8294921).
>> 
>> The bug itself is fixed by refactoring [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) the border rendering code which uses a more precise coordinate calculation, see #11571. Thus, I contribute the test under a separate bugid.
>> 
>> I also modified `ScaledLineBorderTest.java` so that the location of the child panels is saved when they're created as done in `ScaledTextFieldBorderTest.java` in #11498. I removed the unused `Component` import after this modification from both tests.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move State enum before checkBorder where it's used

Marked as reviewed by achung (Committer).

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

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


From aivanov at openjdk.org  Wed Jan  4 20:09:50 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 4 Jan 2023 20:09:50 GMT
Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java
 fails with AssertionError
In-Reply-To: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
References: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
Message-ID: <48UKR6_TlO_xM-9gXAUT9w2s9TZ2xFlrf7BScr9jkN4=.9f2bc200-1ee2-4046-9096-5fd07fa53b1b@github.com>

On Mon, 26 Dec 2022 05:17:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This assertion happens when we try to build the path linked by the shortcut file when part of that path is not accessible. For example, if the ".lnk" file is pointed to the "windows-update. settings" inside the "Internet.settings". 
> 
> After the change, we will skip the target of the link if any part of the path to the target is not a folder and is not traversable in JFileChooser.

So, to reproduce this issue, one has to put a shortcut (`.lnk` file) which points to a virtual folder which has no file system path, any Control Panel applets or Control Panel itself could trigger this.

Is my understanding correct?

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

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


From serb at openjdk.org  Wed Jan  4 20:47:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 4 Jan 2023 20:47:50 GMT
Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java
 fails with AssertionError
In-Reply-To: <48UKR6_TlO_xM-9gXAUT9w2s9TZ2xFlrf7BScr9jkN4=.9f2bc200-1ee2-4046-9096-5fd07fa53b1b@github.com>
References: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
 <48UKR6_TlO_xM-9gXAUT9w2s9TZ2xFlrf7BScr9jkN4=.9f2bc200-1ee2-4046-9096-5fd07fa53b1b@github.com>
Message-ID: <RpXSEa2ZKAjNi_DXF10N7rPZNDWRZVZ2ErwsexD7Yzg=.f1c4b2c7-161d-4c27-8226-e7a2f38a4f41@github.com>

On Wed, 4 Jan 2023 20:07:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> So, to reproduce this issue, one has to put a shortcut (`.lnk` file) which points to a virtual folder which has no file system path, any Control Panel applets or Control Panel itself could trigger this.
> 
> Is my understanding correct?

The user should actually open that 'place in Control Panel" first so the link will have appeared in the "recent files" folder, the exception occurs when the JFC tries to build a "files tree". This is how I get the lnk file for the test.

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

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


From honkar at openjdk.org  Wed Jan  4 22:41:51 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 4 Jan 2023 22:41:51 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v4]
In-Reply-To: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
Message-ID: <UAdVW4p8MloP1NNFLFgJGUr8mein0dvRyaxJPsdpblc=.e498f3ff-f036-4040-b480-e6a2d06b10aa@github.com>

> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as parameter to method.  
> 
> Following are the usual steps for any border scaling -
> 
> - Resetting transform.
> - Calculating new width, height, x & y-translations.
> - Perform the required border rendering.
> - And at the end restore the previous transform.
> 
> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
> 
> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
> 
> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.

Harshitha Onkar has updated the pull request incrementally with three additional commits since the last revision:

 - review changes
 - Revert "test changes"
   
   This reverts commit abed51bd420941d8efa7b779b86257978f56810e.
 - test changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11571/files
  - new: https://git.openjdk.org/jdk/pull/11571/files/e753cb22..5aad627a

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

  Stats: 102 lines in 4 files changed: 25 ins; 27 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/11571.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11571/head:pull/11571

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


From serb at openjdk.org  Wed Jan  4 22:44:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 4 Jan 2023 22:44:50 GMT
Subject: RFR: 8296934: Write a test to verify whether Undecorated Frame can
 be iconified or not [v2]
In-Reply-To: <siYfHryfixaisS_j3q0QEFvx6LUGUI5CbgkTCQnzUzM=.02d20f7b-d621-411d-bba8-897186edaf5d@github.com>
References: <r2i1ZTPfV1ptIZgIklDtQNuR_vt4plnRmEYXxO6BWD0=.46373c1c-cc38-4a85-bcd5-097e577477ff@github.com>
 <siYfHryfixaisS_j3q0QEFvx6LUGUI5CbgkTCQnzUzM=.02d20f7b-d621-411d-bba8-897186edaf5d@github.com>
Message-ID: <WNjkcEAnQQh0d3Y4O-yVQ6oyXdSUBlQSn0DjOgEtGXs=.b820cf19-042c-4a6e-ac8b-5b0dc66c64f1@github.com>

On Tue, 3 Jan 2023 10:59:36 GMT, Anto J <aj at openjdk.org> wrote:

>> This test case verifies that Undecorated Frame can be iconified or not
>> Using mouse click events generated WINDOW_ACTIVATED, WINDOW_ICONIFIED, WINDOW_DEACTIVATED, and WINDOW_DEICONIFIED and tested whether it is iconified or not.
>
> Anto J has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8296934: Write a test to verify whether Undecorated Frame can be iconified or not

Looks fine, I assume the code was tested in the mach5.

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

Marked as reviewed by serb (Reviewer).

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


From duke at openjdk.org  Wed Jan  4 22:47:56 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Wed, 4 Jan 2023 22:47:56 GMT
Subject: Integrated: 8299296: Write a test to verify the components selection
 sends ItemEvent
In-Reply-To: <0HgEcWPfdikEgz9Qiq5C579YlTEaZ6-UG4wWXS0p7oA=.73a00672-386c-4a78-8bf6-619598a23dbd@github.com>
References: <0HgEcWPfdikEgz9Qiq5C579YlTEaZ6-UG4wWXS0p7oA=.73a00672-386c-4a78-8bf6-619598a23dbd@github.com>
Message-ID: <GnEcXCN6S8d726Ov2p-3Nc1Ai3FWZ7yvuYusmy5lX0Y=.6f9aa608-aefb-4982-b90f-63c6e3775b4d@github.com>

On Sat, 24 Dec 2022 14:40:27 GMT, Ravi Gupta <duke at openjdk.org> wrote:

> This testcase verifies the following assertions
> 
> a. Selecting an item in the Choice using mouse generates ItemEvent.
> b. Single-click on an Checkbox generates ItemEvent.
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos, linux and windows and got all pass.

This pull request has now been integrated.

Changeset: 5ae6de85
Author:    ravi.ra.gupta <ravi.ra.gupta at oracle.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ae6de859d472d107cdf642c417c6d2f1c74e5db
Stats:     130 lines in 1 file changed: 130 ins; 0 del; 0 mod

8299296: Write a test to verify the components selection sends ItemEvent

Reviewed-by: serb

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

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


From abhiscxk at openjdk.org  Wed Jan  4 22:49:03 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 4 Jan 2023 22:49:03 GMT
Subject: Integrated: 8081507: Open or Save button in JFileChooser has OK title
 in GTK LaF
In-Reply-To: <xiAzTly59fGFbv79RPrpnePFxG42TRYmGXrikg8DUKQ=.96d809a6-379e-4943-9e6d-41ac46fbc01f@github.com>
References: <xiAzTly59fGFbv79RPrpnePFxG42TRYmGXrikg8DUKQ=.96d809a6-379e-4943-9e6d-41ac46fbc01f@github.com>
Message-ID: <1e-jMImbxl0uIVD33W3C8SG6jRZKmkqHqQqjMuR5Rws=.5260a58c-274b-401b-865b-2848692d625d@github.com>

On Tue, 27 Dec 2022 19:05:10 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Open or Save button in JFileChooser has OK title in GTK LAF. The open/save button text modified as per the native FileChooser. Manual test case is added.
> 
> `open/test/jdk/sanity/client/SwingSet/src/FileChooserDemoTest.java` failed with the current fix with an exception `**Wait AbstractButton with text "OK" loaded.**` Updated the test for GTK LAF and tested in CI which is OK now.
> 
> CI link is added in JBS.

This pull request has now been integrated.

Changeset: 578c287a
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/578c287a68f38f21a91d200b7a0657aaeb721b3f
Stats:     82 lines in 3 files changed: 78 ins; 0 del; 4 mod

8081507: Open or Save button in JFileChooser has OK title in GTK LaF

Reviewed-by: serb, tr

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

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


From serb at openjdk.org  Thu Jan  5 02:30:14 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 5 Jan 2023 02:30:14 GMT
Subject: RFR: 8299430: Cleanup: delete unnecessary semicolons in
 java.desktop module [v2]
In-Reply-To: <P8_b3ITMyyrFNPDjlKT0aLGCrR4OJTRwpU5i3dseCWA=.651b6d35-034a-4a29-a0a2-7cb8ec6c4fbc@github.com>
References: <P8_b3ITMyyrFNPDjlKT0aLGCrR4OJTRwpU5i3dseCWA=.651b6d35-034a-4a29-a0a2-7cb8ec6c4fbc@github.com>
Message-ID: <luArjM9pdSS1q4MZP1zdxn1AFwAKVpjYlppYWIlYm40=.9416e057-bd12-4c5f-8f78-31d5f42bd467@github.com>

> Small cleanup, unnecessary semicolons are deleted here and there.

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

  native on mac

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11807/files
  - new: https://git.openjdk.org/jdk/pull/11807/files/daeb1e81..fce6bacf

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

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

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


From serb at openjdk.org  Thu Jan  5 03:02:11 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 5 Jan 2023 03:02:11 GMT
Subject: RFR: 8299430: Cleanup: delete unnecessary semicolons in
 java.desktop module [v3]
In-Reply-To: <P8_b3ITMyyrFNPDjlKT0aLGCrR4OJTRwpU5i3dseCWA=.651b6d35-034a-4a29-a0a2-7cb8ec6c4fbc@github.com>
References: <P8_b3ITMyyrFNPDjlKT0aLGCrR4OJTRwpU5i3dseCWA=.651b6d35-034a-4a29-a0a2-7cb8ec6c4fbc@github.com>
Message-ID: <V500fE9WvXtpih4XfWi5MpyKsh3z3PLKjpvqUmhLtSA=.6ce88002-43a8-4647-8fbe-cb2d9fbe48cd@github.com>

> Small cleanup, unnecessary semicolons are deleted here and there.

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

  native on win

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11807/files
  - new: https://git.openjdk.org/jdk/pull/11807/files/fce6bacf..dcfc7510

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

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

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


From duke at openjdk.org  Thu Jan  5 03:20:48 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 5 Jan 2023 03:20:48 GMT
Subject: RFR: 8299430: Cleanup: delete unnecessary semicolons in
 java.desktop module [v3]
In-Reply-To: <V500fE9WvXtpih4XfWi5MpyKsh3z3PLKjpvqUmhLtSA=.6ce88002-43a8-4647-8fbe-cb2d9fbe48cd@github.com>
References: <P8_b3ITMyyrFNPDjlKT0aLGCrR4OJTRwpU5i3dseCWA=.651b6d35-034a-4a29-a0a2-7cb8ec6c4fbc@github.com>
 <V500fE9WvXtpih4XfWi5MpyKsh3z3PLKjpvqUmhLtSA=.6ce88002-43a8-4647-8fbe-cb2d9fbe48cd@github.com>
Message-ID: <29xVKefQ2qWC31ZCb2vjVw9Nx3G-k5Sp9kJezYkcp9o=.e5043d00-61fc-47d2-b32f-f009cbbc37c8@github.com>

On Thu, 5 Jan 2023 03:02:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Small cleanup, unnecessary semicolons are deleted here and there.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   native on win

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

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

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


From serb at openjdk.org  Thu Jan  5 03:57:49 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 5 Jan 2023 03:57:49 GMT
Subject: RFR: 8299430: Cleanup: delete unnecessary semicolons in
 java.desktop module
In-Reply-To: <sTfbuI6Yq-StUdBAazFOaWEQC895zTLfI2WeRH0Wbf4=.c1cc3fb7-ab69-45d9-ab78-fc2893a70d07@github.com>
References: <P8_b3ITMyyrFNPDjlKT0aLGCrR4OJTRwpU5i3dseCWA=.651b6d35-034a-4a29-a0a2-7cb8ec6c4fbc@github.com>
 <sTfbuI6Yq-StUdBAazFOaWEQC895zTLfI2WeRH0Wbf4=.c1cc3fb7-ab69-45d9-ab78-fc2893a70d07@github.com>
Message-ID: <20wdsZZEBZNO0DR0Etv-JFKhKyzsxY2T5BwIDVG28pw=.bba98282-27df-4c00-aeb1-134644d682b8@github.com>

On Tue, 3 Jan 2023 11:30:14 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> I see that this PR touches only java files. A few native files have these type of typos as well. I think, it is worth cleaning them as well.

"A few" is too optimistic, we have thousand empty statements caused by the semicolons. Most of them caused by using macro, I did not touch that for now and changed only the obvious issues.

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

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


From smandalika at openjdk.org  Thu Jan  5 05:02:25 2023
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Thu, 5 Jan 2023 05:02:25 GMT
Subject: RFR: 8298921: Create a regression test for JDK-8139581 [v2]
In-Reply-To: <lkasNa1F7wgDFUbBBlSzzve1p3DmJHqmyV6ELZd_BQs=.51d1cbf0-3c97-40d4-8892-d6c214674d94@github.com>
References: <lkasNa1F7wgDFUbBBlSzzve1p3DmJHqmyV6ELZd_BQs=.51d1cbf0-3c97-40d4-8892-d6c214674d94@github.com>
Message-ID: <ucRjjhbt1vd5o66HQssT7S5ARVd_0etagCsYCe5eVxk=.e6c0fe00-7749-414b-bd80-a89d5596db78@github.com>

> Create a regression test for JDK-8139581
> 
> As described in JDK-8139581, when an AWT panel with AWT components, for example "java.awt.Button", is removed from AWT frame and added again to the same frame, then some AWT components contained in the panel are not drawn, however, clicking in the area of not drawn button leads to drawing of the button.
> 
> Test has a swing and awt component in a panel. It then removes and adds back the panel from/into the frame, to verify that they are repainted back properly.

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

  8298921: Fixed review comments, rethrow exception

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11707/files
  - new: https://git.openjdk.org/jdk/pull/11707/files/e415709b..5ee77935

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

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

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


From tr at openjdk.org  Thu Jan  5 05:34:31 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 5 Jan 2023 05:34:31 GMT
Subject: RFR: 8299309: Test
 "java/awt/Dialog/ModalDialogTest/ModalDialogTest.java" fails because new frame
 was not displayed when "New Frame" button was clicked
Message-ID: <br2h0HuFz8KcbRSyzPJeqj-_gLWwYf5yn4Wi17z76tk=.8ec014f8-a081-4cf1-98f8-fafe20d83c5c@github.com>

Windows count check was added as part of [JDK-8290469](https://bugs.openjdk.org/browse/JDK-8290469) fix, to avoid window positional shift which happens during application startup. The condition handled only for windows type of Window and not for Frame/Dialog which is the root cause for the bug. I have updated the condition for other Window types as a fix.

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

Commit messages:
 - Fix

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

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


From aghaisas at openjdk.org  Thu Jan  5 05:42:49 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 5 Jan 2023 05:42:49 GMT
Subject: RFR: 8299430: Cleanup: delete unnecessary semicolons in
 java.desktop module [v3]
In-Reply-To: <V500fE9WvXtpih4XfWi5MpyKsh3z3PLKjpvqUmhLtSA=.6ce88002-43a8-4647-8fbe-cb2d9fbe48cd@github.com>
References: <P8_b3ITMyyrFNPDjlKT0aLGCrR4OJTRwpU5i3dseCWA=.651b6d35-034a-4a29-a0a2-7cb8ec6c4fbc@github.com>
 <V500fE9WvXtpih4XfWi5MpyKsh3z3PLKjpvqUmhLtSA=.6ce88002-43a8-4647-8fbe-cb2d9fbe48cd@github.com>
Message-ID: <7YKJP3-L3DgwxxXi44K329_sO_nDW6TKntqLnFpC5lQ=.b583121b-4419-457f-b173-e17c33c2b6dc@github.com>

On Thu, 5 Jan 2023 03:02:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Small cleanup, unnecessary semicolons are deleted here and there.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   native on win

Marked as reviewed by aghaisas (Reviewer).

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

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


From abhiscxk at openjdk.org  Thu Jan  5 05:51:52 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 5 Jan 2023 05:51:52 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel [v2]
In-Reply-To: <9YWHXTWcAEWeM_tWUzbqxwN1EZjmsgbH4H1PYuo0KRA=.82e80c86-42da-4066-a1f8-31c8f1a383cc@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
 <IUkFswHdUwx2qx6lj6pEWtsAd6yS7N6EQj4G4iV_OMM=.d3edd5a8-6bbe-4540-b1b5-0be110f1410a@github.com>
 <9YWHXTWcAEWeM_tWUzbqxwN1EZjmsgbH4H1PYuo0KRA=.82e80c86-42da-4066-a1f8-31c8f1a383cc@github.com>
Message-ID: <u5s7QSUC3iNBeUHF-TMrEx5BmkeYSBMJu75HK_U1GEM=.e4af4759-190c-4f65-b43f-fda3f9658672@github.com>

On Tue, 3 Jan 2023 01:21:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Review comment update
>>  - Merge
>>  - Merge
>>  - Combobox componnet rendering fix
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java line 372:
> 
>> 370:                             arrowButton.getPreferredSize().width;
>> 371:         //adjust the size based on the button width
>> 372:         size.height += insets.top + insets.bottom + arrowInsets.top
> 
> Are you sure that the arrow insets should be applied on top of the component's insets, probably the maximum of both should be selected?

@mrserb Are you ok with the fix or do you want anything to add?

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

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


From tr at openjdk.org  Thu Jan  5 05:58:48 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 5 Jan 2023 05:58:48 GMT
Subject: RFR: 8299306: Test
 "javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java" fails on
 Windows 10 x64 because there are some buttons did not display button name
In-Reply-To: <nb2XebuqQTexBaybLdEjdtlaG4ZlcH8WQNuLHKEcQQk=.a66207c5-f6cf-411f-b302-1d57dd5be1b7@github.com>
References: <nb2XebuqQTexBaybLdEjdtlaG4ZlcH8WQNuLHKEcQQk=.a66207c5-f6cf-411f-b302-1d57dd5be1b7@github.com>
Message-ID: <uHVfJnDEw_AQXFXhDj5JO17xEfUSxOD796RimJZ7M_o=.b90ace67-e44c-4a96-97ba-8cc343d3df1a@github.com>

On Tue, 3 Jan 2023 07:08:13 GMT, Tejesh R <tr at openjdk.org> wrote:

> When JFilechooser is added to a frame, the control buttons are disabled. Since in the test the control buttons are not required since JFilechooser is added to a JFrame and in turn frame disposal is handled by PassFailJFrame. The fix is to disable JFileChooser control buttons.

I have created a new bug for the size issue - [JDK-8299522](https://bugs.openjdk.org/browse/JDK-8299522)

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

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


From serb at openjdk.org  Thu Jan  5 06:02:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 5 Jan 2023 06:02:50 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v3]
In-Reply-To: <23xwHp6apwTTidFVoGzCjc-oSkW7v8hOVFZ4D_lP6c0=.eba74ea0-5731-4c4a-a971-95ec36248796@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <23xwHp6apwTTidFVoGzCjc-oSkW7v8hOVFZ4D_lP6c0=.eba74ea0-5731-4c4a-a971-95ec36248796@github.com>
Message-ID: <8-Qh-l8Od7ysNSRSIX7LwpT_PXpYMF_VVcvlgKflKOg=.edcc8872-59d6-4e55-a207-24908c4dd41e@github.com>

On Thu, 29 Dec 2022 06:22:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
>> says:
>> "...MetalLookAndFeel registers an entry for each of the classes
>> in the package javax.swing.plaf.metal that are named MetalXXXUI.
>> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
>> that do not have a class in metal, the corresponding class in
>> javax.swing.plaf.basic is used. For example, metal does not
>> have a class named "MetalColorChooserUI", as such,
>> javax.swing.plaf.basic.BasicColorChooserUI is used".
>> 
>> There is class MetalMenuBarUI, but the method populates given defaults table with the value
>> "javax.swing.plaf.basic.BasicMenuBarUI".
>> 
>> Added entry for MetalMenuBarUI..
>> CI tests including JCK tests are ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spec update

Looks fine to me, I hope @aivanov-jdk or @prrace will check the exact wording.

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

Marked as reviewed by serb (Reviewer).

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


From serb at openjdk.org  Thu Jan  5 06:03:56 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 5 Jan 2023 06:03:56 GMT
Subject: [jdk20] RFR: 8299227: host `exif.org` not found in link in doc
 comment [v2]
In-Reply-To: <NRHvZpQ3Gp9yKf_1a8dNiSad35wV5KWtvzroRJaEC1Y=.cfbeea84-3d6c-40a8-971b-82b41ef84d6a@github.com>
References: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
 <CkBcNmCs96sP6ou8iSrMzqKa06tGQXkln-PNeDC1WOw=.360d4fb6-8b23-409d-8892-349fda6b806d@github.com>
 <0LINf1R5FoZStKMSlimveknC42QeZDxLIsNPYaFDXjA=.c08df247-13eb-4c2f-bdf3-b46bb61ca891@github.com>
 <GAsu9kNA_vxUcRuE_SXMaH8GC2LvallS_qnzCncal5k=.5c2c2765-b06c-4eb5-beaf-c2a1e6d6dbbc@github.com>
 <jajjPkrDk6xVnowdBFlrh3w5tKAGqjrtnNqDdWwYiis=.4e1ed866-8b70-41cc-9b49-4d7b3a8dfb67@github.com>
 <NRHvZpQ3Gp9yKf_1a8dNiSad35wV5KWtvzroRJaEC1Y=.cfbeea84-3d6c-40a8-971b-82b41ef84d6a@github.com>
Message-ID: <qt8vDezkjTxlzL4ybvjQUM58xeD5RhpK3VZC76kNy0o=.81345c76-0615-4404-a4f2-db1b6e1befa3@github.com>

On Fri, 23 Dec 2022 19:44:33 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> I found the webarchive myself yesterday, I did not think it a suitable link for JDK.
>> Since you haven't found a suitable link for 2.2, I think an update to 2.3 is best mainly because it seems a better place to link to.
>
> Updated to version 2.3.

Can we place that document somewhere(I think that is not easy but still) and provide a link to it?

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

PR: https://git.openjdk.org/jdk20/pull/74


From iris at openjdk.org  Thu Jan  5 07:39:49 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 5 Jan 2023 07:39:49 GMT
Subject: RFR: 8299430: Cleanup: delete unnecessary semicolons in
 java.desktop module [v3]
In-Reply-To: <V500fE9WvXtpih4XfWi5MpyKsh3z3PLKjpvqUmhLtSA=.6ce88002-43a8-4647-8fbe-cb2d9fbe48cd@github.com>
References: <P8_b3ITMyyrFNPDjlKT0aLGCrR4OJTRwpU5i3dseCWA=.651b6d35-034a-4a29-a0a2-7cb8ec6c4fbc@github.com>
 <V500fE9WvXtpih4XfWi5MpyKsh3z3PLKjpvqUmhLtSA=.6ce88002-43a8-4647-8fbe-cb2d9fbe48cd@github.com>
Message-ID: <LfkbUecF_Z0P4votlhD5aumzk_j4duUZk7bgZsENFiM=.1551f2d5-ff19-41fc-9838-eab563c42463@github.com>

On Thu, 5 Jan 2023 03:02:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Small cleanup, unnecessary semicolons are deleted here and there.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   native on win

Marked as reviewed by iris (Reviewer).

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

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


From aj at openjdk.org  Thu Jan  5 07:42:49 2023
From: aj at openjdk.org (Anto J)
Date: Thu, 5 Jan 2023 07:42:49 GMT
Subject: RFR: 8296934: Write a test to verify whether Undecorated Frame can
 be iconified or not [v2]
In-Reply-To: <WNjkcEAnQQh0d3Y4O-yVQ6oyXdSUBlQSn0DjOgEtGXs=.b820cf19-042c-4a6e-ac8b-5b0dc66c64f1@github.com>
References: <r2i1ZTPfV1ptIZgIklDtQNuR_vt4plnRmEYXxO6BWD0=.46373c1c-cc38-4a85-bcd5-097e577477ff@github.com>
 <siYfHryfixaisS_j3q0QEFvx6LUGUI5CbgkTCQnzUzM=.02d20f7b-d621-411d-bba8-897186edaf5d@github.com>
 <WNjkcEAnQQh0d3Y4O-yVQ6oyXdSUBlQSn0DjOgEtGXs=.b820cf19-042c-4a6e-ac8b-5b0dc66c64f1@github.com>
Message-ID: <kdMI9XTgVKywilpPvnQL9vTFdbOltdW-kOaOFXkUPj4=.403438e4-dbe7-4d90-9b07-8ed9b59b8c9b@github.com>

On Wed, 4 Jan 2023 22:42:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Looks fine, I assume the code was tested in the mach5.

Yes, It's working fine in mach5

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

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


From abhiscxk at openjdk.org  Thu Jan  5 08:47:59 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 5 Jan 2023 08:47:59 GMT
Subject: [jdk20] RFR: 8299227: host `exif.org` not found in link in doc
 comment [v2]
In-Reply-To: <qt8vDezkjTxlzL4ybvjQUM58xeD5RhpK3VZC76kNy0o=.81345c76-0615-4404-a4f2-db1b6e1befa3@github.com>
References: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
 <CkBcNmCs96sP6ou8iSrMzqKa06tGQXkln-PNeDC1WOw=.360d4fb6-8b23-409d-8892-349fda6b806d@github.com>
 <0LINf1R5FoZStKMSlimveknC42QeZDxLIsNPYaFDXjA=.c08df247-13eb-4c2f-bdf3-b46bb61ca891@github.com>
 <GAsu9kNA_vxUcRuE_SXMaH8GC2LvallS_qnzCncal5k=.5c2c2765-b06c-4eb5-beaf-c2a1e6d6dbbc@github.com>
 <jajjPkrDk6xVnowdBFlrh3w5tKAGqjrtnNqDdWwYiis=.4e1ed866-8b70-41cc-9b49-4d7b3a8dfb67@github.com>
 <NRHvZpQ3Gp9yKf_1a8dNiSad35wV5KWtvzroRJaEC1Y=.cfbeea84-3d6c-40a8-971b-82b41ef84d6a@github.com>
 <qt8vDezkjTxlzL4ybvjQUM58xeD5RhpK3VZC76kNy0o=.81345c76-0615-4404-a4f2-db1b6e1befa3@github.com>
Message-ID: <csQoaoYWu95A6f-0Ro0A39F91Kp-FB1C0jzRb4w0ti4=.06cb286e-ba03-4cfb-9845-d0f1cdaaf891@github.com>

On Thu, 5 Jan 2023 06:01:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Updated to version 2.3.
>
> Can we place that document somewhere(I think that is not easy but still) and provide a link to it?

Did you mean this docment `https://www.kodak.com/global/plugins/acrobat/en/service/digCam/exifStandard2.pdf` ?

I am not sure if we can do this.

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

PR: https://git.openjdk.org/jdk20/pull/74


From serb at openjdk.org  Thu Jan  5 08:50:55 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 5 Jan 2023 08:50:55 GMT
Subject: Integrated: 8299430: Cleanup: delete unnecessary semicolons in
 java.desktop module
In-Reply-To: <P8_b3ITMyyrFNPDjlKT0aLGCrR4OJTRwpU5i3dseCWA=.651b6d35-034a-4a29-a0a2-7cb8ec6c4fbc@github.com>
References: <P8_b3ITMyyrFNPDjlKT0aLGCrR4OJTRwpU5i3dseCWA=.651b6d35-034a-4a29-a0a2-7cb8ec6c4fbc@github.com>
Message-ID: <7WZak26CQILl0kyTKi_wvX5HFmcYl9rf2n4rgK7GtMY=.543f19ff-69dc-4e17-9bd2-81647e4e798b@github.com>

On Mon, 2 Jan 2023 07:20:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Small cleanup, unnecessary semicolons are deleted here and there.

This pull request has now been integrated.

Changeset: e7361cb7
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7361cb746cf00984dd5193ec8a8cc90e1e5a39b
Stats:     123 lines in 92 files changed: 0 ins; 4 del; 119 mod

8299430: Cleanup: delete unnecessary semicolons in java.desktop module

Reviewed-by: stsypanov, aghaisas, iris

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

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


From smandalika at openjdk.org  Thu Jan  5 09:58:16 2023
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Thu, 5 Jan 2023 09:58:16 GMT
Subject: RFR: 8298921: Create a regression test for JDK-8139581 [v3]
In-Reply-To: <lkasNa1F7wgDFUbBBlSzzve1p3DmJHqmyV6ELZd_BQs=.51d1cbf0-3c97-40d4-8892-d6c214674d94@github.com>
References: <lkasNa1F7wgDFUbBBlSzzve1p3DmJHqmyV6ELZd_BQs=.51d1cbf0-3c97-40d4-8892-d6c214674d94@github.com>
Message-ID: <UFscZWoknYQIrRtNFuBOOuSK2RreVRuw1pLOJKi9EFY=.5ebe8d8a-4fc7-47ae-9f95-4019fecf3903@github.com>

> Create a regression test for JDK-8139581
> 
> As described in JDK-8139581, when an AWT panel with AWT components, for example "java.awt.Button", is removed from AWT frame and added again to the same frame, then some AWT components contained in the panel are not drawn, however, clicking in the area of not drawn button leads to drawing of the button.
> 
> Test has a swing and awt component in a panel. It then removes and adds back the panel from/into the frame, to verify that they are repainted back properly.

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

  8298921: Fixed whitespaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11707/files
  - new: https://git.openjdk.org/jdk/pull/11707/files/5ee77935..4d55e825

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

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

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


From psadhukhan at openjdk.org  Thu Jan  5 12:05:48 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 5 Jan 2023 12:05:48 GMT
Subject: RFR: 8299306: Test
 "javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java" fails on
 Windows 10 x64 because there are some buttons did not display button name
In-Reply-To: <nb2XebuqQTexBaybLdEjdtlaG4ZlcH8WQNuLHKEcQQk=.a66207c5-f6cf-411f-b302-1d57dd5be1b7@github.com>
References: <nb2XebuqQTexBaybLdEjdtlaG4ZlcH8WQNuLHKEcQQk=.a66207c5-f6cf-411f-b302-1d57dd5be1b7@github.com>
Message-ID: <mbAx8-kKuTSkkywccf-3Bp3DVZ13sYo19FEDkR9AYDE=.e59661a8-31e1-4276-9475-915fca71f9f9@github.com>

On Tue, 3 Jan 2023 07:08:13 GMT, Tejesh R <tr at openjdk.org> wrote:

> When JFilechooser is added to a frame, the control buttons are disabled. Since in the test the control buttons are not required since JFilechooser is added to a JFrame and in turn frame disposal is handled by PassFailJFrame. The fix is to disable JFileChooser control buttons.

Marked as reviewed by psadhukhan (Reviewer).

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

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


From aturbanov at openjdk.org  Thu Jan  5 16:52:57 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 5 Jan 2023 16:52:57 GMT
Subject: Integrated: 8298449: Unnecessary Vector usage in
 MetaData.ProxyPersistenceDelegate
In-Reply-To: <EuE_osZPhPoAjRSX6B_WMCzdf6NwjBARBLitLQIgeEQ=.37af7798-a198-4e7f-b5d5-4e6427b2057b@github.com>
References: <EuE_osZPhPoAjRSX6B_WMCzdf6NwjBARBLitLQIgeEQ=.37af7798-a198-4e7f-b5d5-4e6427b2057b@github.com>
Message-ID: <cWvot8YPcVAc9J0_lx4WoJS-9dxNYqk895O4JTeOIgw=.6b326c2b-0e17-4df3-a369-54fecf043817@github.com>

On Fri, 11 Nov 2022 07:00:52 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Vector<Object> args` is used only in single method and then it converted to `Object[]`.
> So we can avoid usage of legacy synchronized `Vector` here and use `ArrayList` instead.

This pull request has now been integrated.

Changeset: b908388e
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b908388e817e9bf30c8558b53efc9b2ddf2bad75
Stats:     7 lines in 1 file changed: 2 ins; 1 del; 4 mod

8298449: Unnecessary Vector usage in MetaData.ProxyPersistenceDelegate

Reviewed-by: serb

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

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


From honkar at openjdk.org  Thu Jan  5 17:03:51 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 5 Jan 2023 17:03:51 GMT
Subject: RFR: 8299309: Test
 "java/awt/Dialog/ModalDialogTest/ModalDialogTest.java" fails because new frame
 was not displayed when "New Frame" button was clicked
In-Reply-To: <br2h0HuFz8KcbRSyzPJeqj-_gLWwYf5yn4Wi17z76tk=.8ec014f8-a081-4cf1-98f8-fafe20d83c5c@github.com>
References: <br2h0HuFz8KcbRSyzPJeqj-_gLWwYf5yn4Wi17z76tk=.8ec014f8-a081-4cf1-98f8-fafe20d83c5c@github.com>
Message-ID: <LFFfLvi9xVzg7Ds55ln-FGRHX1i3lLF_mz4NQeAJB30=.b6cdaaa2-3c58-4253-b631-eb7ee2750f60@github.com>

On Thu, 5 Jan 2023 05:26:26 GMT, Tejesh R <tr at openjdk.org> wrote:

> Windows count check was added as part of [JDK-8290469](https://bugs.openjdk.org/browse/JDK-8290469) fix, to avoid window positional shift which happens during application startup. The condition handled only for windows type of Window and not for Frame/Dialog which is the root cause for the bug. I have updated the condition for other Window types as a fix.

Fix looks good.

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

Marked as reviewed by honkar (Committer).

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


From angorya at openjdk.org  Thu Jan  5 17:29:48 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 5 Jan 2023 17:29:48 GMT
Subject: RFR: 8298876: Swing applications do not get repainted coming out
 of sleep on Windows 10
In-Reply-To: <4Rwd2whqzEDkIp18wA5Gug64zbPWMzrRUNLyJ4GVJE8=.81f3f83c-df7d-40cf-9e22-25e5035435ad@github.com>
References: <4Rwd2whqzEDkIp18wA5Gug64zbPWMzrRUNLyJ4GVJE8=.81f3f83c-df7d-40cf-9e22-25e5035435ad@github.com>
Message-ID: <PRayJWBiu673CaL3KCmXUZ1WuwVDRF1X1dYKlFwJ7LY=.a666623a-b561-41d8-99e7-699ee03302e1@github.com>

On Mon, 2 Jan 2023 08:24:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This is a revert of commit https://github.com/openjdk/jdk/commit/415bf44191632cd8dbcc158c0ff0992c0b61c3ba
> which was a fix for 8275715: D3D pipeline processes multiple PaintEvent at initial drawing 
> as it is causing some repaint issue and also since the regression test is known to fail in some systems and is currently problemlisted which suggests the fix was half-baked.
> 
> Raised a new issue for the same https://bugs.openjdk.org/browse/JDK-8299436

The issue disappears with this change.  Many thanks!

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

Marked as reviewed by angorya (no project role).

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


From honkar at openjdk.org  Thu Jan  5 19:03:17 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 5 Jan 2023 19:03:17 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v5]
In-Reply-To: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
Message-ID: <LQryZvfoeTq3YYiQzSE6SaDiDgMnSRFnaPxNLDtPf9U=.d7efc83c-90d8-44f6-86c0-4a3244787f80@github.com>

> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as parameter to method.  
> 
> Following are the usual steps for any border scaling -
> 
> - Resetting transform.
> - Calculating new width, height, x & y-translations.
> - Perform the required border rendering.
> - And at the end restore the previous transform.
> 
> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
> 
> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
> 
> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.

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

  moved strokeWidth logic to individual classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11571/files
  - new: https://git.openjdk.org/jdk/pull/11571/files/5aad627a..98e7b074

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

  Stats: 40 lines in 4 files changed: 17 ins; 8 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/11571.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11571/head:pull/11571

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


From honkar at openjdk.org  Thu Jan  5 19:03:18 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 5 Jan 2023 19:03:18 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v4]
In-Reply-To: <UAdVW4p8MloP1NNFLFgJGUr8mein0dvRyaxJPsdpblc=.e498f3ff-f036-4040-b480-e6a2d06b10aa@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <UAdVW4p8MloP1NNFLFgJGUr8mein0dvRyaxJPsdpblc=.e498f3ff-f036-4040-b480-e6a2d06b10aa@github.com>
Message-ID: <ERp6sDkQGubAgfcSFdruZOHH9IOGyWrTQNYAQrvnQH8=.90d9301b-9872-4f84-a806-6828a0f4d58d@github.com>

On Wed, 4 Jan 2023 22:41:51 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as parameter to method.  
>> 
>> Following are the usual steps for any border scaling -
>> 
>> - Resetting transform.
>> - Calculating new width, height, x & y-translations.
>> - Perform the required border rendering.
>> - And at the end restore the previous transform.
>> 
>> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
>> 
>> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
>> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
>> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
>> 
>> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.
>
> Harshitha Onkar has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - review changes
>  - Revert "test changes"
>    
>    This reverts commit abed51bd420941d8efa7b779b86257978f56810e.
>  - test changes

Since strokeWidth is set differently in each case, it has been moved from common code to individual classes.

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

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


From prr at openjdk.org  Thu Jan  5 19:05:50 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 5 Jan 2023 19:05:50 GMT
Subject: RFR: 8298876: Swing applications do not get repainted coming out
 of sleep on Windows 10
In-Reply-To: <4Rwd2whqzEDkIp18wA5Gug64zbPWMzrRUNLyJ4GVJE8=.81f3f83c-df7d-40cf-9e22-25e5035435ad@github.com>
References: <4Rwd2whqzEDkIp18wA5Gug64zbPWMzrRUNLyJ4GVJE8=.81f3f83c-df7d-40cf-9e22-25e5035435ad@github.com>
Message-ID: <OpmtwTuXj7_1A8mcxA2Hd-WomkTnvTzALzVE_nhfs8k=.e630fc0c-7bc4-41ee-b181-8ac609e4a9c8@github.com>

On Mon, 2 Jan 2023 08:24:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This is a revert of commit https://github.com/openjdk/jdk/commit/415bf44191632cd8dbcc158c0ff0992c0b61c3ba
> which was a fix for 8275715: D3D pipeline processes multiple PaintEvent at initial drawing 
> as it is causing some repaint issue and also since the regression test is known to fail in some systems and is currently problemlisted which suggests the fix was half-baked.
> 
> Raised a new issue for the same https://bugs.openjdk.org/browse/JDK-8299436

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Thu Jan  5 20:06:58 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 5 Jan 2023 20:06:58 GMT
Subject: [jdk20] RFR: 8299227: host `exif.org` not found in link in doc
 comment [v3]
In-Reply-To: <CSY2Hm3PVq5HPG8BrA2Hsr3YHG0jnfbycbp4mSdbr7A=.5f944f1b-dc09-43c5-9220-9e5e33a3534d@github.com>
References: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
 <CSY2Hm3PVq5HPG8BrA2Hsr3YHG0jnfbycbp4mSdbr7A=.5f944f1b-dc09-43c5-9220-9e5e33a3534d@github.com>
Message-ID: <VQnF7AJSz3y7GKLvo6HX7xa7t35KRojDYDSVbso1DSU=.4e7f0170-aa82-478d-9ddf-9482877a80f9@github.com>

On Fri, 23 Dec 2022 19:48:02 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Reported broken links are updated accordingly.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Links and spec version update

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/74


From prr at openjdk.org  Thu Jan  5 20:16:53 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 5 Jan 2023 20:16:53 GMT
Subject: RFR: 8298240: Replace the usage of ImageLayoutException by the
 CMMException [v2]
In-Reply-To: <Al4VrMYfp2BWmJr-fOhXBd95NZTOxuCrnpDipj28Xg4=.fb982ce5-c96a-4dba-a7c7-542a3d13c0d2@github.com>
References: <MugzKoEie2il8Rn7Tp4oLM0N8zg-QtGh1gsQmPPX-lE=.66e63bba-76ef-4425-8aa6-6a2350d77c24@github.com>
 <Al4VrMYfp2BWmJr-fOhXBd95NZTOxuCrnpDipj28Xg4=.fb982ce5-c96a-4dba-a7c7-542a3d13c0d2@github.com>
Message-ID: <qaoNpyj3Sfd-ls_Z1yPHTFvpA5GwxJ5Q-adZ4lA5Iec=.e14ee201-872b-4c13-8674-58d4802670d5@github.com>

On Fri, 30 Dec 2022 07:22:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> ImageLayoutException is used to report any issues with image layout calculation. But since we cannot throw the unspecified exception to the application, all usages of ImageLayoutException are wrapped by the CMMException. And now if such CMMException occurs we have lost at what point the initial exception was raised.
>> 
>> We can pass some additional data around, but it looks like we can just delete the ImageLayoutException and use CMMException instead. 
>> 
>> Additionally:
>>  * The `public` keyword is removed in a few places if not needed.
>>  * The PT_XX flags are updated to make it clearly visible how they are related.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into delete_imagelayout
>  - Simplify rge PT_XXX and replace public
>  - delete ImageLayoutException

Seems reasonable to me.

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

Marked as reviewed by prr (Reviewer).

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


From prr at openjdk.org  Thu Jan  5 20:22:50 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 5 Jan 2023 20:22:50 GMT
Subject: RFR: 4934362: see also refers to self
In-Reply-To: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
References: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
Message-ID: <gCXmjqJMWaT4FHeELv3Ywuj0UEb56Jq0sBSslmgitSo=.e6f4c669-9067-4f66-8107-1f4e4494c1bf@github.com>

On Tue, 3 Jan 2023 06:00:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Some methods and constants has a hyperreference to self in javadoc which is rectified to reference proper methods

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Thu Jan  5 20:49:53 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 5 Jan 2023 20:49:53 GMT
Subject: RFR: 8299412 JNI call of getAccessibleActionCount on a wrong
 thread [v2]
In-Reply-To: <V021dlf9P3wKJrijtcLHYZFw5baJsO9VMnG3Cnuv4NM=.254a5b3b-c542-4ea1-9a76-936c3c5beb1d@github.com>
References: <qZquaGznBhIRJMHMZ0mjEeg26LrwgnIyUOW9vkmr0vQ=.4b4f82ac-beea-4d45-8f0e-7c552844e80b@github.com>
 <V021dlf9P3wKJrijtcLHYZFw5baJsO9VMnG3Cnuv4NM=.254a5b3b-c542-4ea1-9a76-936c3c5beb1d@github.com>
Message-ID: <KpPI2dc2w_IrKwmgHgLf0ojOvRhdIHRu-BaSMoh2Q1I=.67ef8fa6-ca8a-4670-ba08-0c9eba4baebf@github.com>

On Thu, 29 Dec 2022 20:41:04 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> [CommonComponentAccessibility getActionsWithEnv:] defines the getAccessibleActionCount method on the AccessibleAction class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.
>> 
>> @azuev-java @mrserb @prrace please review
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   There's a more compact way of doing this:

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Thu Jan  5 20:49:54 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 5 Jan 2023 20:49:54 GMT
Subject: RFR: 8299412 JNI call of getAccessibleActionCount on a wrong
 thread [v2]
In-Reply-To: <JfhakyBmut0SFSCpDIZZ5X9RFUp9A7ZrKhKz_ZbKlGE=.33fe1caf-8b16-49bf-9881-8ef0599d14e3@github.com>
References: <qZquaGznBhIRJMHMZ0mjEeg26LrwgnIyUOW9vkmr0vQ=.4b4f82ac-beea-4d45-8f0e-7c552844e80b@github.com>
 <V021dlf9P3wKJrijtcLHYZFw5baJsO9VMnG3Cnuv4NM=.254a5b3b-c542-4ea1-9a76-936c3c5beb1d@github.com>
 <JfhakyBmut0SFSCpDIZZ5X9RFUp9A7ZrKhKz_ZbKlGE=.33fe1caf-8b16-49bf-9881-8ef0599d14e3@github.com>
Message-ID: <VeEa-O_RCYg6ZGx3gFn_nn9O8OlwnTL7PrDuPXrjXoo=.9bdaa65f-49c4-44a0-a0df-3f2d754a6436@github.com>

On Fri, 30 Dec 2022 06:53:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   There's a more compact way of doing this:
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 605:
> 
>> 603:         DECLARE_STATIC_METHOD(jm_getAccessibleActionCount, sjc_CAccessibility, "getAccessibleActionCount", "(Ljavax/accessibility/AccessibleAction;Ljava/awt/Component;)I");
>> 604:         jint count = (*env)->CallStaticIntMethod(env, sjc_CAccessibility, jm_getAccessibleActionCount, axAction, fComponent);
>> 605:         CHECK_EXCEPTION();
> 
> Do we need to call "(*env)->DeleteLocalRef(env, axAction);" in case of error in CHECK_EXCEPTION?

I think we still reach the DeleteLocalRef that's further down at line 624

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

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


From prr at openjdk.org  Thu Jan  5 21:40:49 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 5 Jan 2023 21:40:49 GMT
Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java
 fails with AssertionError
In-Reply-To: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
References: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
Message-ID: <KVfhRha1a1CQ52b9KNy_4eUby60HaLY4v16KmRdzfUk=.1b5161f0-f180-4905-9520-dc373409819d@github.com>

On Mon, 26 Dec 2022 05:17:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This assertion happens when we try to build the path linked by the shortcut file when part of that path is not accessible. For example, if the ".lnk" file is pointed to the "windows-update. settings" inside the "Internet.settings". 
> 
> After the change, we will skip the target of the link if any part of the path to the target is not a folder and is not traversable in JFileChooser.

What do people mean by Control Panel ? Do you mean Windows (File) Explorer ?
If you do mean Control Panel I think I need a picture or two to show me how that affects FileChooser.
Is that lnk file format something that is "stable" across Windows releases ?

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

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


From aivanov at openjdk.org  Thu Jan  5 22:06:49 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 5 Jan 2023 22:06:49 GMT
Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java
 fails with AssertionError
In-Reply-To: <KVfhRha1a1CQ52b9KNy_4eUby60HaLY4v16KmRdzfUk=.1b5161f0-f180-4905-9520-dc373409819d@github.com>
References: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
 <KVfhRha1a1CQ52b9KNy_4eUby60HaLY4v16KmRdzfUk=.1b5161f0-f180-4905-9520-dc373409819d@github.com>
Message-ID: <O1yLUIpUe7SlS4TOPDKyiHFRr2H1O91oraTCksE2iyI=.7f0838fc-92a7-4cc4-bfce-9a3f4ce15f3b@github.com>

On Thu, 5 Jan 2023 21:38:08 GMT, Phil Race <prr at openjdk.org> wrote:

> What do people mean by Control Panel ? Do you mean Windows (File) Explorer ? If you do mean Control Panel I think I need a picture or two to show me how that affects FileChooser. Is that lnk file format something that is "stable" across Windows releases ?

I mean the classical Control Panel that's launched in Windows Explorer as opposed to the modern Settings app.

A shortcut, `.lnk`, can point to any object in the Shell namespace (a COM object) not only to objects on file system.

>From [the linked email](https://mail.openjdk.org/pipermail/awt-dev/2019-November/015494.html), I infer there's `The Internet` object (on a desktop? ) which is marked with `ATTRIB_BROWSABLE` but not `ATTRIB_FOLDER`. That is the Windows (File) Explorer can navigate to this object, yet JFileChooser can't because this object is not a file system object.

If I understand @mrserb's scenario where he reproduced the problem, one of the folders (Recent) contained a shortcut which has the same or similar properties: the File Explorer can navigate to the object to which the shortcut points, yet JFileChooser can't because it shows and navigates file system objects object.

A `.lnk` object is stable across Windows releases, basically it's a serialised form of `IShellLink` interface. Yet the shell would fail to resolve the `.lnk` if the shell extension it points to is not installed.

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

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


From prr at openjdk.org  Thu Jan  5 22:14:49 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 5 Jan 2023 22:14:49 GMT
Subject: RFR: 8299425: "LCMSImageLayout.isIntPacked" flag can be deleted
In-Reply-To: <B5ZZeBPytgniy6zooDsWftJJG0_Q6qMH3sg_8OHUTM4=.b132ad52-56ff-4b88-89c5-2bb55b3d7356@github.com>
References: <B5ZZeBPytgniy6zooDsWftJJG0_Q6qMH3sg_8OHUTM4=.b132ad52-56ff-4b88-89c5-2bb55b3d7356@github.com>
Message-ID: <G79LvnCVyhfCZvTxhzAMRH0ddExhqY6v5h4YXaSuGtM=.869a1068-532d-4647-819d-4509204609a1@github.com>

On Sat, 31 Dec 2022 03:22:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> After this change we will set correct pixel formatter when we initially create it, instead of updating the pixel formatter in native based on additional "isIntPacked" flag.
> 
> FYI: The fix for https://bugs.openjdk.org/browse/JDK-7124245 added the "isIntPacked" flag to mark the non-byte pixels layouts(like TYPE_INT_RGB).
> * This flag is passed around even if it is not used by the pixel layout
> * It may cause unnecessary creation of new transform if one type is "rgb && isIntPacked=true" and another one is "bgr && isIntPacked=false", but the actual data is the same
> see: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/2cf07dbdee64

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Thu Jan  5 23:01:53 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 5 Jan 2023 23:01:53 GMT
Subject: RFR: 8299337: The java.awt.image.ColorModel#pData field is unused
In-Reply-To: <33MoUulwjlpaM_-aqninKh8mPXBN0-rKAacsfZ6OUF8=.957b42a7-73c1-4c0c-9ad1-74d0ed76c46b@github.com>
References: <33MoUulwjlpaM_-aqninKh8mPXBN0-rKAacsfZ6OUF8=.957b42a7-73c1-4c0c-9ad1-74d0ed76c46b@github.com>
Message-ID: <gcUizt1N6rP1ohVtHJwv0Sd38G8Gbm4LNlAxmybFupg=.7c106ea9-8130-443d-91b2-5fea84859474@github.com>

On Sat, 24 Dec 2022 03:49:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I have found that we store the native pointer in the "java.awt.image.ColorModel#pData" field and never update/clean it. We can check how and when the native data is deallocated and reset the pointer, but it will be easy just to delete the field as unused.

Marked as reviewed by prr (Reviewer).

src/java.desktop/unix/native/common/awt/X11Color.c line 1231:

> 1229:         JNU_SetLongFieldFromPtr(env, awt_colormodel, g_CMpDataID,
> 1230:                                 aData->color_data);
> 1231: 

This is the one that is more work to track down but it seems it belongs to the X11GraphicsConfig and is managed / disposed by that.

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

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


From serb at openjdk.org  Fri Jan  6 00:40:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 6 Jan 2023 00:40:50 GMT
Subject: RFR: 8298876: Swing applications do not get repainted coming out
 of sleep on Windows 10
In-Reply-To: <4Rwd2whqzEDkIp18wA5Gug64zbPWMzrRUNLyJ4GVJE8=.81f3f83c-df7d-40cf-9e22-25e5035435ad@github.com>
References: <4Rwd2whqzEDkIp18wA5Gug64zbPWMzrRUNLyJ4GVJE8=.81f3f83c-df7d-40cf-9e22-25e5035435ad@github.com>
Message-ID: <dLuY9j-m52E91sVZSBHk-UiGVwedKNsSrAyCz48_D1w=.21cda8f2-b382-4a6d-b3df-b0f4562ed085@github.com>

On Mon, 2 Jan 2023 08:24:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This is a revert of commit https://github.com/openjdk/jdk/commit/415bf44191632cd8dbcc158c0ff0992c0b61c3ba
> which was a fix for 8275715: D3D pipeline processes multiple PaintEvent at initial drawing 
> as it is causing some repaint issue and also since the regression test is known to fail in some systems and is currently problemlisted which suggests the fix was half-baked.
> 
> Raised a new issue for the same https://bugs.openjdk.org/browse/JDK-8299436

Since this is just a revert what about fixing it in jdk20?

test/jdk/sun/java2d/DirectX/MultiPaintEventTest/MultiPaintEventTest.java line 1:

> 1: /*

The test should be removed from the problem list as well.

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

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


From aj at openjdk.org  Fri Jan  6 00:40:59 2023
From: aj at openjdk.org (Anto J)
Date: Fri, 6 Jan 2023 00:40:59 GMT
Subject: Integrated: 8296934: Write a test to verify whether Undecorated Frame
 can be iconified or not
In-Reply-To: <r2i1ZTPfV1ptIZgIklDtQNuR_vt4plnRmEYXxO6BWD0=.46373c1c-cc38-4a85-bcd5-097e577477ff@github.com>
References: <r2i1ZTPfV1ptIZgIklDtQNuR_vt4plnRmEYXxO6BWD0=.46373c1c-cc38-4a85-bcd5-097e577477ff@github.com>
Message-ID: <-6NhjxPMcGnl5X5DBTTqD6SrvJlTWWs5hmi3SMoC-gU=.210b7c9a-0d08-46e8-a4a1-1498058d44fe@github.com>

On Mon, 2 Jan 2023 16:09:35 GMT, Anto J <aj at openjdk.org> wrote:

> This test case verifies that Undecorated Frame can be iconified or not
> Using mouse click events generated WINDOW_ACTIVATED, WINDOW_ICONIFIED, WINDOW_DEACTIVATED, and WINDOW_DEICONIFIED and tested whether it is iconified or not.

This pull request has now been integrated.

Changeset: 7845b0d7
Author:    Anto J <aj at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7845b0d7b4193688448b7bf0c427df4976d302e5
Stats:     200 lines in 1 file changed: 200 ins; 0 del; 0 mod

8296934: Write a test to verify whether Undecorated Frame can be iconified or not

Reviewed-by: serb

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

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


From serb at openjdk.org  Fri Jan  6 00:45:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 6 Jan 2023 00:45:50 GMT
Subject: RFR: 8299412 JNI call of getAccessibleActionCount on a wrong
 thread [v2]
In-Reply-To: <V021dlf9P3wKJrijtcLHYZFw5baJsO9VMnG3Cnuv4NM=.254a5b3b-c542-4ea1-9a76-936c3c5beb1d@github.com>
References: <qZquaGznBhIRJMHMZ0mjEeg26LrwgnIyUOW9vkmr0vQ=.4b4f82ac-beea-4d45-8f0e-7c552844e80b@github.com>
 <V021dlf9P3wKJrijtcLHYZFw5baJsO9VMnG3Cnuv4NM=.254a5b3b-c542-4ea1-9a76-936c3c5beb1d@github.com>
Message-ID: <bEwosCgCi6OQPvmd6uPIIm7zUjFpErajW-FZkotNcEM=.6446b790-ad89-4d01-a780-3a5ab880d9ba@github.com>

On Thu, 29 Dec 2022 20:41:04 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> [CommonComponentAccessibility getActionsWithEnv:] defines the getAccessibleActionCount method on the AccessibleAction class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.
>> 
>> @azuev-java @mrserb @prrace please review
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   There's a more compact way of doing this:

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.org  Fri Jan  6 00:46:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 6 Jan 2023 00:46:50 GMT
Subject: RFR: 8298921: Create a regression test for JDK-8139581 [v3]
In-Reply-To: <UFscZWoknYQIrRtNFuBOOuSK2RreVRuw1pLOJKi9EFY=.5ebe8d8a-4fc7-47ae-9f95-4019fecf3903@github.com>
References: <lkasNa1F7wgDFUbBBlSzzve1p3DmJHqmyV6ELZd_BQs=.51d1cbf0-3c97-40d4-8892-d6c214674d94@github.com>
 <UFscZWoknYQIrRtNFuBOOuSK2RreVRuw1pLOJKi9EFY=.5ebe8d8a-4fc7-47ae-9f95-4019fecf3903@github.com>
Message-ID: <G7AM37utBrk-q2lUQyg5xnEN4SaKcpeXpJ0i5SdtzZI=.3daffd25-783c-47d6-8cce-5a46bcbad9d6@github.com>

On Thu, 5 Jan 2023 09:58:16 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for JDK-8139581
>> 
>> As described in JDK-8139581, when an AWT panel with AWT components, for example "java.awt.Button", is removed from AWT frame and added again to the same frame, then some AWT components contained in the panel are not drawn, however, clicking in the area of not drawn button leads to drawing of the button.
>> 
>> Test has a swing and awt component in a panel. It then removes and adds back the panel from/into the frame, to verify that they are repainted back properly.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8298921: Fixed whitespaces

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.org  Fri Jan  6 00:52:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 6 Jan 2023 00:52:50 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows [v2]
In-Reply-To: <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
 <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
Message-ID: <jmk5QwhSkR2NWMmalhzRkBJem_zRyAZn4egOHPc7g7k=.62398ce3-cb6a-41f6-8265-2cfe6fa963c3@github.com>

On Thu, 22 Dec 2022 10:57:15 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> **Environment**: 
>> GraalVM 22.3.0 with  jdk 19, Windows OS.
>> 
>> **Description**:
>> Create a native image of Swing application using GraalVM and run it with ` -Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> `java.lang.Error: java.home property not set` error is thrown.
>> 
>> For more details see https://github.com/oracle/graal/issues/4875.
>> 
>> **Solution**:
>> The error is thrown by the code from [FontConfiguration.findFontConfigFile()](https://github.com/openjdk/jdk19u/blob/c9d485792b99233f381dcdfd69838e7b973909bd/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L175) method.
>> GraalVM does not set `java.home`  property, that is why the `java.lang.Error: java.home property not set` is thrown.
>> `FontConfiguration.findFontConfigFile()` method compares `java.home` property to null before checking user provided `sun.awt.fontconfig` java property.
>> 
>> The proposed fix swaps the order of `java.home` and `sun.awt.fontconfig` properties checking to avoid using `java.home` property in case `sun.awt.fontconfig` is set.
>> 
>> 
>> **Steps to reproduce**:
>> - Download graal 22.3.0 jdk 19 for Windows from [GraalVM Community Edition 22.3.0](https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0) page.
>> - Install native-image
>> 
>> graalvm-ce-java19-22.3.0\bin\gu.cmd install native-image
>> 
>> - Create and compile `SwingSample.java` sample
>> 
>> import java.awt.*;
>> import javax.swing.*;
>> 
>> public class SwingSample {
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeAndWait(() -> {
>> 
>>             JFrame frame = new JFrame("Hello World");
>> 
>>             JButton button = new JButton("Hello");
>>             button.addActionListener(e -> {
>>                 System.out.printf("Hello, World!%n");
>>             });
>> 
>>             JPanel panel = new JPanel(new FlowLayout());
>>             panel.add(button);
>> 
>>             frame.add(panel);
>>             frame.setSize(400, 300);
>>             frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>             frame.setVisible(true);
>>         });
>>     }
>> }
>> 
>> - Run native-image-agent to generate configuration files
>> 
>> graalvm-ce-java19-22.3.0\bin\java.cmd -agentlib:native-image-agent=config-output-dir=conf-dir SwingSample
>> 
>> - Copy `graalvm-ce-java19-22.3.0\lib\fontconfig.properties.src` file to the sample dir
>> - Generate native image with configuration files and `-Djava.awt.headless=false `, `-Dsun.awt.fontconfig=fontconfig.properties.src` java properties
>> 
>> call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64"
>> graalvm-ce-java19-22.3.0\bin\native-image.cmd --no-fallback -Djava.awt.headless=false -Dsun.awt.fontconfig=fontconfig.properties.src -H:ResourceConfigurationFiles=conf-dir/resource-config.json -H:SerializationConfigurationFiles=conf-dir/serialization-config.json -H:ReflectionConfigurationFiles=conf-dir/reflect-config.json -H:JNIConfigurationFiles=conf-dir/jni-config.json SwingSample
>> 
>> - Run the native image with `-Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> 
>> swingsample.exe  -Dsun.awt.fontconfig=fontconfig.properties.src
>> 
>> Exception in thread "main" java.lang.reflect.InvocationTargetException
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371)
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346)
>>         at java.desktop at 19.0.1/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480)
>>         at SwingSample.main(SwingSample.java:7)
>> Caused by: java.lang.Error: java.home property not set
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
>>         at java.desktop at 19.0.1/sun.awt.windows.WFontConfiguration.<init>(WFontConfiguration.java:41)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize javaLib when a user fontconfig file is set

If this property is not optional why do we have a null check for it? Can that check be removed as a part of refactoring?

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

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


From duke at openjdk.org  Fri Jan  6 02:45:18 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 6 Jan 2023 02:45:18 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from a
 constructor
Message-ID: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>

This PR adds a new lint warning category `this-escape`.

It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.

A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
* Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
* Some constructor `B()` of `B` invokes `A()` as its superclass constructor
* During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly

In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.

Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.

>From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.

For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.

More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.

Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.

Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.

**Patch Navigation Guide**

* Non-trivial compiler changes:
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`

* Javadoc additions of `@implNote`:

    * `src/java.base/share/classes/java/io/PipedReader.java`
    * `src/java.base/share/classes/java/io/PipedWriter.java`
    * `src/java.base/share/classes/java/lang/Throwable.java`
    * `src/java.base/share/classes/java/util/ArrayDeque.java`
    * `src/java.base/share/classes/java/util/EnumMap.java`
    * `src/java.base/share/classes/java/util/HashSet.java`
    * `src/java.base/share/classes/java/util/Hashtable.java`
    * `src/java.base/share/classes/java/util/LinkedList.java`
    * `src/java.base/share/classes/java/util/TreeMap.java`
    * `src/java.base/share/classes/java/util/TreeSet.java`

* New unit tests
    * `test/langtools/tools/javac/warnings/ThisEscape/*.java`

* **Everything else** is just adding `@SuppressWarnings("this-escape")`

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

Commit messages:
 - Remove trailing whitespace.
 - Some documentation tweaks.
 - Treat method references like the equivalent lambda.
 - Fix bug where initializers could generate duplicate warnings.
 - Javadoc fix.
 - Add ThisEscape.html doc note and link the new @implNote's to it.
 - Add more @SuppressWarnings("this-escape") annotations.
 - Add more @SuppressWarnings("this-escape") annotations.
 - Add more @SuppressWarnings("this-escape") annotations.
 - Add more @SuppressWarnings("this-escape") annotations.
 - ... and 38 more: https://git.openjdk.org/jdk/compare/c6588d5b...9c162283

Changes: https://git.openjdk.org/jdk/pull/11874/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8015831
  Stats: 4326 lines in 1285 files changed: 4259 ins; 3 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

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


From psadhukhan at openjdk.org  Fri Jan  6 04:50:29 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 6 Jan 2023 04:50:29 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane updateStyle()
 ignores method argument
Message-ID: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>

It seems Synth has two cases of updateStyle() where its argument is not passed to the getContext() call. It seems to be an oversight as in other Synth classes, the component argument passed to updateStyle is being passed to getContext().

CI tests are ok with this change and there is no new regeression with CI tests run in NimbusL&F by default..

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

Commit messages:
 - 7131166: SynthListUI / SynthInternalFrameTitlePane updateStyle() ignores method argument

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

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


From dholmes at openjdk.org  Fri Jan  6 04:51:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 6 Jan 2023 04:51:00 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>

On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Hi Archie,

The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere?

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

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


From serb at openjdk.org  Fri Jan  6 05:05:47 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 6 Jan 2023 05:05:47 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
Message-ID: <DKpZ8fjexcVlAFhBM6iaGGIpms32vml3j-dTWc9fwzg=.08365e11-feae-45b0-9271-3043f98a0c57@github.com>

On Fri, 6 Jan 2023 04:42:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems Synth has two cases of updateStyle() where its argument is not passed to the getContext() call. It seems to be an oversight as in other Synth classes, the component argument passed to updateStyle is being passed to getContext().
> 
> CI tests are ok with this change and there is no new regeression with CI tests run in NimbusL&F by default..

Can this change tested somehow? Does it affect on the component rendering?

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

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


From serb at openjdk.org  Fri Jan  6 05:15:10 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 6 Jan 2023 05:15:10 GMT
Subject: RFR: 4934362: see also refers to self
In-Reply-To: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
References: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
Message-ID: <b7rm42EDWIVfFh9m0bDVXyE1auf-PoNTYvw8MIduavM=.5f76d12f-8259-4e20-8842-10c5dddb1557@github.com>

On Tue, 3 Jan 2023 06:00:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Some methods and constants has a hyperreference to self in javadoc which is rectified to reference proper methods

src/java.desktop/share/classes/java/awt/Component.java line 2268:

> 2266:      *          of this component
> 2267:      * @throws NullPointerException if {@code d} is {@code null}
> 2268:      * @see #getSize

The old ref seems to be a shurtcut to the `setSize(int, int)` 
take a look to the current spec
https://docs.oracle.com/en/java/javase/19/docs/api/java.desktop/java/awt/Component.html#setSize(java.awt.Dimension)

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

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


From psadhukhan at openjdk.org  Fri Jan  6 05:25:29 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 6 Jan 2023 05:25:29 GMT
Subject: RFR: 4934362: see also refers to self [v2]
In-Reply-To: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
References: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
Message-ID: <O6dDS_pPAfL3q_KTfjRd8KXVhNsMULsRuKrsjSGcHmI=.0c5302b8-bd4b-4883-bbee-efd52b877cbc@github.com>

> Some methods and constants has a hyperreference to self in javadoc which is rectified to reference proper methods

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

  Rectified link

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11820/files
  - new: https://git.openjdk.org/jdk/pull/11820/files/5c9bd461..cac52f91

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

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

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


From serb at openjdk.org  Fri Jan  6 05:35:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 6 Jan 2023 05:35:50 GMT
Subject: RFR: 4934362: see also refers to self [v2]
In-Reply-To: <O6dDS_pPAfL3q_KTfjRd8KXVhNsMULsRuKrsjSGcHmI=.0c5302b8-bd4b-4883-bbee-efd52b877cbc@github.com>
References: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
 <O6dDS_pPAfL3q_KTfjRd8KXVhNsMULsRuKrsjSGcHmI=.0c5302b8-bd4b-4883-bbee-efd52b877cbc@github.com>
Message-ID: <DrIKuS18p08lKYNWxcc_xe6gx6RGN4fKoU6kFYawESU=.fdf7033d-ae3b-44ce-bd56-b29f57c6d0e3@github.com>

On Fri, 6 Jan 2023 05:25:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Some methods and constants has a hyperreference to self in javadoc which is rectified to reference proper methods
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rectified link

src/java.desktop/share/classes/java/awt/MediaTracker.java line 529:

> 527:      *                       have been aborted, or have encountered
> 528:      *                       an error; {@code false} otherwise
> 529:      * @see         java.awt.MediaTracker#checkID(int, boolean, boolean)

int, boolean, boolean is a private method, it should probably refer the checkID(int)

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

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


From psadhukhan at openjdk.org  Fri Jan  6 05:57:08 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 6 Jan 2023 05:57:08 GMT
Subject: RFR: 4934362: see also refers to self [v3]
In-Reply-To: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
References: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
Message-ID: <idlyKRTbDb6VogUoZvjwaX-ZeEmNvmDuzgNOO6EaxcA=.752dc524-62de-4c89-a6e7-cea726a3be61@github.com>

> Some methods and constants has a hyperreference to self in javadoc which is rectified to reference proper methods

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

  Rectified link

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11820/files
  - new: https://git.openjdk.org/jdk/pull/11820/files/cac52f91..bfa5497c

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

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

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


From serb at openjdk.org  Fri Jan  6 05:58:59 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 6 Jan 2023 05:58:59 GMT
Subject: [jdk20] RFR: 8299227: host `exif.org` not found in link in doc
 comment [v2]
In-Reply-To: <csQoaoYWu95A6f-0Ro0A39F91Kp-FB1C0jzRb4w0ti4=.06cb286e-ba03-4cfb-9845-d0f1cdaaf891@github.com>
References: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
 <CkBcNmCs96sP6ou8iSrMzqKa06tGQXkln-PNeDC1WOw=.360d4fb6-8b23-409d-8892-349fda6b806d@github.com>
 <0LINf1R5FoZStKMSlimveknC42QeZDxLIsNPYaFDXjA=.c08df247-13eb-4c2f-bdf3-b46bb61ca891@github.com>
 <GAsu9kNA_vxUcRuE_SXMaH8GC2LvallS_qnzCncal5k=.5c2c2765-b06c-4eb5-beaf-c2a1e6d6dbbc@github.com>
 <jajjPkrDk6xVnowdBFlrh3w5tKAGqjrtnNqDdWwYiis=.4e1ed866-8b70-41cc-9b49-4d7b3a8dfb67@github.com>
 <NRHvZpQ3Gp9yKf_1a8dNiSad35wV5KWtvzroRJaEC1Y=.cfbeea84-3d6c-40a8-971b-82b41ef84d6a@github.com>
 <qt8vDezkjTxlzL4ybvjQUM58xeD5RhpK3VZC76kNy0o=.81345c76-0615-4404-a4f2-db1b6e1befa3@github.com>
 <csQoaoYWu95A6f-0Ro0A39F91Kp-FB1C0jzRb4w0ti4=.06cb286e-ba03-4cfb-9845-d0f1cdaaf891@github.com>
Message-ID: <hgdQXVE6nMfHKMHwG5QXLCqcGky75a31S_prUvyzxUM=.de1d16db-8870-4c3e-8ed0-5e7c830e39e6@github.com>

On Thu, 5 Jan 2023 08:44:47 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Can we place that document somewhere(I think that is not easy but still) and provide a link to it?
>
> Did you mean this docment `https://www.kodak.com/global/plugins/acrobat/en/service/digCam/exifStandard2.pdf` ?
> 
> I am not sure if we can do this.

I mean the Exif2-2.PDF from the "web.archive"

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

PR: https://git.openjdk.org/jdk20/pull/74


From abhiscxk at openjdk.org  Fri Jan  6 06:24:49 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 6 Jan 2023 06:24:49 GMT
Subject: RFR: 8299306: Test
 "javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java" fails on
 Windows 10 x64 because there are some buttons did not display button name
In-Reply-To: <nb2XebuqQTexBaybLdEjdtlaG4ZlcH8WQNuLHKEcQQk=.a66207c5-f6cf-411f-b302-1d57dd5be1b7@github.com>
References: <nb2XebuqQTexBaybLdEjdtlaG4ZlcH8WQNuLHKEcQQk=.a66207c5-f6cf-411f-b302-1d57dd5be1b7@github.com>
Message-ID: <pS7ss7Jn4kKqpEW5STemb9Czk91SrkN_DdcKVwfPRJc=.347cfcd6-46dc-4606-a3a5-5e4dbe7562bc@github.com>

On Tue, 3 Jan 2023 07:08:13 GMT, Tejesh R <tr at openjdk.org> wrote:

> When JFilechooser is added to a frame, the control buttons are disabled. Since in the test the control buttons are not required since JFilechooser is added to a JFrame and in turn frame disposal is handled by PassFailJFrame. The fix is to disable JFileChooser control buttons.

LGTM.

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

Marked as reviewed by abhiscxk (Author).

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


From abhiscxk at openjdk.org  Fri Jan  6 07:01:59 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 6 Jan 2023 07:01:59 GMT
Subject: [jdk20] RFR: 8299227: host `exif.org` not found in link in doc
 comment [v2]
In-Reply-To: <hgdQXVE6nMfHKMHwG5QXLCqcGky75a31S_prUvyzxUM=.de1d16db-8870-4c3e-8ed0-5e7c830e39e6@github.com>
References: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
 <CkBcNmCs96sP6ou8iSrMzqKa06tGQXkln-PNeDC1WOw=.360d4fb6-8b23-409d-8892-349fda6b806d@github.com>
 <0LINf1R5FoZStKMSlimveknC42QeZDxLIsNPYaFDXjA=.c08df247-13eb-4c2f-bdf3-b46bb61ca891@github.com>
 <GAsu9kNA_vxUcRuE_SXMaH8GC2LvallS_qnzCncal5k=.5c2c2765-b06c-4eb5-beaf-c2a1e6d6dbbc@github.com>
 <jajjPkrDk6xVnowdBFlrh3w5tKAGqjrtnNqDdWwYiis=.4e1ed866-8b70-41cc-9b49-4d7b3a8dfb67@github.com>
 <NRHvZpQ3Gp9yKf_1a8dNiSad35wV5KWtvzroRJaEC1Y=.cfbeea84-3d6c-40a8-971b-82b41ef84d6a@github.com>
 <qt8vDezkjTxlzL4ybvjQUM58xeD5RhpK3VZC76kNy0o=.81345c76-0615-4404-a4f2-db1b6e1befa3@github.com>
 <csQoaoYWu95A6f-0Ro0A39F91Kp-FB1C0jzRb4w0ti4=.06cb286e-ba03-4cfb-9845-d0f1cdaaf891@github.com>
 <hgdQXVE6nMfHKMHwG5QXLCqcGky75a31S_prUvyzxUM=.de1d16db-8870-4c3e-8ed0-5e7c830e39e6@github.com>
Message-ID: <2ywgqwxo0gKHvVkAYXFo-NonsoCKKXZZjK93W8cgwoo=.20377d44-7ef1-4408-92d4-dc99fb7f6dcc@github.com>

On Fri, 6 Jan 2023 05:56:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Did you mean this docment `https://www.kodak.com/global/plugins/acrobat/en/service/digCam/exifStandard2.pdf` ?
>> 
>> I am not sure if we can do this.
>
> I mean the Exif2-2.PDF from the "web.archive"

I don't have an idea where we can put `Exif2-2.PDF` and provide a link. 
Since we have a suitable link to version 2.3, it's better to point to that link. As mentioned by @prrace also in the comment above. 
https://github.com/openjdk/jdk20/pull/74#discussion_r1056618094.

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

PR: https://git.openjdk.org/jdk20/pull/74


From asemenov at openjdk.org  Fri Jan  6 07:11:57 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 6 Jan 2023 07:11:57 GMT
Subject: Integrated: 8299412 JNI call of getAccessibleActionCount on a wrong
 thread
In-Reply-To: <qZquaGznBhIRJMHMZ0mjEeg26LrwgnIyUOW9vkmr0vQ=.4b4f82ac-beea-4d45-8f0e-7c552844e80b@github.com>
References: <qZquaGznBhIRJMHMZ0mjEeg26LrwgnIyUOW9vkmr0vQ=.4b4f82ac-beea-4d45-8f0e-7c552844e80b@github.com>
Message-ID: <YhfA2yMArcEz4-dv1FzEw_BcXkLUrriDuR4jz_H7vg4=.2ccf721e-13d6-41c7-89e8-4a1a3fd6b476@github.com>

On Thu, 29 Dec 2022 15:54:43 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> [CommonComponentAccessibility getActionsWithEnv:] defines the getAccessibleActionCount method on the AccessibleAction class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.
> 
> @azuev-java @mrserb @prrace please review

This pull request has now been integrated.

Changeset: 775da84a
Author:    Artem Semenov <asemenov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/775da84a84770696495561277eb040f53260ecaf
Stats:     12 lines in 2 files changed: 7 ins; 2 del; 3 mod

8299412: JNI call of getAccessibleActionCount on a wrong thread

Reviewed-by: prr, serb

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

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


From mvs at openjdk.org  Fri Jan  6 07:21:12 2023
From: mvs at openjdk.org (Manukumar V S)
Date: Fri, 6 Jan 2023 07:21:12 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v2]
In-Reply-To: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
Message-ID: <NSe5ZVQIz159nKk8zeuC-O01YzdbdBbKXM5Wlo3aqtE=.4fcd9130-ed6a-4508-bad4-fce86ee3093d@github.com>

> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
> 
> Fix:
> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
> Also updated the screen capture code, made frame undecorated, added some prints for better debugging.

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: Replaced one robot.waitForIdle with robot.delay(), formatting corrections, taken the insets into account for initial frame position

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10655/files
  - new: https://git.openjdk.org/jdk/pull/10655/files/5b33a645..b3ac566d

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

  Stats: 36 lines in 1 file changed: 10 ins; 8 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/10655.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10655/head:pull/10655

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


From mvs at openjdk.org  Fri Jan  6 07:21:12 2023
From: mvs at openjdk.org (Manukumar V S)
Date: Fri, 6 Jan 2023 07:21:12 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v2]
In-Reply-To: <bxzrjMDW_3h7vTjV8AL5ziDpF1fsujnTd1yojkhadbs=.f72d0e06-08b8-4cbc-9953-efe05647b20b@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
 <bCjlBewHa7tXT7d5mtQmLxcMbGDApK2ZvtN3RSnCpCM=.fb8b14dd-1585-44d7-a153-9ec72ac20670@github.com>
 <bxzrjMDW_3h7vTjV8AL5ziDpF1fsujnTd1yojkhadbs=.f72d0e06-08b8-4cbc-9953-efe05647b20b@github.com>
Message-ID: <hzBu8ey7PmsXzX0DwJWwGOdKnIiONiGGt4wmFCWtRoY=.fcc782d0-f7dc-4f6e-aaf5-70a1b20f2229@github.com>

On Tue, 3 Jan 2023 16:30:43 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 133:
>> 
>>> 131:         robot.mousePress(InputEvent.BUTTON3_DOWN_MASK);
>>> 132:         robot.mouseRelease(InputEvent.BUTTON3_DOWN_MASK);
>>> 133:         robot.waitForIdle();
>> 
>> When testing locally on my macOS machine, this waitForIdle seems to be the culprit for why this test takes much longer per iteration. Maybe worth looking into why?
>
> Yes, this `robot.waitForIdle` makes the test unbearably slow. Worth submitting a separate bug with the reproducer. At this point, the pop is shown on the screen and its first item is highlighted.
> 
> I replaced it with
> 
> robot.delay(200);

Replaced robot.waitForIdle with robot.delay(200). I will check the possibility of raising a new bug.

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

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


From tr at openjdk.org  Fri Jan  6 07:53:53 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 6 Jan 2023 07:53:53 GMT
Subject: Integrated: 8299306: Test
 "javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java" fails on
 Windows 10 x64 because there are some buttons did not display button name
In-Reply-To: <nb2XebuqQTexBaybLdEjdtlaG4ZlcH8WQNuLHKEcQQk=.a66207c5-f6cf-411f-b302-1d57dd5be1b7@github.com>
References: <nb2XebuqQTexBaybLdEjdtlaG4ZlcH8WQNuLHKEcQQk=.a66207c5-f6cf-411f-b302-1d57dd5be1b7@github.com>
Message-ID: <Q75QS8XBOljjXZwNy1-0CrnBuwjzeDjjPYFG5X7Uggw=.53256763-7886-4a99-a2a7-d1f6dfbd7ecd@github.com>

On Tue, 3 Jan 2023 07:08:13 GMT, Tejesh R <tr at openjdk.org> wrote:

> When JFilechooser is added to a frame, the control buttons are disabled. Since in the test the control buttons are not required since JFilechooser is added to a JFrame and in turn frame disposal is handled by PassFailJFrame. The fix is to disable JFileChooser control buttons.

This pull request has now been integrated.

Changeset: 99be7408
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99be74088eec3e7974642c8aa5792377d32ebe67
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8299306: Test "javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java" fails on Windows 10 x64 because there are some buttons did not display button name

Reviewed-by: psadhukhan, abhiscxk

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

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


From alanb at openjdk.org  Fri Jan  6 07:53:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jan 2023 07:53:54 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <Hnu2IeLr21reuXeHYgIlKiNCwQ9zJLeg9dykcL_Y8KM=.67209ee1-a778-4bae-a7a8-d61e860f7b23@github.com>

On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

This looks like a very useful lint warning to have but this PR is unwieldy. If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially.

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

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


From serb at openjdk.org  Fri Jan  6 08:07:55 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 6 Jan 2023 08:07:55 GMT
Subject: Integrated: 8298240: Replace the usage of ImageLayoutException by the
 CMMException
In-Reply-To: <MugzKoEie2il8Rn7Tp4oLM0N8zg-QtGh1gsQmPPX-lE=.66e63bba-76ef-4425-8aa6-6a2350d77c24@github.com>
References: <MugzKoEie2il8Rn7Tp4oLM0N8zg-QtGh1gsQmPPX-lE=.66e63bba-76ef-4425-8aa6-6a2350d77c24@github.com>
Message-ID: <0E4jEplh7hF2oMFIy6B7QHayiQFDg9czjvWOzxK3LeA=.c244de05-9ae8-40fb-b8a6-f786900abbbe@github.com>

On Wed, 7 Dec 2022 04:07:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> ImageLayoutException is used to report any issues with image layout calculation. But since we cannot throw the unspecified exception to the application, all usages of ImageLayoutException are wrapped by the CMMException. And now if such CMMException occurs we have lost at what point the initial exception was raised.
> 
> We can pass some additional data around, but it looks like we can just delete the ImageLayoutException and use CMMException instead. 
> 
> Additionally:
>  * The `public` keyword is removed in a few places if not needed.
>  * The PT_XX flags are updated to make it clearly visible how they are related.

This pull request has now been integrated.

Changeset: b5b7948d
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5b7948d9b4870d9e84ec8d8b544b252f9053785
Stats:     175 lines in 2 files changed: 13 ins; 79 del; 83 mod

8298240: Replace the usage of ImageLayoutException by the CMMException

Reviewed-by: prr

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

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


From aturbanov at openjdk.org  Fri Jan  6 08:32:56 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 6 Jan 2023 08:32:56 GMT
Subject: Integrated: 8298447: Unnecessary Vector usage in DocPrintJob
 implementations
In-Reply-To: <JJ3LrpITZ7EaKjvUzOZH0s-dlR9JjZ02glhUVEWFrp8=.17a11333-83c9-4a52-a0e7-30052ecbebb6@github.com>
References: <JJ3LrpITZ7EaKjvUzOZH0s-dlR9JjZ02glhUVEWFrp8=.17a11333-83c9-4a52-a0e7-30052ecbebb6@github.com>
Message-ID: <l_HqI3ciMsg6puv0qVQLkiICQeqc8S6kveh3KuBLY4k=.f4e5316b-7e58-4a51-929f-fc811594473b@github.com>

On Mon, 5 Dec 2022 08:23:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There are 3 implementations of javax.print.DocPrintJob in the JDK (It seems they were copy-pasted from each other):
> 1. PSStreamPrintJob
> 2. UnixPrintJob
> 3. Win32PrintJob
> 
> They have Vector fields 'jobListeners', 'attrListeners', 'listenedAttributeSets', but they are always accessed only under synchronized(this) blocks. It means we can safely replace them with ArrayList.
> 
> BTW. 'attrListeners' and 'listenedAttributeSets' seems unused.

This pull request has now been integrated.

Changeset: 0234f813
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0234f813e6113fee133a2cab77566d1fcb191c8b
Stats:     24 lines in 3 files changed: 0 ins; 0 del; 24 mod

8298447: Unnecessary Vector usage in DocPrintJob implementations

Reviewed-by: serb

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

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


From serb at openjdk.org  Fri Jan  6 11:26:54 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 6 Jan 2023 11:26:54 GMT
Subject: RFR: 8299425: "LCMSImageLayout.isIntPacked" flag can be deleted
 [v2]
In-Reply-To: <B5ZZeBPytgniy6zooDsWftJJG0_Q6qMH3sg_8OHUTM4=.b132ad52-56ff-4b88-89c5-2bb55b3d7356@github.com>
References: <B5ZZeBPytgniy6zooDsWftJJG0_Q6qMH3sg_8OHUTM4=.b132ad52-56ff-4b88-89c5-2bb55b3d7356@github.com>
Message-ID: <9_qiNoKZYyX7U_z9mvLJh4r1di1Pn0kxg5ZAeMCqd44=.c63270b3-a6fa-44d2-945a-a31b762d5edc@github.com>

> After this change we will set correct pixel formatter when we initially create it, instead of updating the pixel formatter in native based on additional "isIntPacked" flag.
> 
> FYI: The fix for https://bugs.openjdk.org/browse/JDK-7124245 added the "isIntPacked" flag to mark the non-byte pixels layouts(like TYPE_INT_RGB).
> * This flag is passed around even if it is not used by the pixel layout
> * It may cause unnecessary creation of new transform if one type is "rgb && isIntPacked=true" and another one is "bgr && isIntPacked=false", but the actual data is the same
> see: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/2cf07dbdee64

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into JDK-8299425
 - Merge remote-tracking branch 'upstream/master' into JDK-8299425
 - JDK-8299425: "LCMSImageLayout.isIntPacked" flag can be deleted

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

Changes: https://git.openjdk.org/jdk/pull/11806/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11806&range=01
  Stats: 48 lines in 4 files changed: 4 ins; 28 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/11806.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11806/head:pull/11806

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


From psadhukhan at openjdk.org  Fri Jan  6 13:02:48 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 6 Jan 2023 13:02:48 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
Message-ID: <0mjOBQIb2FDS1gK5O3f3YxrOHFqYVotIc-AQTwr8Nxk=.5dc28f99-7d0b-45da-8a95-46a9d24deea0@github.com>

On Fri, 6 Jan 2023 04:42:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems Synth has two cases of updateStyle() where its argument is not passed to the getContext() call. It seems to be an oversight as in other Synth classes, the component argument passed to updateStyle is being passed to getContext().
> 
> CI tests are ok with this change and there is no new regeression with CI tests run in NimbusL&F by default..

I didn't see any new issues with the CI tests run with and without SynthL&F, nor did I see any issue in SwingSet2..I could not see how else it can be tested..
I did not try this late jdk20 time-frame and trying this now beginning of jdk21 so that if there are any issues found, we can fix or revert before jdk21 release.

Also, looking at other Synth classes, it seems to be the way to go to maintain consistency

https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthButtonUI.java#L86
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java#L91
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java#L154
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthDesktopIconUI.java#L148
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java#L143
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java#L133
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLabelUI.java#L75
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthMenuBarUI.java#L83
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthMenuUI.java#L83
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java#L143

etc

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

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


From duke at openjdk.org  Fri Jan  6 14:51:54 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 6 Jan 2023 14:51:54 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
Message-ID: <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>

On Fri, 6 Jan 2023 04:48:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere?

Hi @dholmes-ora,

The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc.

Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds.

Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. 

> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details.

Hi @AlanBateman,

As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well.

> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially.

Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?

If this is generally agreed as a better route then let me know and I'll update the patch.

Thanks for both of your comments.

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

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


From alanb at openjdk.org  Fri Jan  6 15:41:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jan 2023 15:41:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
 <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
Message-ID: <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>

On Fri, 6 Jan 2023 14:49:16 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?
> 
> If this is generally agreed as a better route then let me know and I'll update the patch.

Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it.

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

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


From mcimadamore at openjdk.org  Fri Jan  6 15:57:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Jan 2023 15:57:50 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
 <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
 <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
Message-ID: <D_mLssKO7VlglPgP2sf3S1seKgyuJazeTrpnURCpxQk=.7e318df2-ef54-484c-9cb2-bea1100fe949@github.com>

On Fri, 6 Jan 2023 15:38:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere?
>> 
>> Hi @dholmes-ora,
>> 
>> The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc.
>> 
>> Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds.
>> 
>> Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. 
>> 
>>> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details.
>> 
>> Hi @AlanBateman,
>> 
>> As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well.
>> 
>>> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially.
>> 
>> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?
>> 
>> If this is generally agreed as a better route then let me know and I'll update the patch.
>> 
>> Thanks for both of your comments.
>
>> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?
>> 
>> If this is generally agreed as a better route then let me know and I'll update the patch.
> 
> Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it.

I agree with @AlanBateman. When we introduced similar warnings in the past, we have enabled support in javac (with some test) in a separate PR, and then followed up with small dedicated PR for each of the various areas (enabling new warnings one by one).

See this great umbrella JBS issue (created by @asotona) which has details on all the issues that were filed when we added an extra Lint warning for lossy conversions:

https://bugs.openjdk.org/browse/JDK-8286374

They all refer to this:

https://bugs.openjdk.org/browse/JDK-8244681

Which was submitted as a separate javac-only PR:
https://github.com/openjdk/jdk/pull/8599

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

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


From prr at openjdk.org  Fri Jan  6 19:57:10 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 6 Jan 2023 19:57:10 GMT
Subject: RFR: 8298876: Swing applications do not get repainted coming out
 of sleep on Windows 10
In-Reply-To: <dLuY9j-m52E91sVZSBHk-UiGVwedKNsSrAyCz48_D1w=.21cda8f2-b382-4a6d-b3df-b0f4562ed085@github.com>
References: <4Rwd2whqzEDkIp18wA5Gug64zbPWMzrRUNLyJ4GVJE8=.81f3f83c-df7d-40cf-9e22-25e5035435ad@github.com>
 <dLuY9j-m52E91sVZSBHk-UiGVwedKNsSrAyCz48_D1w=.21cda8f2-b382-4a6d-b3df-b0f4562ed085@github.com>
Message-ID: <7xWNFt2jZvxwgPaXDTQj69i3gNoH1MTvjSFPa_OoK-U=.ef72ad0a-b1bf-4644-ab70-6c31bedd23c4@github.com>

On Fri, 6 Jan 2023 00:37:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Since this is just a revert what about fixing it in jdk20?

If it had been introduced in 20 we likely would but it was introduced in 19.

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

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


From serb at openjdk.org  Fri Jan  6 20:19:57 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 6 Jan 2023 20:19:57 GMT
Subject: Integrated: 8299425: "LCMSImageLayout.isIntPacked" flag can be deleted
In-Reply-To: <B5ZZeBPytgniy6zooDsWftJJG0_Q6qMH3sg_8OHUTM4=.b132ad52-56ff-4b88-89c5-2bb55b3d7356@github.com>
References: <B5ZZeBPytgniy6zooDsWftJJG0_Q6qMH3sg_8OHUTM4=.b132ad52-56ff-4b88-89c5-2bb55b3d7356@github.com>
Message-ID: <HswzFGbyLzomUlLQl2S8f4jiB0px3E1ocBrTHTF5xIs=.987ab0ee-911c-4a6c-b62e-9801290b3308@github.com>

On Sat, 31 Dec 2022 03:22:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> After this change we will set correct pixel formatter when we initially create it, instead of updating the pixel formatter in native based on additional "isIntPacked" flag.
> 
> FYI: The fix for https://bugs.openjdk.org/browse/JDK-7124245 added the "isIntPacked" flag to mark the non-byte pixels layouts(like TYPE_INT_RGB).
> * This flag is passed around even if it is not used by the pixel layout
> * It may cause unnecessary creation of new transform if one type is "rgb && isIntPacked=true" and another one is "bgr && isIntPacked=false", but the actual data is the same
> see: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/2cf07dbdee64

This pull request has now been integrated.

Changeset: 4a95c74b
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a95c74b7628ad297d2a6bff2d47c6a9ddf876e3
Stats:     48 lines in 4 files changed: 4 ins; 28 del; 16 mod

8299425: "LCMSImageLayout.isIntPacked" flag can be deleted

Reviewed-by: prr

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

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


From aivanov at openjdk.org  Fri Jan  6 20:33:51 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 6 Jan 2023 20:33:51 GMT
Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java
 fails with AssertionError
In-Reply-To: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
References: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
Message-ID: <8IF_Mv2GxJmo_4pehBOumCe16PsM-cdRxSDuTBmbNLo=.5c15c968-8794-4175-8869-c91dee84b37d@github.com>

On Mon, 26 Dec 2022 05:17:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This assertion happens when we try to build the path linked by the shortcut file when part of that path is not accessible. For example, if the ".lnk" file is pointed to the "windows-update. settings" inside the "Internet.settings". 
> 
> After the change, we will skip the target of the link if any part of the path to the target is not a folder and is not traversable in JFileChooser.

Indeed, this resolves the problem. And I reproduced the original issue with `AssertionError` by running `bug4847375.java` with enabled assertions.

You're right, the Recent folder contains a handful of link files which point to the new Setting app which use `ms-settings:` protocol, File Explorer displays the *target location* as `"The Internet"`.

test/jdk/javax/swing/JFileChooser/4847375/bug4847375.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 4847375 8171363 8227257

Could you also add an option to run this test with assertions when using jtreg directly like you did for the new test?

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

Marked as reviewed by aivanov (Reviewer).

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


From aivanov at openjdk.org  Fri Jan  6 20:38:51 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 6 Jan 2023 20:38:51 GMT
Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java
 fails with AssertionError
In-Reply-To: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
References: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
Message-ID: <dr3AzvRNidPlSWbmqfl4WybjX8DEqw6Gviaw8HuzBGY=.ce3f10ab-30cd-4c11-a8c1-9d318a4a6a0f@github.com>

On Mon, 26 Dec 2022 05:17:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This assertion happens when we try to build the path linked by the shortcut file when part of that path is not accessible. For example, if the ".lnk" file is pointed to the "windows-update. settings" inside the "Internet.settings". 
> 
> After the change, we will skip the target of the link if any part of the path to the target is not a folder and is not traversable in JFileChooser.

By the way, `JFileChooser` can navigate the `.lnk` files which point to the classic Control Panel. I created a shortcut to *Devices and Printers* folder on the desktop. Double-clicking it, opens the folder but shows no items; the combo box at the top shows the structure: *Desktop* ? *Control Panel* ? *Hardware and Sound* ? *Devices and Printers* followed by *This PC* and other common items.

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

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


From aivanov at openjdk.org  Fri Jan  6 20:42:52 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 6 Jan 2023 20:42:52 GMT
Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java
 fails with AssertionError
In-Reply-To: <8IF_Mv2GxJmo_4pehBOumCe16PsM-cdRxSDuTBmbNLo=.5c15c968-8794-4175-8869-c91dee84b37d@github.com>
References: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
 <8IF_Mv2GxJmo_4pehBOumCe16PsM-cdRxSDuTBmbNLo=.5c15c968-8794-4175-8869-c91dee84b37d@github.com>
Message-ID: <BQ0g6lks-WTAYGQTpDcr2gj5upH46RwsC-WF77hSDAQ=.dfe6b63e-e926-4b0c-8bbe-e79f979dc372@github.com>

On Fri, 6 Jan 2023 20:22:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This assertion happens when we try to build the path linked by the shortcut file when part of that path is not accessible. For example, if the ".lnk" file is pointed to the "windows-update. settings" inside the "Internet.settings". 
>> 
>> After the change, we will skip the target of the link if any part of the path to the target is not a folder and is not traversable in JFileChooser.
>
> test/jdk/javax/swing/JFileChooser/4847375/bug4847375.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 4847375 8171363 8227257
> 
> Could you also add an option to run this test with assertions when using jtreg directly like you did for the new test?

Could you update the copyright year in other modified files too?

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

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


From prr at openjdk.org  Fri Jan  6 20:45:51 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 6 Jan 2023 20:45:51 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows [v2]
In-Reply-To: <jmk5QwhSkR2NWMmalhzRkBJem_zRyAZn4egOHPc7g7k=.62398ce3-cb6a-41f6-8265-2cfe6fa963c3@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
 <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
 <jmk5QwhSkR2NWMmalhzRkBJem_zRyAZn4egOHPc7g7k=.62398ce3-cb6a-41f6-8265-2cfe6fa963c3@github.com>
Message-ID: <jAff87Y1F3KwyapG1gOQbTejQtJG_4hHAiNoO3ItZms=.71eeaac3-fc5e-46f6-849b-47c947503c00@github.com>

On Fri, 6 Jan 2023 00:49:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> If this property is not optional why do we have a null check for it? Can that check be removed as a part of refactoring?

It is much better to have an error thrown which explains the problem rather than a random NPE or similar right afterwards.
This behaviour has been there since at least JDK 1.3 (2000)  when the file was first created as sun/awt/FontProperties.java. It may even have existed in some other location before then, but I can't tell that from SCCS per-file history.

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

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


From serb at openjdk.org  Fri Jan  6 22:02:38 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 6 Jan 2023 22:02:38 GMT
Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java
 fails with AssertionError [v2]
In-Reply-To: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
References: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
Message-ID: <S_M1SbhJdSLe3AnmmmoY3KtQ28K6zKI5yBs_r8TpYIs=.35f706d3-2120-4043-9d89-ee78ebda4b3f@github.com>

> This assertion happens when we try to build the path linked by the shortcut file when part of that path is not accessible. For example, if the ".lnk" file is pointed to the "windows-update. settings" inside the "Internet.settings". 
> 
> After the change, we will skip the target of the link if any part of the path to the target is not a folder and is not traversable in JFileChooser.

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

  review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11789/files
  - new: https://git.openjdk.org/jdk/pull/11789/files/a189371a..5106f402

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

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

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


From achung at openjdk.org  Fri Jan  6 22:14:47 2023
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 6 Jan 2023 22:14:47 GMT
Subject: RFR: 8282217: Key events (key char and key code) changed for Swiss
 keyboard
Message-ID: <N9XfS6cL8s1G98UAiEr7ZvgzQB-HX6qKGptKZe7d810=.1f5932c5-fd00-4fe8-9c0b-99f2fa71d880@github.com>

Removed check for MapVirtualKeyEx return value causing some keys to become undefined

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

Commit messages:
 - removed check for 0x80000000 in character for dead key

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

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


From mik3hall at gmail.com  Fri Jan  6 22:35:52 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 6 Jan 2023 16:35:52 -0600
Subject: OS/X GUI applications
In-Reply-To: <12bbb5e2-dc26-5bbe-22e5-816027ffc32b@oracle.com>
References: <CA1D7F10-343A-4052-8E35-D21C32F9719B@gmail.com>
 <22d33eca-eb38-8401-291a-c7a62c25d1ee@oracle.com>
 <12bbb5e2-dc26-5bbe-22e5-816027ffc32b@oracle.com>
Message-ID: <629416D3-AA95-4B07-903B-FCF264FF8A42@gmail.com>



> On Jan 3, 2023, at 1:15 PM, Philip Race <philip.race at oracle.com> wrote:
> 
> PS actually java launcher code still reads -Dapple.awt.application.name
> 
> -Phil.

Specific to getting a default application menu Cocoa ?About? menu item for javaFX applications. I could elaborate more if any interest but just that here to be brief.
Again, my concern was not the continued support of the apple system properties. It was my mistaken first assumption that it was the use of these that enabled the behavior like getting this menu item. Although the apple.awt.application.name does figure into what follows.

The javaFX Application class can include?

	static {
		//java.awt.Toolkit.getDefaultToolkit(); // Start AppKit
		Thread t = new Thread(() -> { java.awt.Toolkit.getDefaultToolkit(); });
      	t.start();
	}

ApplicationDelegate.m then can be changed as follows?

Add?
#import "PropertiesUtilities.h"
#import ?ThreadUtilities.h"

Make the following change in the ?init??
    //self.fAboutMenu = (NSMenuItem*)[appMenu itemAtIndex:0];
    if ([[[appMenu itemAtIndex:0] title] hasPrefix:@"About"]) 
        self.fAboutMenu = (NSMenuItem*)[appMenu itemAtIndex:0];
    else {
		JNIEnv *env = [ThreadUtilities getJNIEnv];
		NSString* appName = [PropertiesUtilities javaSystemPropertyForKey:@"apple.awt.application.name" withEnv:env];
		if (appName != nil) {
			NSMenuItem *aboutItem = [[NSMenuItem alloc] init];
			[aboutItem setTitle:[NSString stringWithFormat:@"About %@", appName]];
			[appMenu insertItem:aboutItem atIndex:0];
			self.fAboutMenu = aboutItem;
		}    
    }

This fixes the previously mentioned bug where the code assumes it has an ?About? menu item when it doesn?t.
The code seems to need to run off the main thread to access the menus properly. Otherwise you get nil or nulls. Somewhat strangely the menu code seems to function as nop?s if they get nil or nulls. So the above change should be ok even if hit running on the main thread.

Also given that this in - (void)_updateAboutMenu:(BOOL)aboutAvailable enabled:(BOOL)aboutEnabled

    if (aboutAvailable) {
        // Make sure About is around
        if ([self.fAboutMenu menu] == nil) {
            addMenuItem(self.fAboutMenu, 0);
        }

Is also sort of a bug. First, I?m not sure why if it?s nil you would want to add it to the menu. But even if you try it does nothing, it is a nop. I had first thought about using this method.

I used the apple.awt.application.name property for one reason to give another way to skip the changed code if it wasn?t set. But in testing this didn?t work. Something always seems to set that property so it just kept working.

Again, with these changes a javaFX application gets the default Cocoa ?About? menu item in the Application menu. I haven?t verified if this would further allow changing the java.awt.Desktop about handler. But it might be at least a first step in reconciling javaFX applications and java.awt.Desktop. At least on OS/X.






From serb at openjdk.org  Fri Jan  6 22:57:51 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 6 Jan 2023 22:57:51 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows [v2]
In-Reply-To: <jAff87Y1F3KwyapG1gOQbTejQtJG_4hHAiNoO3ItZms=.71eeaac3-fc5e-46f6-849b-47c947503c00@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
 <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
 <jmk5QwhSkR2NWMmalhzRkBJem_zRyAZn4egOHPc7g7k=.62398ce3-cb6a-41f6-8265-2cfe6fa963c3@github.com>
 <jAff87Y1F3KwyapG1gOQbTejQtJG_4hHAiNoO3ItZms=.71eeaac3-fc5e-46f6-849b-47c947503c00@github.com>
Message-ID: <wwYWYUhyE0sZyy3_conm04PKsFs-LBBvTNn6gvwifiw=.c081b182-e7f5-4eea-a5d2-2cd77770936e@github.com>

On Fri, 6 Jan 2023 20:42:38 GMT, Phil Race <prr at openjdk.org> wrote:

> It is much better to have an error thrown which explains the problem rather than a random NPE or similar right afterwards. 

But I assume we should have a test somewhere that validates that this option is not null = "is not optional"?
I make a quick search of code where we read the conf files, and it seems:
https://github.com/search?q=%22java.home%22+repo%3Aopenjdk%2Fjdk+path%3Asrc%2Fjava.desktop%2F+language%3AJava+language%3AJava&type=Code&ref=advsearch&l=Java&l=Java

 * The Sound - throw an exception in one place, but ignores the null in another place
 * The Fontconfig - throw an exception in FcFontConfiguration.java, but fallback to the empty code in SunFontManager.java
 * The Swing ignores the null property
 * The metal pipeline fallback to the empty path
 * The a11y code just read it as is.
 * The printers code in PSPrinterJob ignores the null

We have an opportunity to clean up all that code.

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

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


From serb at openjdk.org  Fri Jan  6 23:11:59 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 6 Jan 2023 23:11:59 GMT
Subject: Integrated: 8299337: The java.awt.image.ColorModel#pData field is
 unused
In-Reply-To: <33MoUulwjlpaM_-aqninKh8mPXBN0-rKAacsfZ6OUF8=.957b42a7-73c1-4c0c-9ad1-74d0ed76c46b@github.com>
References: <33MoUulwjlpaM_-aqninKh8mPXBN0-rKAacsfZ6OUF8=.957b42a7-73c1-4c0c-9ad1-74d0ed76c46b@github.com>
Message-ID: <_PNSJIx6ikiQK_e5Zhr0M7cKvcrmAOwjee55gspe5B4=.0f3559ce-70cf-4b74-860a-038c505cba8c@github.com>

On Sat, 24 Dec 2022 03:49:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I have found that we store the native pointer in the "java.awt.image.ColorModel#pData" field and never update/clean it. We can check how and when the native data is deallocated and reset the pointer, but it will be easy just to delete the field as unused.

This pull request has now been integrated.

Changeset: 73101314
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7310131409d3be351e780696173e7354ab51e467
Stats:     13 lines in 5 files changed: 0 ins; 10 del; 3 mod

8299337: The java.awt.image.ColorModel#pData field is unused

Reviewed-by: prr

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

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


From duke at openjdk.org  Fri Jan  6 23:13:09 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 6 Jan 2023 23:13:09 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v2]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <QUOGIQWxLc_RT0xtonZXdnCxSUR7Gkw3vj4MSp8wiW8=.23bbeb90-21fe-435a-a4e3-d631ebab9ad6@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright year for newly added files to 2023.
 - Suppress "this-escape" warnings using build flags instead of @SuppressAnnotations annotations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/9c162283..f667cd56

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

  Stats: 1935 lines in 1303 files changed: 60 ins; 1770 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

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


From duke at openjdk.org  Fri Jan  6 23:13:09 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 6 Jan 2023 23:13:09 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
 <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
 <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
Message-ID: <D_16yzU3GKCNp3muk32Ykwpy9od0qdOohTmBO8Gt_Es=.c914efeb-2b98-44ef-891a-7480fb094315@github.com>

On Fri, 6 Jan 2023 15:38:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere?
>> 
>> Hi @dholmes-ora,
>> 
>> The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc.
>> 
>> Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds.
>> 
>> Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. 
>> 
>>> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details.
>> 
>> Hi @AlanBateman,
>> 
>> As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well.
>> 
>>> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially.
>> 
>> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?
>> 
>> If this is generally agreed as a better route then let me know and I'll update the patch.
>> 
>> Thanks for both of your comments.
>
>> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?
>> 
>> If this is generally agreed as a better route then let me know and I'll update the patch.
> 
> Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it.

Hi @AlanBateman,

OK that sounds like a plan. I've pushed a new commit to the `ThisEscape` branch that removes all the`@SuppressWarnings` annotations and replaces them with adjustments to build flags.

I've moved the `@SuppressWarnings` annotations onto a new branch `ThisEscapeAnnotations`. This is just for future reference in case somebody wants to add them back someday and doesn't want to start from scratch.

>  I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it.

Hmm. Hasn't that horse already left the barn? You kind of implied that when you said:

> I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor.

In other words, it doesn't sound like changing the behavior of these constructors is viable option at this point. And if that's the case, we might as well document and warn about the current behavior.

Of course I'd love to be wrong... in which case, we can fix these constructors.

Or, the third option - just do nothing yet. That would mean removing the warnings, which is fine.

But then the `ThisEscape.html` document is orphaned. What should we do with it? I can remove it, just leave it there, or put it somewhere else (where?).

It seems like having some documentation of the meaning of "this escape" would be helpful, because it's a subtle concept and there are multiple ways to define "escape".

Thanks.

@mcimadamore thanks for the bugs suggestion, I'll put that on the to-do list.

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

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


From dnguyen at openjdk.org  Fri Jan  6 23:20:51 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 6 Jan 2023 23:20:51 GMT
Subject: RFR: 8299309: Test
 "java/awt/Dialog/ModalDialogTest/ModalDialogTest.java" fails because new frame
 was not displayed when "New Frame" button was clicked
In-Reply-To: <br2h0HuFz8KcbRSyzPJeqj-_gLWwYf5yn4Wi17z76tk=.8ec014f8-a081-4cf1-98f8-fafe20d83c5c@github.com>
References: <br2h0HuFz8KcbRSyzPJeqj-_gLWwYf5yn4Wi17z76tk=.8ec014f8-a081-4cf1-98f8-fafe20d83c5c@github.com>
Message-ID: <YMj8__hxzmmF0H2sdMcYPSXSUU3UJxfWN7CUVcDNmKg=.1092dad8-f016-4e37-98ca-92277a522e3e@github.com>

On Thu, 5 Jan 2023 05:26:26 GMT, Tejesh R <tr at openjdk.org> wrote:

> Windows count check was added as part of [JDK-8290469](https://bugs.openjdk.org/browse/JDK-8290469) fix, to avoid window positional shift which happens during application startup. The condition handled only for windows type of Window and not for Frame/Dialog which is the root cause for the bug. I have updated the condition for other Window types as a fix.

Tested before and after applying the fix. New frame appears as expected after the fix, when nothing appeared before the fix. Looks good.

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

Marked as reviewed by dnguyen (Author).

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


From duke at openjdk.org  Sat Jan  7 01:41:50 2023
From: duke at openjdk.org (SWinxy)
Date: Sat, 7 Jan 2023 01:41:50 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
Message-ID: <IWDHVDL2qYoLO3Ba1TcfTsRqWuz9vMLrv5mOtkPKKGw=.9b5d355e-6271-4b30-9645-a2792936efb7@github.com>

On Fri, 6 Jan 2023 04:42:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems Synth has two cases of updateStyle() where its argument is not passed to the getContext() call. It seems to be an oversight as in other Synth classes, the component argument passed to updateStyle is being passed to getContext().
> 
> CI tests are ok with this change and there is no new regeression with CI tests run in NimbusL&F by default..

I'm seeing a slightly larger problem of inconsistencies as to what is passed into the `updateStyle` methods. `SynthInternalFrameTitlePane` passes `this` to `getContext`, while nothing else does. `SynthInternalFrameTitlePane` and `SynthComboBoxUI` don't pass in the event source in their `propertyChange` methods unlike everything else. `SynthTextFieldUI` and `SynthTextAreaUI` passes in a call to `getComponent()`, while e.g. `SynthTableHeaderUI` passes in the protected field. Inconsistent!

I don't think this change will do anything bad though.

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

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


From prr at openjdk.org  Sat Jan  7 02:08:52 2023
From: prr at openjdk.org (Phil Race)
Date: Sat, 7 Jan 2023 02:08:52 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v3]
In-Reply-To: <23xwHp6apwTTidFVoGzCjc-oSkW7v8hOVFZ4D_lP6c0=.eba74ea0-5731-4c4a-a971-95ec36248796@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <23xwHp6apwTTidFVoGzCjc-oSkW7v8hOVFZ4D_lP6c0=.eba74ea0-5731-4c4a-a971-95ec36248796@github.com>
Message-ID: <Y9AqFnzido6ZAEs1l0B4zaaYTdqpui1QQHKr9TteonY=.2dd50d2d-9a82-4dca-9a46-dd422d836f4c@github.com>

On Thu, 29 Dec 2022 06:22:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
>> says:
>> "...MetalLookAndFeel registers an entry for each of the classes
>> in the package javax.swing.plaf.metal that are named MetalXXXUI.
>> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
>> that do not have a class in metal, the corresponding class in
>> javax.swing.plaf.basic is used. For example, metal does not
>> have a class named "MetalColorChooserUI", as such,
>> javax.swing.plaf.basic.BasicColorChooserUI is used".
>> 
>> There is class MetalMenuBarUI, but the method populates given defaults table with the value
>> "javax.swing.plaf.basic.BasicMenuBarUI".
>> 
>> Added entry for MetalMenuBarUI..
>> CI tests including JCK tests are ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spec update

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java line 255:

> 253:      * "MetalColorChooserUI"}, as such, {@code
> 254:      * javax.swing.plaf.basic.BasicColorChooserUI} is used.
> 255:      * It is to be noted that some MetalXXXUI classes can be used only by

Seems to me that this needs to be introduced in the previous paragraph otherwise you are revising what is said there in an awkward way.

So we can add to "{@code
     * MetalLookAndFeel} registers an entry for each of the classes in
     * the package {@code javax.swing.plaf.metal} that are named
     * MetalXXXUI"
   just this one extra clause :
", which are used by the current {@code MetalTheme}"

Technically that is ALL that is needed.

But at line 255 we then can (since 252- 254 already set precedent) say
"And {@code MetalMenuBarUI} is an  example of a UI class that is used only by one provided theme : {@code OceanTheme}, and therefore will not be registered by the other provided themes"

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

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


From prr at openjdk.org  Sat Jan  7 02:21:55 2023
From: prr at openjdk.org (Phil Race)
Date: Sat, 7 Jan 2023 02:21:55 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v3]
In-Reply-To: <23xwHp6apwTTidFVoGzCjc-oSkW7v8hOVFZ4D_lP6c0=.eba74ea0-5731-4c4a-a971-95ec36248796@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <23xwHp6apwTTidFVoGzCjc-oSkW7v8hOVFZ4D_lP6c0=.eba74ea0-5731-4c4a-a971-95ec36248796@github.com>
Message-ID: <B6D0PzCSu9-jXcKh_LGLnn212HtK_N6txx5odEG4zU8=.93a86e0e-3a40-4dc3-bbf5-71908cb39af9@github.com>

On Thu, 29 Dec 2022 06:22:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
>> says:
>> "...MetalLookAndFeel registers an entry for each of the classes
>> in the package javax.swing.plaf.metal that are named MetalXXXUI.
>> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
>> that do not have a class in metal, the corresponding class in
>> javax.swing.plaf.basic is used. For example, metal does not
>> have a class named "MetalColorChooserUI", as such,
>> javax.swing.plaf.basic.BasicColorChooserUI is used".
>> 
>> There is class MetalMenuBarUI, but the method populates given defaults table with the value
>> "javax.swing.plaf.basic.BasicMenuBarUI".
>> 
>> Added entry for MetalMenuBarUI..
>> CI tests including JCK tests are ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spec update

We need to clarify here what we want before the CSR can be completed.
One comment in the draft CSR got my attention -

"MetalMenuBarUI entry is not registered in this method although is is part of javax.swing.plaf.metal since it is registered in OceanTheme class, which is used by MetalLookAndFeel by default."

Hmm .. so now I'm wondering if we are phrasing things correctly.
If themes register the UIs they use why does this method do *anything*  ?
Or is there some *assumption* that all themes use MOST of them and so they are always registerr but
some UIs are registered only by themes that use them ? 
You tell me what actually happens and I can help you word it.

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

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


From serb at openjdk.org  Sat Jan  7 07:45:54 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 7 Jan 2023 07:45:54 GMT
Subject: RFR: 4934362: see also refers to self [v3]
In-Reply-To: <idlyKRTbDb6VogUoZvjwaX-ZeEmNvmDuzgNOO6EaxcA=.752dc524-62de-4c89-a6e7-cea726a3be61@github.com>
References: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
 <idlyKRTbDb6VogUoZvjwaX-ZeEmNvmDuzgNOO6EaxcA=.752dc524-62de-4c89-a6e7-cea726a3be61@github.com>
Message-ID: <VjvqgXXtBj2AJwzLzAWq8UfZijkBmWWhhcLYpxkRYQk=.bb47ad2d-5b6a-43d9-8ccf-c93e80f176a4@github.com>

On Fri, 6 Jan 2023 05:57:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Some methods and constants has a hyperreference to self in javadoc which is rectified to reference proper methods
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rectified link

src/java.desktop/share/classes/javax/swing/JComboBox.java line 158:

> 156:      * or override. Use the accessor methods instead.
> 157:      *
> 158:      * @see #isEditable

probably it was planned to point to the isEditable method?

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

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


From serb at openjdk.org  Sat Jan  7 08:33:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 7 Jan 2023 08:33:50 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <0mjOBQIb2FDS1gK5O3f3YxrOHFqYVotIc-AQTwr8Nxk=.5dc28f99-7d0b-45da-8a95-46a9d24deea0@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
 <0mjOBQIb2FDS1gK5O3f3YxrOHFqYVotIc-AQTwr8Nxk=.5dc28f99-7d0b-45da-8a95-46a9d24deea0@github.com>
Message-ID: <7FZyi4OAkHuq-dDeU_wJgWhENveXcRkUQA2Mlt4G2dM=.90c42eeb-51f6-4e2c-8f06-139de0fffb6b@github.com>

On Fri, 6 Jan 2023 12:59:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Also, looking at other Synth classes, it seems to be the way to go to maintain consistency

But I think we should understand what goes wrong when we pass current values, and what we fix by this change.

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

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


From duke at openjdk.org  Sat Jan  7 16:24:56 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 7 Jan 2023 16:24:56 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v2]
In-Reply-To: <QUOGIQWxLc_RT0xtonZXdnCxSUR7Gkw3vj4MSp8wiW8=.23bbeb90-21fe-435a-a4e3-d631ebab9ad6@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <QUOGIQWxLc_RT0xtonZXdnCxSUR7Gkw3vj4MSp8wiW8=.23bbeb90-21fe-435a-a4e3-d631ebab9ad6@github.com>
Message-ID: <xWYztLE9Mx-jVzvGesQ0jF5PXrQYZE_aDpOvZ6EW5K8=.70ef0e5d-3fcc-4428-bbc4-d2847fd57e69@github.com>

On Fri, 6 Jan 2023 23:13:09 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year for newly added files to 2023.
>  - Suppress "this-escape" warnings using build flags instead of @SuppressAnnotations annotations.

src/java.base/share/classes/java/lang/AssertionError.java line 75:

> 73:      */
> 74:     @SuppressWarnings("this-escape")
> 75:     public AssertionError(Object detailMessage) {

The?Javadoc of?this?constructor should?probably?mention that?it?calls `initCause(?)` when?`detailMessage` is?a?`Throwable`.

src/java.base/share/classes/java/lang/BootstrapMethodError.java line 77:

> 75:      * Constructs a {@code BootstrapMethodError} with the specified
> 76:      * cause.
> 77:      *

Suggestion:

     *
     * @implNote This constructor invokes {@link #initCause initCause()}; see
     * <a href="{@docRoot}/java.base/java/lang/doc-files/ThisEscape.html">This Escape</a>.
     *

src/java.base/share/classes/java/lang/ExceptionInInitializerError.java line 54:

> 52:      * throwable object.
> 53:      * A detail message is a String that describes this particular exception.
> 54:      */

Suggestion:

     *
     * @implNote This constructor invokes {@link #initCause initCause()}; see
     * <a href="{@docRoot}/java.base/java/lang/doc-files/ThisEscape.html">This Escape</a>.
     */

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

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


From duke at openjdk.org  Sat Jan  7 16:58:58 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 7 Jan 2023 16:58:58 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v3]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <TpQ6WIGxsY1KZfY8qSobqotTj6nA5EQe7VCH8mRxe80=.48fb5e57-210b-48dc-bf00-7221e4ce1bcb@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Add a few more Javadoc warnings for 'this' escape via initCause().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/f667cd56..398737fa

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

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

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


From alanb at openjdk.org  Sat Jan  7 18:05:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 7 Jan 2023 18:05:50 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <D_16yzU3GKCNp3muk32Ykwpy9od0qdOohTmBO8Gt_Es=.c914efeb-2b98-44ef-891a-7480fb094315@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
 <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
 <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
 <D_16yzU3GKCNp3muk32Ykwpy9od0qdOohTmBO8Gt_Es=.c914efeb-2b98-44ef-891a-7480fb094315@github.com>
Message-ID: <iK8Zd1oZLhFZu3nWbKaBtLD0GrYVEd0iVJDbyWKhwVY=.c1066a2c-882e-4498-a9a2-5a8a78fbbfe5@github.com>

On Fri, 6 Jan 2023 23:08:27 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> I've moved the `@SuppressWarnings` annotations onto a new branch `ThisEscapeAnnotations`. This is just for future reference in case somebody wants to add them back someday and doesn't want to start from scratch.
> 
> > I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it.
> 
> Hmm. Hasn't that horse already left the barn? You kind of implied that when you said:
> 
> > I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor.
> 
> In other words, it doesn't sound like changing the behavior of these constructors is viable option at this point. And if that's the case, we might as well document and warn about the current behavior.
> 
> Of course I'd love to be wrong... in which case, we can fix these constructors.

I hope at least some of these can be fixed as leaking a part initialized object to an untrusted subclass or some other code is problematic in many ways. Skimming through the original list, then some of these may be accidental and some may be fixable without any compatibility concerns, esp. in the JDK internal classes. Yes, some horses have left the barn. A horse that got out a long time ago is j.net.ServerSocket where 3 of its constructors call an overridable bind method. Recent re-implementation would have fixed this but there were concerns that subclasses may be relying on this long standing undocumented behavior. There are other cases in the list where the leaking may be necessary part of the contract for subclasses. So it will probably require working through them on a case by case basis. I don't think the implementation notes should be included as part of the adding the lint warning as I think it creates an attractive nuisance. Developers reading these implementation notes may c
 reate code that depends on these "hooks" and it will make it very hard for the JDK to ever change the behavior. Where the leaking is a necessary part of the contract for subclassing then it may be that it has to be documented as normative text rather than an implementation note.

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

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


From duke at openjdk.org  Sat Jan  7 19:52:49 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 7 Jan 2023 19:52:49 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <iK8Zd1oZLhFZu3nWbKaBtLD0GrYVEd0iVJDbyWKhwVY=.c1066a2c-882e-4498-a9a2-5a8a78fbbfe5@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
 <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
 <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
 <D_16yzU3GKCNp3muk32Ykwpy9od0qdOohTmBO8Gt_Es=.c914efeb-2b98-44ef-891a-7480fb094315@github.com>
 <iK8Zd1oZLhFZu3nWbKaBtLD0GrYVEd0iVJDbyWKhwVY=.c1066a2c-882e-4498-a9a2-5a8a78fbbfe5@github.com>
Message-ID: <kqQTTj7gYjBC70LCPLNbpfnBbTjyDTLsFX4Gvc0WO_g=.07f26c0d-b006-41fd-9cd5-48255a921d57@github.com>

On Sat, 7 Jan 2023 18:03:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I don't think the implementation notes should be included as part of the adding the lint warning as I think it creates an attractive nuisance.

I agree with you - not only for that reason, but also because as others have pointed out the addition of the warning is really a separate task from the evaluation and triage of any existing leaks. Moreover, this latter task is really multiple separate tasks that belong to the various module/functional groups.

I'll remove all the Javadoc `@implNote`'s from the patch, and `src/java.base/share/classes/java/lang/doc-files/ThisEscape.html` as well - it will still be available in the git history if someone comes up with a better home for it.

This will also further reduce the number of labels and therefore required reviewers.

Thanks.

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

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


From duke at openjdk.org  Sat Jan  7 19:59:59 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 7 Jan 2023 19:59:59 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v4]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <lW3XeWImW3aoe4zyqD6Bm81B6VLrlnhmEYzKA0lwT-s=.7aa83963-79c0-4d92-a37a-47349122d1ef@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Remove Javadoc @implNotes; plan to triage the various existing leaks separately.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/398737fa..537b3e3c

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

  Stats: 255 lines in 29 files changed: 0 ins; 251 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

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


From duke at openjdk.org  Sat Jan  7 21:08:07 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 7 Jan 2023 21:08:07 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Fix incorrect @bug numbers in unit tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/537b3e3c..7e2fdb07

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

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

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


From serb at openjdk.org  Sun Jan  8 09:12:55 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 8 Jan 2023 09:12:55 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <c4Qx6gF9iiaJdMaOybsl_4cNgqu8KPNOQQH2zBDAOzU=.a72f2f21-5212-4337-b3f3-ccff0a39c728@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
 <DD5uVC90-DPgmwfJXNEgnLj_wxHGTD7_uKMZBwNLHa8=.6a564a17-23d4-4da8-8381-c882b852aaaa@github.com>
 <c4Qx6gF9iiaJdMaOybsl_4cNgqu8KPNOQQH2zBDAOzU=.a72f2f21-5212-4337-b3f3-ccff0a39c728@github.com>
Message-ID: <jH6H-chU7-m3gPJRb1v2StPHplL06eKXHvUIrxV-FYE=.f6f34982-26c3-43b9-9ac0-ddb1a4fd1c9a@github.com>

On Tue, 3 Jan 2023 05:19:55 GMT, Tejesh R <tr at openjdk.org> wrote:

> I have tested in headful system multiple time, never reproduced this issue...... Can timing affect in headless and not in headful......?

It should not. Does it actually have any dependency on "headful" envirement? The native code we used does not create any UI element or something like that. It is better to debug it on the same/similar config/system where the bug is reproduced, since as far as I understand it is not a rare case.

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

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


From smandalika at openjdk.org  Sun Jan  8 09:12:58 2023
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Sun, 8 Jan 2023 09:12:58 GMT
Subject: Integrated: 8298921: Create a regression test for JDK-8139581
In-Reply-To: <lkasNa1F7wgDFUbBBlSzzve1p3DmJHqmyV6ELZd_BQs=.51d1cbf0-3c97-40d4-8892-d6c214674d94@github.com>
References: <lkasNa1F7wgDFUbBBlSzzve1p3DmJHqmyV6ELZd_BQs=.51d1cbf0-3c97-40d4-8892-d6c214674d94@github.com>
Message-ID: <7vvnj9UJUw3j-oWD37zenfI4oLm5AOMHmu-YfLGo-rQ=.f3a5e521-ebd8-4028-89b0-5f90103170ed@github.com>

On Fri, 16 Dec 2022 10:21:35 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create a regression test for JDK-8139581
> 
> As described in JDK-8139581, when an AWT panel with AWT components, for example "java.awt.Button", is removed from AWT frame and added again to the same frame, then some AWT components contained in the panel are not drawn, however, clicking in the area of not drawn button leads to drawing of the button.
> 
> Test has a swing and awt component in a panel. It then removes and adds back the panel from/into the frame, to verify that they are repainted back properly.

This pull request has now been integrated.

Changeset: 834e50e9
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/834e50e9efc16effad7469cae99ab8f918a30e86
Stats:     198 lines in 1 file changed: 198 ins; 0 del; 0 mod

8298921: Create a regression test for JDK-8139581

Reviewed-by: serb

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

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


From tamasflaviu at gmail.com  Sun Jan  8 17:01:25 2023
From: tamasflaviu at gmail.com (Flaviu Tamas)
Date: Sun, 8 Jan 2023 12:01:25 -0500
Subject: [PATCH] 7000965: Paste fails when X clipboard is in a certain
 state
In-Reply-To: <CAKCn7JHPUDzbPZvPyT3rHjU8rhsnVOTnr=WSNLSBdd5emdPg7g@mail.gmail.com>
References: <CAKCn7JHPUDzbPZvPyT3rHjU8rhsnVOTnr=WSNLSBdd5emdPg7g@mail.gmail.com>
Message-ID: <CAKCn7JFUQROriS6tHcPkf4Djo6F8Tg-Y1hZ1uajkF7N61umtSw@mail.gmail.com>

Hi, following up here. Turns out this bug has already been reported:
https://bugs.openjdk.org/browse/JDK-7000965

Would appreciate it if someone would sponsor this work, as described
in https://openjdk.org/contribute/, section 4.

On Mon, Jan 2, 2023 at 8:00 AM Flaviu Tamas <tamasflaviu at gmail.com> wrote:
>
> Sometimes, the X clipboard is in some state that causes pastes to fail
> with the following, or similar, stack traces:
>
> java.lang.NullPointerException
> : Failed to retrieve atom name.
>     at java.desktop/sun.awt.X11.XlibWrapper.XGetAtomName(Native Method)
>     at java.desktop/sun.awt.X11.XAtom.getName(XAtom.java:189)
>     at java.desktop/sun.awt.X11.XDataTransferer.getTargetNameForAtom(XDataTransferer.java:172)
>     at java.desktop/sun.awt.X11.XDataTransferer.getNativeForFormat(XDataTransferer.java:161)
>     at java.desktop/sun.awt.datatransfer.DataTransferer.getFlavorsForFormatsAsSet(DataTransferer.java:487)
>     at java.desktop/sun.awt.datatransfer.SunClipboard.formatArrayAsDataFlavorSet(SunClipboard.java:342)
>     at java.desktop/sun.awt.datatransfer.SunClipboard.isDataFlavorAvailable(SunClipboard.java:185)
>
> This is a widespread issue and very frustrating issue, see:
>
> - https://youtrack.jetbrains.com/issue/JBR-438/Clipboard-operations-arent-working-in-certain-state-of-Xorg-selection-buffers
> - https://www.google.com/search?q="Failed+to+retrieve+atom+name"+"DataTransferer"
>
> Frankly, I don't understand how X works at all, or how this issue
> arises. However, this same workaround was applied to Mozilla in 2010:
> https://hg.mozilla.org/releases/mozilla-1.9.1/rev/62f3d28797e2, and I
> don't see any reasonable behavior that having this workaround in place
> would break. The workaround works by simply skipping native formats
> that don't have a name.
>
> Verified to work by running IntelliJ Clion under the modified VM and
> verifying that paste from my terminal, which previously did not work,
> now works. I'm not familiar with OpenJDK unit testing conventions, but
> I believe this change falls under the "highly platform-dependent"
> exception.


From mik3hall at gmail.com  Sun Jan  8 18:04:16 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 8 Jan 2023 12:04:16 -0600
Subject: OS/X GUI applications
In-Reply-To: <629416D3-AA95-4B07-903B-FCF264FF8A42@gmail.com>
References: <CA1D7F10-343A-4052-8E35-D21C32F9719B@gmail.com>
 <22d33eca-eb38-8401-291a-c7a62c25d1ee@oracle.com>
 <12bbb5e2-dc26-5bbe-22e5-816027ffc32b@oracle.com>
 <629416D3-AA95-4B07-903B-FCF264FF8A42@gmail.com>
Message-ID: <1409C528-2A83-4A41-B3BE-4FFB869748E7@gmail.com>



> On Jan 6, 2023, at 4:35 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> I haven?t verified if this would further allow changing the java.awt.Desktop about handler. 

I did check that custom AboutHandlers are possible for OS/X JavaFX applications. 
With?

	static {
		//java.awt.Toolkit.getDefaultToolkit(); // Start AppKit
		Thread t = new Thread(() -> { java.awt.Toolkit.getDefaultToolkit(); });
      	t.start();  
	}

I made the Application class itself the handler?

public class HelloWorld extends Application implements AboutHandler {

Setting the handler seemed to also need some thread management.

	@Override
	public void init() {
    	Thread t = new Thread(() -> {
			Desktop desktop = Desktop.getDesktop();
			desktop.setAboutHandler((AboutHandler)this);   
		});
		t.start();		  				
	}

It appeared this could be done in the init or about anywhere in the javaFX start method.

The handler I think comes in on the AWT EventQueue so needs to be changed to javaFX

    public void handleAbout(AboutEvent evt) {
    	System.out.println("got to handleAbout");
    	Platform.runLater(() -> {
    		Alert alert = new Alert(AlertType.INFORMATION, "About HelloWorld");
			alert.showAndWait();
		});
    }

Checking on Windows 10 VirtualBox it appeared Desktop.Action.APP_ABOUT isn?t supported. 
I had trouble with my VirtualBox linux images so didn?t verify there but I?m guessing this is viewed as OS/X only and not supported there either.

I never really did determine why javaFX applications are different. My last thought had been that they instantiated an NSApplication early so a NSApplicationAWT wss never obtained. However, I later thought I saw where I passed a check indicating I had to have NSApplicationAWT. With a fix so you get the About menu item it seemed a little moot. What I provided for ApplicationDelegate seems to be one such fix. You can come up with your own fix but I think it will need to done jdk side though to provide this functionality to javafx app?s. I might bring this up on the javafx list if the jdk does make it possible at some point.

I haven?t looked at any other Desktop functionality for javafx app?s yet having no immediate need myself.   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230108/3e40e594/attachment.htm>

From duke at openjdk.org  Sun Jan  8 21:02:19 2023
From: duke at openjdk.org (SWinxy)
Date: Sun, 8 Jan 2023 21:02:19 GMT
Subject: RFR: 8299774: SYNTH_BUTTON_UI_KEY field is unused
Message-ID: <fxswCm94cFN0rMWIU37GW0akeC9VvEbmWqtol95I8Gk=.f207d96a-dd29-432b-87ae-f93227935689@github.com>

Added in JDK-8192888, and became unused in JDK-8213843.

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

Commit messages:
 - SYNTH_BUTTON_UI_KEY field is unused

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

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


From serb at openjdk.org  Sun Jan  8 21:02:19 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 8 Jan 2023 21:02:19 GMT
Subject: RFR: 8299774: SYNTH_BUTTON_UI_KEY field is unused
In-Reply-To: <fxswCm94cFN0rMWIU37GW0akeC9VvEbmWqtol95I8Gk=.f207d96a-dd29-432b-87ae-f93227935689@github.com>
References: <fxswCm94cFN0rMWIU37GW0akeC9VvEbmWqtol95I8Gk=.f207d96a-dd29-432b-87ae-f93227935689@github.com>
Message-ID: <dOcqZjGxp1chkA1m4GTKhrphSkxWJOfCFgvB0jsuo1U=.957f6347-15cb-4639-82a6-c3c7c0785d59@github.com>

On Sat, 7 Jan 2023 03:34:02 GMT, SWinxy <duke at openjdk.org> wrote:

> Added in JDK-8192888, and became unused in JDK-8213843.

The change looks fine

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

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


From serb at openjdk.org  Mon Jan  9 01:45:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 9 Jan 2023 01:45:50 GMT
Subject: RFR: 8299774: SYNTH_BUTTON_UI_KEY field is unused
In-Reply-To: <fxswCm94cFN0rMWIU37GW0akeC9VvEbmWqtol95I8Gk=.f207d96a-dd29-432b-87ae-f93227935689@github.com>
References: <fxswCm94cFN0rMWIU37GW0akeC9VvEbmWqtol95I8Gk=.f207d96a-dd29-432b-87ae-f93227935689@github.com>
Message-ID: <Zp4s1SYxhFL0GjJyjenFhWu5VlSaCNXP0mxP6HszUhI=.c9d30ce3-ee81-4b65-8d2a-19e93c95982f@github.com>

On Sat, 7 Jan 2023 03:34:02 GMT, SWinxy <duke at openjdk.org> wrote:

> Added in JDK-8192888, and became unused in JDK-8213843.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.org  Mon Jan  9 01:48:52 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 9 Jan 2023 01:48:52 GMT
Subject: RFR: 8282217: Key events (key char and key code) changed for Swiss
 keyboard
In-Reply-To: <N9XfS6cL8s1G98UAiEr7ZvgzQB-HX6qKGptKZe7d810=.1f5932c5-fd00-4fe8-9c0b-99f2fa71d880@github.com>
References: <N9XfS6cL8s1G98UAiEr7ZvgzQB-HX6qKGptKZe7d810=.1f5932c5-fd00-4fe8-9c0b-99f2fa71d880@github.com>
Message-ID: <qlEi63Fl_MSwmqrQuk2W55jesDZzugAYFwRAKmSmhZE=.5ab838b1-2443-4b9b-9c20-f8b272812d83@github.com>

On Fri, 6 Jan 2023 22:07:33 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removed check for MapVirtualKeyEx return value causing some keys to become undefined

That check was added as part of the https://bugs.openjdk.org/browse/JDK-8139189, can we check that functionality is not broken by the current change?

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

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


From serb at openjdk.org  Mon Jan  9 01:49:57 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 9 Jan 2023 01:49:57 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel [v2]
In-Reply-To: <IUkFswHdUwx2qx6lj6pEWtsAd6yS7N6EQj4G4iV_OMM=.d3edd5a8-6bbe-4540-b1b5-0be110f1410a@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
 <IUkFswHdUwx2qx6lj6pEWtsAd6yS7N6EQj4G4iV_OMM=.d3edd5a8-6bbe-4540-b1b5-0be110f1410a@github.com>
Message-ID: <NZYGr8xrQFS_OlavTVvWFGZH1qXapUcS79LFTnekr7g=.26ecbcdc-8808-4c11-bf7e-9836f6307a50@github.com>

On Thu, 22 Dec 2022 10:35:32 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> In case of GTK LAF, the current selected element was not visible due to arrowbutton is rendered in entire display area of Combobox.
>> 
>> The proposed fix is to set the `squareButton `property of combobox to `false `so that the arrowbutton didn't take entire combobox display area for rendering. The `getMinimumSize `method is overridden in `SynthComboBoxUI `to consider **arrowbutton insets** for combobox minimum size. 
>> 
>> The JCK tests mentioned in JBS seems fine with the fix. 
>> An automated test case is implemented to test in Nimbus and GTK LAF. The text color check is to ensure the current selected item is visible.
>> 
>> When clientlibs tests are run with LAF set to Nimbus and GTK LAF, few test failures observed. 
>> 
>> `javax/swing/JComboBox/4523758/bug4523758.java` test failed with current fix in GTK LAF.
>> `open/test/jdk/javax/swing/JComboBox/TestComboBoxHeight.java` test passes if run in GTK LAF with current fix.
>> 
>> In Nimbus LAF, the failures before and after fix has no issues as such.
>> 
>> Although CI jobs looks ok with tests run in their default set LAFs.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Review comment update
>  - Merge
>  - Merge
>  - Combobox componnet rendering fix

Marked as reviewed by serb (Reviewer).

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

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


From duke at openjdk.org  Mon Jan  9 02:19:54 2023
From: duke at openjdk.org (SWinxy)
Date: Mon, 9 Jan 2023 02:19:54 GMT
Subject: Integrated: 8299774: SYNTH_BUTTON_UI_KEY field is unused
In-Reply-To: <fxswCm94cFN0rMWIU37GW0akeC9VvEbmWqtol95I8Gk=.f207d96a-dd29-432b-87ae-f93227935689@github.com>
References: <fxswCm94cFN0rMWIU37GW0akeC9VvEbmWqtol95I8Gk=.f207d96a-dd29-432b-87ae-f93227935689@github.com>
Message-ID: <Zl43-TYUobYnEcHSGjk3_8pJp3jO6vvldLCAyaoItlM=.c6403c83-3b22-4445-830c-daa6c81cd6b5@github.com>

On Sat, 7 Jan 2023 03:34:02 GMT, SWinxy <duke at openjdk.org> wrote:

> Added in JDK-8192888, and became unused in JDK-8213843.

This pull request has now been integrated.

Changeset: 7607c07e
Author:    SWinxy <swinxythecat at gmail.com>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7607c07e002cd86cf2a0f44df9933612550ced95
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8299774: SYNTH_BUTTON_UI_KEY field is unused

Reviewed-by: serb

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

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


From psadhukhan at openjdk.org  Mon Jan  9 03:57:17 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 9 Jan 2023 03:57:17 GMT
Subject: RFR: 4934362: see also refers to self [v4]
In-Reply-To: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
References: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
Message-ID: <YYfN2px7U82QiuHv4HHIe-5PGuaPfpx6D2lgL1np1BI=.263bd130-df76-44c3-b2a2-70f4e6d3e9d6@github.com>

> Some methods and constants has a hyperreference to self in javadoc which is rectified to reference proper methods

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

  Point to isEditable method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11820/files
  - new: https://git.openjdk.org/jdk/pull/11820/files/bfa5497c..8e6465a8

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

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

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


From tr at openjdk.org  Mon Jan  9 04:37:54 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 9 Jan 2023 04:37:54 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <jH6H-chU7-m3gPJRb1v2StPHplL06eKXHvUIrxV-FYE=.f6f34982-26c3-43b9-9ac0-ddb1a4fd1c9a@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
 <DD5uVC90-DPgmwfJXNEgnLj_wxHGTD7_uKMZBwNLHa8=.6a564a17-23d4-4da8-8381-c882b852aaaa@github.com>
 <c4Qx6gF9iiaJdMaOybsl_4cNgqu8KPNOQQH2zBDAOzU=.a72f2f21-5212-4337-b3f3-ccff0a39c728@github.com>
 <jH6H-chU7-m3gPJRb1v2StPHplL06eKXHvUIrxV-FYE=.f6f34982-26c3-43b9-9ac0-ddb1a4fd1c9a@github.com>
Message-ID: <hxhpzs0b1OYYP580dKMElrjxcGVv8mlWb3zH81lb3jg=.e2c5a620-0991-42f7-9294-613fc4956f17@github.com>

On Sun, 8 Jan 2023 09:09:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I have tested in headful system multiple time, never reproduced this issue...... Can timing affect in headless and not in headful......?
> 
> It should not. Does it actually have any dependency on "headful" envirement? The native code we used does not create any UI element or something like that. It is better to debug it on the same/similar config/system where the bug is reproduced, since as far as I understand it is not a rare case.

I don't think there is any dependency on "headful". The occurrence was very random, like sometime issue used to show up repeatedly for test runs, and the very next week there were no occurrences, and the occurrence was not fixed for any particular path/folder, it used to vary (For headful). I was able to debug and understand that backup mechanism failed at random intervals, so had to conclude that it had to something to do with headful.

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

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


From abhiscxk at openjdk.org  Mon Jan  9 04:52:03 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 9 Jan 2023 04:52:03 GMT
Subject: Integrated: 8218474: JComboBox display issue with GTKLookAndFeel
In-Reply-To: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
Message-ID: <2QoY6M_vuvwG2TQrydzIqzPezQz2yBeuvnNo196QPAA=.e7e4681a-abc8-4bc4-99c1-b3fafcf56cf4@github.com>

On Wed, 7 Dec 2022 10:25:31 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> In case of GTK LAF, the current selected element was not visible due to arrowbutton is rendered in entire display area of Combobox.
> 
> The proposed fix is to set the `squareButton `property of combobox to `false `so that the arrowbutton didn't take entire combobox display area for rendering. The `getMinimumSize `method is overridden in `SynthComboBoxUI `to consider **arrowbutton insets** for combobox minimum size. 
> 
> The JCK tests mentioned in JBS seems fine with the fix. 
> An automated test case is implemented to test in Nimbus and GTK LAF. The text color check is to ensure the current selected item is visible.
> 
> When clientlibs tests are run with LAF set to Nimbus and GTK LAF, few test failures observed. 
> 
> `javax/swing/JComboBox/4523758/bug4523758.java` test failed with current fix in GTK LAF.
> `open/test/jdk/javax/swing/JComboBox/TestComboBoxHeight.java` test passes if run in GTK LAF with current fix.
> 
> In Nimbus LAF, the failures before and after fix has no issues as such.
> 
> Although CI jobs looks ok with tests run in their default set LAFs.

This pull request has now been integrated.

Changeset: c4449224
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Committer: Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c4449224bbb70d1a0256ebf19297450ab0f98d4b
Stats:     182 lines in 5 files changed: 180 ins; 0 del; 2 mod

8218474: JComboBox display issue with GTKLookAndFeel

Reviewed-by: tr, serb

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

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


From mvs at openjdk.org  Mon Jan  9 06:01:58 2023
From: mvs at openjdk.org (Manukumar V S)
Date: Mon, 9 Jan 2023 06:01:58 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <z3JtNXaiKFA7HEvGGDj1_18JGSa6HVUDqe7rIAgfCx8=.204b76cc-b24a-4988-80d3-4cc291349f0b@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
 <z3JtNXaiKFA7HEvGGDj1_18JGSa6HVUDqe7rIAgfCx8=.204b76cc-b24a-4988-80d3-4cc291349f0b@github.com>
Message-ID: <Z_YvwJVJ3HdLNI46h-xCSt1tklBC8q3-bFtOw60FzBU=.5ad19ea7-fa4b-474f-81e5-0a65ba050ec9@github.com>

On Tue, 3 Jan 2023 16:45:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I also suggest removing the second asterisk at line 43, so that jtreg tags don't result javadoc warnings.
> 
> If you also remove `throws Exception` clause from `openPopup`, the test will become warning-free.

Fixed the review comments and updated the test.

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

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


From mvs at openjdk.org  Mon Jan  9 06:04:52 2023
From: mvs at openjdk.org (Manukumar V S)
Date: Mon, 9 Jan 2023 06:04:52 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v2]
In-Reply-To: <NSe5ZVQIz159nKk8zeuC-O01YzdbdBbKXM5Wlo3aqtE=.4fcd9130-ed6a-4508-bad4-fce86ee3093d@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
 <NSe5ZVQIz159nKk8zeuC-O01YzdbdBbKXM5Wlo3aqtE=.4fcd9130-ed6a-4508-bad4-fce86ee3093d@github.com>
Message-ID: <eYC0uuuWyarbiStEetDZpDGVnbJP4kwL_iY0RzOqbMM=.c3df8d1a-995f-4c6e-8682-7cb31e07d771@github.com>

On Fri, 6 Jan 2023 07:21:12 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
>> 
>> Fix:
>> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
>> Also updated the screen capture code, made frame undecorated, added some prints for better debugging.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Replaced one robot.waitForIdle with robot.delay(), formatting corrections, taken the insets into account for initial frame position

Accidentally closed the PR, reopening it.

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

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


From mvs at openjdk.org  Mon Jan  9 06:02:00 2023
From: mvs at openjdk.org (Manukumar V S)
Date: Mon, 9 Jan 2023 06:02:00 GMT
Subject: Withdrawn: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
Message-ID: <ooIdriTRt78sMrxBvP8phcVbJyEAdjVsHEe_QlTXk4M=.0988955e-3367-4821-b1d6-10ebb84d2258@github.com>

On Tue, 11 Oct 2022 14:17:42 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
> 
> Fix:
> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
> Also updated the screen capture code, made frame undecorated, added some prints for better debugging.

This pull request has been closed without being integrated.

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

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


From dholmes at openjdk.org  Mon Jan  9 06:39:52 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jan 2023 06:39:52 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
Message-ID: <KlEenZ7O0DBvGKo8LfptAIvOJlwIOuZrv-lvszxXG3E=.f7bcba4e-9f8d-4ec0-953d-c68774c96902@github.com>

On Sat, 7 Jan 2023 21:08:07 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix incorrect @bug numbers in unit tests.

All your new files need a copyright and GPL header.

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

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


From aturbanov at openjdk.org  Mon Jan  9 10:01:55 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 9 Jan 2023 10:01:55 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds [v2]
In-Reply-To: <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
Message-ID: <kvO_2yYNJ0FwwXO3aWqDaqOeYFS6iO_vWTTCu-FH6nk=.21c3ffb8-7781-41ba-a257-101221800bdc@github.com>

On Mon, 5 Dec 2022 22:10:15 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The above test was failing due to incorrect pixel color and wrong window bounds on Mac-ARM, Windows and Linux platforms.
>> 
>> The following changes have been made:
>> - Correct window bounds are obtained using the current ScreenDevice's DefaultConfig bounds (this test checks FullScreen functionality on multiple screen devices).
>> - Color tolerance has been added for color check
>> - Instead of scanning the full screen to check pixel color, vertical and horizontal scans are done at the far right and bottom end to ensure that window is in full screen mode w.r.t to screen device and the window bounds are as expected.
>> 
>> CI testing passes on all platforms (tested 50 times per platform).
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   frame changed back to decorated and exclude on linux

test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 190:

> 188:             try {
> 189:                 robot = new Robot();
> 190:             } catch(AWTException ae) {

Suggestion:

            } catch (AWTException ae) {

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

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


From psadhukhan at openjdk.org  Mon Jan  9 10:16:57 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 9 Jan 2023 10:16:57 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v3]
In-Reply-To: <23xwHp6apwTTidFVoGzCjc-oSkW7v8hOVFZ4D_lP6c0=.eba74ea0-5731-4c4a-a971-95ec36248796@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <23xwHp6apwTTidFVoGzCjc-oSkW7v8hOVFZ4D_lP6c0=.eba74ea0-5731-4c4a-a971-95ec36248796@github.com>
Message-ID: <0fyFbdQmyTEQE3iZ2uQ9ZO3bOnV1AX_XHTYL2fvrctY=.158ae93a-806d-4893-840b-e58b3db777de@github.com>

On Thu, 29 Dec 2022 06:22:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
>> says:
>> "...MetalLookAndFeel registers an entry for each of the classes
>> in the package javax.swing.plaf.metal that are named MetalXXXUI.
>> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
>> that do not have a class in metal, the corresponding class in
>> javax.swing.plaf.basic is used. For example, metal does not
>> have a class named "MetalColorChooserUI", as such,
>> javax.swing.plaf.basic.BasicColorChooserUI is used".
>> 
>> There is class MetalMenuBarUI, but the method populates given defaults table with the value
>> "javax.swing.plaf.basic.BasicMenuBarUI".
>> 
>> Added entry for MetalMenuBarUI..
>> CI tests including JCK tests are ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spec update

> We need to clarify here what we want before the CSR can be completed. One comment in the draft CSR got my attention -
> 
> "MetalMenuBarUI entry is not registered in this method although is is part of javax.swing.plaf.metal since it is registered in OceanTheme class, which is used by MetalLookAndFeel by default."
> 
> Hmm .. so now I'm wondering if we are phrasing things correctly. If themes register the UIs they use why does this method do _anything_ ? Or is there some _assumption_ that all themes use MOST of them and so they are always registerr but some UIs are registered only by themes that use them ? You tell me what actually happens and I can help you word it.

The UIs are registered per L&F (and populated in `UIDefaults table` when user calls `UIManager.setLookAndFeel`) so we have `"ButtonUI", javax.swing.plaf.*** + uiClassID"` to find out the exact uiClassID, which implements that particular widget for that particular L&F, which in this case is `javax.swing.plaf.basic.BasicButtonUI`/`javax.swing.plaf.metal.MetalButtonUI` etc

However, Metal L&F has different themes and some uiClass are specific to particular themes so it seems they are further segregated and registered in specific theme's UIDefaults table (via `currentTheme.addCustomEntriesToTable(table)` in MetalLookAndFeel class) for ex, MetalMenuBarUI only for OceanTheme (and therefore are not registered upfront in L&F class)
which we are trying to establish here...

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

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


From psadhukhan at openjdk.org  Mon Jan  9 10:19:51 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 9 Jan 2023 10:19:51 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
Message-ID: <UkTmmsjU6an23Wvu-4SQr9Dhit0Y7P168edjmIYODXs=.07ae6e07-0ed8-4daa-9588-2a0db2989528@github.com>

On Fri, 6 Jan 2023 04:42:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems Synth has two cases of updateStyle() where its argument is not passed to the getContext() call. It seems to be an oversight as in other Synth classes, the component argument passed to updateStyle is being passed to getContext().
> 
> CI tests are ok with this change and there is no new regeression with CI tests run in NimbusL&F by default..

I dont think there is any difference between passing method argument vis-a-vis this as I think both point to same object..
As I told, I dont see any difference in rendering with and without this change...
It is just to maintain consistency which is being done here or we could just close as "Wont fix"...but I think we should just give it a chance to have all the classes maintain the same construct...

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

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


From psadhukhan at openjdk.org  Mon Jan  9 10:19:57 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 9 Jan 2023 10:19:57 GMT
Subject: Integrated: 8298876: Swing applications do not get repainted coming
 out of sleep on Windows 10
In-Reply-To: <4Rwd2whqzEDkIp18wA5Gug64zbPWMzrRUNLyJ4GVJE8=.81f3f83c-df7d-40cf-9e22-25e5035435ad@github.com>
References: <4Rwd2whqzEDkIp18wA5Gug64zbPWMzrRUNLyJ4GVJE8=.81f3f83c-df7d-40cf-9e22-25e5035435ad@github.com>
Message-ID: <4dHRq2BVUA2YyuOh9GP5U9_rgd1H0i3e5E2yKGuaGfI=.31979736-3df3-44f7-8b89-f0788786150e@github.com>

On Mon, 2 Jan 2023 08:24:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This is a revert of commit https://github.com/openjdk/jdk/commit/415bf44191632cd8dbcc158c0ff0992c0b61c3ba
> which was a fix for 8275715: D3D pipeline processes multiple PaintEvent at initial drawing 
> as it is causing some repaint issue and also since the regression test is known to fail in some systems and is currently problemlisted which suggests the fix was half-baked.
> 
> Raised a new issue for the same https://bugs.openjdk.org/browse/JDK-8299436

This pull request has now been integrated.

Changeset: 4072412c
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4072412c1fd1e28febff71c6b37a9813f22bdc4b
Stats:     92 lines in 2 files changed: 0 ins; 88 del; 4 mod

8298876: Swing applications do not get repainted coming out of sleep on Windows 10

Reviewed-by: angorya, prr

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

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


From duke at openjdk.org  Mon Jan  9 14:03:54 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 9 Jan 2023 14:03:54 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <KlEenZ7O0DBvGKo8LfptAIvOJlwIOuZrv-lvszxXG3E=.f7bcba4e-9f8d-4ec0-953d-c68774c96902@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <KlEenZ7O0DBvGKo8LfptAIvOJlwIOuZrv-lvszxXG3E=.f7bcba4e-9f8d-4ec0-953d-c68774c96902@github.com>
Message-ID: <efiqSfOiXFcY_J9cTnqaD-MXaNKg7b5-LsATAeEe9Xc=.a1265538-2624-4f3c-995e-6b1ecdf227b7@github.com>

On Mon, 9 Jan 2023 06:37:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> All your new files need a copyright and GPL header.

Sorry if I'm being blind but I'm not seeing it. Which file(s) are you referring to?

The `@test /nodynamiccopyright/` files don't get one per [this](https://openjdk.org/groups/compiler/tests.html#gold).

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

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


From tr at openjdk.org  Mon Jan  9 14:46:53 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 9 Jan 2023 14:46:53 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
Message-ID: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>

FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
Automated test is attached which has been tested with multiple test runs.

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

Commit messages:
 - fix + Automated Test

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

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


From serb at openjdk.org  Mon Jan  9 14:47:08 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 9 Jan 2023 14:47:08 GMT
Subject: RFR: 8299772: The ColorModel.getRGBdefault() method is not thread-safe
Message-ID: <Ov06tqQrCHkABN9x6zIYIdMjqK0qMEEqlboiSTIdHgw=.729da5c8-e6d5-428a-86af-08e41e84a2c0@github.com>

The getRGBdefault() was made thread safe via holder implemented as a local interface.

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

Commit messages:
 - Update RGBdefaultSingleton.java
 - the test
 - 8299772: The ColorModel.getRGBdefault() method is not thread-safe

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

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


From duke at openjdk.org  Mon Jan  9 15:31:51 2023
From: duke at openjdk.org (SWinxy)
Date: Mon, 9 Jan 2023 15:31:51 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
Message-ID: <cuhf5xorPR929Vr2zh_sALeSsozVkzdvyrYfU_tyfs4=.b0d786e7-bfc2-4c34-b4fd-d2dd20ea3f88@github.com>

On Fri, 6 Jan 2023 04:42:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems Synth has two cases of updateStyle() where its argument is not passed to the getContext() call. It seems to be an oversight as in other Synth classes, the component argument passed to updateStyle is being passed to getContext().
> 
> CI tests are ok with this change and there is no new regeression with CI tests run in NimbusL&F by default..

This patch is fine, and I think it should be done for consistency. It's weird that `SynthInternalFrameTitlePane` passes itself, but that's not itself a problem; merely an unusual quirk.

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

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

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


From philip.race at oracle.com  Mon Jan  9 16:51:02 2023
From: philip.race at oracle.com (Philip Race)
Date: Mon, 9 Jan 2023 08:51:02 -0800
Subject: [PATCH] Paste fails when X clipboard is in a certain state
In-Reply-To: <CAKCn7JEV5ydg_cttOGJ808MUbSAScCGaa1994F9sjYCu5z5DrQ@mail.gmail.com>
References: <CAKCn7JEV5ydg_cttOGJ808MUbSAScCGaa1994F9sjYCu5z5DrQ@mail.gmail.com>
Message-ID: <c7f5aa7a-0c85-4acc-90de-6d3b6da060b6@oracle.com>

Note that fixes aren't accepted as patches.
You need to submit a github PR after signing the OCA and getting it 
recorded.
https://openjdk.org/contribute/

However I've re-opened this bug (I do not understand why it was closed) and
assigned to someone might be able to find time to take care of it.

-phil.

On 10/18/22 9:08 PM, Flaviu Tamas wrote:
> Sometimes, the X clipboard is in some state that causes pastes to fail
> with the following, or similar, stack traces:
>
> java.lang.NullPointerException: Failed to retrieve atom name.
>      at java.desktop/sun.awt.X11.XlibWrapper.XGetAtomName(Native Method)
>      at java.desktop/sun.awt.X11.XAtom.getName(XAtom.java:189)
>      at java.desktop/sun.awt.X11.XDataTransferer.getTargetNameForAtom(XDataTransferer.java:172)
>      at java.desktop/sun.awt.X11.XDataTransferer.getNativeForFormat(XDataTransferer.java:161)
>      at java.desktop/sun.awt.datatransfer.DataTransferer.getFlavorsForFormatsAsSet(DataTransferer.java:487)
>      at java.desktop/sun.awt.datatransfer.SunClipboard.formatArrayAsDataFlavorSet(SunClipboard.java:342)
>      at java.desktop/sun.awt.datatransfer.SunClipboard.isDataFlavorAvailable(SunClipboard.java:185)
>
> This is a widespread issue and very frustrating issue, see:
>
> - https://youtrack.jetbrains.com/issue/JBR-438/Clipboard-operations-arent-working-in-certain-state-of-Xorg-selection-buffers
> - https://www.google.com/search?q="Failed+to+retrieve+atom+name"+"DataTransferer"
>
> Frankly, I don't understand how X works at all, or how this issue
> arises. However, this same workaround was applied to Mozilla in 2010:
> https://hg.mozilla.org/releases/mozilla-1.9.1/rev/62f3d28797e2, and I
> don't see any reasonable behavior that having this workaround in place
> would break. The workaround works by simply skipping native formats
> that don't have a name.
>
> Verified to work by running IntelliJ Clion under the modified VM and
> verifying that paste from my terminal, which previously did not work,
> now works. I'm not familiar with OpenJDK unit testing conventions, but
> I believe this change falls under the "highly platform-dependent"
> exception.



From aivanov at openjdk.org  Mon Jan  9 16:46:54 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 9 Jan 2023 16:46:54 GMT
Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java
 fails with AssertionError [v2]
In-Reply-To: <S_M1SbhJdSLe3AnmmmoY3KtQ28K6zKI5yBs_r8TpYIs=.35f706d3-2120-4043-9d89-ee78ebda4b3f@github.com>
References: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
 <S_M1SbhJdSLe3AnmmmoY3KtQ28K6zKI5yBs_r8TpYIs=.35f706d3-2120-4043-9d89-ee78ebda4b3f@github.com>
Message-ID: <2Fk66CGQnFSHw8YpJ6-6xgJvX89hoVeNNthmx7xk70c=.5de193ca-c9fe-462c-b11b-d9da17b5d7bb@github.com>

On Fri, 6 Jan 2023 22:02:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This assertion happens when we try to build the path linked by the shortcut file when part of that path is not accessible. For example, if the ".lnk" file is pointed to the "windows-update. settings" inside the "Internet.settings". 
>> 
>> After the change, we will skip the target of the link if any part of the path to the target is not a folder and is not traversable in JFileChooser.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by aivanov (Reviewer).

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

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


From serb at openjdk.org  Mon Jan  9 16:53:55 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 9 Jan 2023 16:53:55 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <UkTmmsjU6an23Wvu-4SQr9Dhit0Y7P168edjmIYODXs=.07ae6e07-0ed8-4daa-9588-2a0db2989528@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
 <UkTmmsjU6an23Wvu-4SQr9Dhit0Y7P168edjmIYODXs=.07ae6e07-0ed8-4daa-9588-2a0db2989528@github.com>
Message-ID: <QDs0PphbeFMHkJImTzpS_xzfku460k7LO0NuNZmLhL0=.dbd6baa9-81c8-416e-8d92-16473a0b2fca@github.com>

On Mon, 9 Jan 2023 10:17:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I dont think there is any difference between passing method argument vis-a-vis this as I think both point to same object..

Are you sure that it is always the same? Right now we ignore the component passed from the SynthListUI.propertyChange() and use list, after the change we will use the source of the event, I think that could be tested.

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

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


From honkar at openjdk.org  Mon Jan  9 17:21:58 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 9 Jan 2023 17:21:58 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v3]
In-Reply-To: <212vFogi6FjVFiexmbfBPZd-4GywAUKQIMZbr3l3wIs=.e3b7a827-7427-4b46-acad-290d3d4e65c3@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <lYAXVRfHlBD3wxhnlk68b5PyjhL0xwIVs9G0weqJ3Y8=.69e8b1d4-13b3-4ce1-ab23-7cdc4df1c097@github.com>
 <212vFogi6FjVFiexmbfBPZd-4GywAUKQIMZbr3l3wIs=.e3b7a827-7427-4b46-acad-290d3d4e65c3@github.com>
Message-ID: <rFQ3ZV1aFZwX9PJ24oEx31D0J84M6-Yvpcs0V9Tjaik=.88b8df62-9182-46c1-af2f-d9e2055ebb7d@github.com>

On Wed, 4 Jan 2023 19:33:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - minor changes
>>  - Merge branch 'master' into RefactorBorder_8294484
>>  - Merge branch 'master' into RefactorBorder_8294484
>>  - review changes
>>  - Refactoring changes
>>  - Merge branch 'master' into RefactorBorder_8294484
>>  - revert MetalBorder changes
>>  - merge master
>>  - refactoring changes - initial commit
>
> Changes requested by aivanov (Reviewer).

@aivanov-jdk Please review the updated changes.

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

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


From aivanov at openjdk.org  Mon Jan  9 17:30:53 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 9 Jan 2023 17:30:53 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds [v2]
In-Reply-To: <tQFUlui7EfK7f-ZPmAaI51aw0hyWzyTxXJSzB7Wcosg=.70abc002-2e50-4d3f-9ffe-11b0421b4295@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
 <aSifVJRa62shis8D30fdNdwxcUAzCybqmo6ZtiP7uBY=.4ffd8c68-3ebe-436e-b3a7-a1a23b8d0c03@github.com>
 <tQFUlui7EfK7f-ZPmAaI51aw0hyWzyTxXJSzB7Wcosg=.70abc002-2e50-4d3f-9ffe-11b0421b4295@github.com>
Message-ID: <vcU1BpbZs5wKxrIelX5t0edi6ELgfajBnURgryyBXdE=.36247d6e-4537-45de-a2a9-3fa471739543@github.com>

On Thu, 22 Dec 2022 22:02:39 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> > Why can't we scan all the pixels? It was the purpose of the test to ensure each window has the exact color. Does it take very long time?
> 
> There isn't a significant time difference but I think it might be a better and efficient way. Since the right and bottom scans span across the entire height and width of full screen window, it can test the extent of full screen window effectively.

I agree that scanning one horizontal and one vertical line is much faster than scanning the entire rectangle. Yet scanning the entire rectangle guarantees there are no other colors in the entire capture of the image. The other approach, although faster, may not detect an occurrence of another color.

Using [`Stream.parallel`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/stream/BaseStream.html#parallel()) may improve the speed of processing the entire rectangular image, for example by paralleling scanning the horizontal lines of the image.

Since it's not the reason for the test failure, I'd rather leave scanning the entire image.

> > Why is color tolerance needed? Is it to account for High DPI display? Can we use [`Robot.createMultiResolutionScreenCapture`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Robot.html#createMultiResolutionScreenCapture(java.awt.Rectangle)) to ensure the `BufferedImage` contains the actual pixels rather a scaled down version?
> 
> There seems to be color issues at certain locations the color is not exactly red or green hence the testColor check fails on some platforms. I'll have to recheck and test the artifacts like Sergey mentioned it earlier.

If using `createMultiResolutionScreenCapture` resolves the problem, we should use it, High DPI displays are more common now and down-sampling the captured image could introduce artficats, even though it shouldn't because all the pixels are to be of the same color.

Did the entire window image have different colors or only the right-most and bottom-most lines?

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

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


From aivanov at openjdk.org  Mon Jan  9 17:42:57 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 9 Jan 2023 17:42:57 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds [v2]
In-Reply-To: <o2BJuYzPUEwRvdID4INEHQQhXl2jhvKyHUtZgIZYNDE=.c5971482-50fc-455c-8464-e2e70bc92b44@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
 <CUGEHLhq9stsvqPxzj58o9ngHDcGQBlOiHMyNqKfh48=.28a35c51-72ac-463c-8392-2037ea9c02db@github.com>
 <M0xzCzMOfO1Uk1FGaaF5v65YOx1HR5YIGmrsM5IE67A=.a8c89539-991b-4910-b5bb-1f427fa75099@github.com>
 <B1NZU42rDKaZPwvOEcv_mjwxPsXKOoKKZA4JlsBc3Ck=.75ce53cf-ac17-4eb5-b65d-4a7b62f6f485@github.com>
 <o2BJuYzPUEwRvdID4INEHQQhXl2jhvKyHUtZgIZYNDE=.c5971482-50fc-455c-8464-e2e70bc92b44@github.com>
Message-ID: <QavMloigUKV-0paQFXV3B9oZSqf-n8kM8lFGJ03UMik=.d79728e0-58ef-49b4-a1b7-727fe8f0b74b@github.com>

On Wed, 7 Dec 2022 09:20:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> On Windows, it does not work as well if a non-accelerated java2d pipeline is selected. You can test that by using this option: `-Dsun.java2d.d3d=false`

Or rather try with `-Dsun.java2d.d3d=True` and check if Direct3D is enabled. If it isn't, you won't see the difference.

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

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


From aivanov at openjdk.org  Mon Jan  9 17:42:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 9 Jan 2023 17:42:59 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds [v2]
In-Reply-To: <kvO_2yYNJ0FwwXO3aWqDaqOeYFS6iO_vWTTCu-FH6nk=.21c3ffb8-7781-41ba-a257-101221800bdc@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
 <kvO_2yYNJ0FwwXO3aWqDaqOeYFS6iO_vWTTCu-FH6nk=.21c3ffb8-7781-41ba-a257-101221800bdc@github.com>
Message-ID: <p9FZ3yjK6-WW4pupzm-fNfF-Ek4CnHVTUKSYAWMUo4c=.243ad9f8-f3de-45d7-b789-4aa005b8f522@github.com>

On Mon, 9 Jan 2023 09:59:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   frame changed back to decorated and exclude on linux
>
> test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 190:
> 
>> 188:             try {
>> 189:                 robot = new Robot();
>> 190:             } catch(AWTException ae) {
> 
> Suggestion:
> 
>             } catch (AWTException ae) {

There are a couple more lines where a space is missing on the left of a binary operator.

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

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


From dnguyen at openjdk.org  Mon Jan  9 18:00:04 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 9 Jan 2023 18:00:04 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <I6npa8dAup5iQ19djUr8wRiq7TVcbCkuNCfOQda7cjM=.41f88fba-7dc8-4942-bdd4-c417be8d6425@github.com>

On Mon, 9 Jan 2023 10:24:49 GMT, Tejesh R <tr at openjdk.org> wrote:

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 413:

> 411:         helpButtonText   = UIManager.getString("FileChooser.helpButtonText",l);
> 412:         directoryOpenButtonText = UIManager.getString("FileChooser.directoryOpenButtonText",l);
> 413:         customApproveButtonText = UIManager.getString("FileChooser.customApproveButtonText", l);

Not sure if it needs to be addressed throughout the file, but for the "L" var at the end of each getString(), sometimes there's a space after the comma and sometimes there's none. Maybe it's better to follow the same convention throughout the file. Maybe it's better to just copy the lines above the one's you added to match the code block only.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 601:

> 599:         } else if(fc.getDialogType() == JFileChooser.SAVE_DIALOG) {
> 600:             return saveButtonToolTipText;
> 601:         } else if (fc.getDialogType() == JFileChooser.CUSTOM_DIALOG) {

Same spacing concern here.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 928:

> 926:         } else if (fc.getDialogType() == JFileChooser.SAVE_DIALOG) {
> 927:             return saveButtonMnemonic;
> 928:         } else if(fc.getDialogType() == JFileChooser.CUSTOM_DIALOG) {

Spacing here too

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 52:

> 50:                 UIManager.LookAndFeelInfo[] lookAndFeel = UIManager.getInstalledLookAndFeels();
> 51:                 for (UIManager.LookAndFeelInfo look : lookAndFeel) {
> 52:                     if(look.getClassName().equals(aquaLAF)) {

Would it be cleaner to remove the aquaLAF string and replace the getClassName() in the "if" condition at line 52 for look.getName().equals("Aqua")? This condenses the block by one line and keeps clarity.

Also there should be a space after the if.

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 63:

> 61: 
> 62:     private CustomApproveButtonTest(String lookAndFeel) {
> 63:         System.out.println("Testing Look & Feel : "+lookAndFeel);

Spacing

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 93:

> 91:         }
> 92: 
> 93:         if(frame != null) {

Spacing

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 115:

> 113:                 if (result == null) {
> 114:                     result = button;
> 115:                 }

What's the `result == null` for? 

Is it meant to not recursively call findCustomApproveButton() if a JButton result is found? Because then the break at line 107 resolves that I think.

If it's to only have a result for the first instance of a non-null result, then wouldn't adding a similar break after `result = button` be better so we don't have to recursively call findCustomApproveButton() if a result is already found?

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 122:

> 120: 
> 121:     private void fail(String s) {
> 122:         if(frame != null) {

Spacing after if

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

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


From aivanov at openjdk.org  Mon Jan  9 18:46:54 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 9 Jan 2023 18:46:54 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <jH6H-chU7-m3gPJRb1v2StPHplL06eKXHvUIrxV-FYE=.f6f34982-26c3-43b9-9ac0-ddb1a4fd1c9a@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
 <DD5uVC90-DPgmwfJXNEgnLj_wxHGTD7_uKMZBwNLHa8=.6a564a17-23d4-4da8-8381-c882b852aaaa@github.com>
 <c4Qx6gF9iiaJdMaOybsl_4cNgqu8KPNOQQH2zBDAOzU=.a72f2f21-5212-4337-b3f3-ccff0a39c728@github.com>
 <jH6H-chU7-m3gPJRb1v2StPHplL06eKXHvUIrxV-FYE=.f6f34982-26c3-43b9-9ac0-ddb1a4fd1c9a@github.com>
Message-ID: <agLFny5ZGnTJU6-pb6kyZY9HLgxYdLIaI0MTefcVHNQ=.25dbb227-1369-4f7c-836f-9153ee9d35dc@github.com>

On Sun, 8 Jan 2023 09:09:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Did we check how the native code works w/o using JFileChooser, buy FileSystemView, or by the native example? Is it possible that it is intermittent because of timing related to "com" thread?
>> 
>> 
>> 
>>> 
>> 
>> I have tested in headful system multiple time, never reproduced this issue...... Can timing affect in headless and not in headful......?
>
>> I have tested in headful system multiple time, never reproduced this issue...... Can timing affect in headless and not in headful......?
> 
> It should not. Does it actually have any dependency on "headful" envirement? The native code we used does not create any UI element or something like that. It is better to debug it on the same/similar config/system where the bug is reproduced, since as far as I understand it is not a rare case.

@mrserb, @TejeshR13, There could be a dependency on the host being headful even if we don't create UI. You may remember there were a couple of test failures where colours in `VolatileImage` were different from the colours in `BufferedImage` because `VolatileImage` used `IndexedColorModel` rather than the expected 32-bit colour.

Recently I saw another problem where a seemingly headless test didn't work as expected on the headless system. Windows L&F wasn't set correctly and `JTextField` didn't have the expected border.

Windows Server systems may not have full-featured desktop environment, in this case we may see problems with *headless* tests which in fact need *headful (full-featured)* desktop environment even though such tests don't show the UI.

I agree it is worth exploring further why fetching the icon of the _Downloads_ folder returns `null`. Could either of you submit a bug, please?

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

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


From aivanov at openjdk.org  Mon Jan  9 19:03:51 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 9 Jan 2023 19:03:51 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <R5KpqeBP6UC7LgpvlCqEEFa7Imuu-rOluzwQqVrN5Pw=.e1226970-93fc-40f9-8a2e-42301b45be80@github.com>

On Mon, 9 Jan 2023 10:24:49 GMT, Tejesh R <tr at openjdk.org> wrote:

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

If the programmer uses, `CUSTOM_DIALOG`, they are responsible for setting the text and, if required, tooltip for the approve button, which is implied by the required `approveButtonText` parameter to [JFileChooser.html.showDialog](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JFileChooser.html#showDialog(java.awt.Component,java.lang.String)).

As such, I don't think that adding a new entry to `UIManager` is the correct way to fix the bug.

If `JFileChooser` is added into a frame or another container without using its `show*` methods, you have to explicitly set the text for approve button using [`setApproveButtonText`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JFileChooser.html#setApproveButtonText(java.lang.String)).

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

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


From aivanov at openjdk.org  Mon Jan  9 19:03:53 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 9 Jan 2023 19:03:53 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
In-Reply-To: <I6npa8dAup5iQ19djUr8wRiq7TVcbCkuNCfOQda7cjM=.41f88fba-7dc8-4942-bdd4-c417be8d6425@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <I6npa8dAup5iQ19djUr8wRiq7TVcbCkuNCfOQda7cjM=.41f88fba-7dc8-4942-bdd4-c417be8d6425@github.com>
Message-ID: <WvqdcUPMQstDQ8DkrXZH8NL3Efn_smdhsCnIA0lZRig=.dd36a822-a893-4ab3-a838-1b2a607f9466@github.com>

On Mon, 9 Jan 2023 17:28:36 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 413:
> 
>> 411:         helpButtonText   = UIManager.getString("FileChooser.helpButtonText",l);
>> 412:         directoryOpenButtonText = UIManager.getString("FileChooser.directoryOpenButtonText",l);
>> 413:         customApproveButtonText = UIManager.getString("FileChooser.customApproveButtonText", l);
> 
> Not sure if it needs to be addressed throughout the file, but for the "L" var at the end of each getString(), sometimes there's a space after the comma and sometimes there's none. Maybe it's better to follow the same convention throughout the file. Maybe it's better to just copy the lines above the one's you added to match the code block only.

Follow the style in the surrounding code so that newly added lines aren't out of place.

For new isolated code, follow the common Java code style where spaces are added.

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

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


From aivanov at openjdk.org  Mon Jan  9 19:56:55 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 9 Jan 2023 19:56:55 GMT
Subject: RFR: 8299261: Clean up AWT D3D exports
In-Reply-To: <dAxIVJYLOXHv0t-y1d21lQyPx8v2SM7WTRn5Hf0Q96Q=.a0c5f8ac-3c7d-4984-bf08-065a8e06364b@github.com>
References: <dAxIVJYLOXHv0t-y1d21lQyPx8v2SM7WTRn5Hf0Q96Q=.a0c5f8ac-3c7d-4984-bf08-065a8e06364b@github.com>
Message-ID: <w7rbvqpBVtjoehTlwVHz7C-Tv9ZWLuZoW2bMLRnzLFc=.969e1502-c19b-47e2-8184-b46c9a081d8c@github.com>

On Thu, 22 Dec 2022 10:01:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes unnecessary exports from awt.dll.
> 
> The exports were introduced in e4c9db984fe1a3a9d06fb60e333e92df3b165454, and as far as I could tell, they were never used; the exported functions are only used inside awt.dll.
> 
> Verified that:
> - debug and release builds finish successfully
> - mach5 client libs tests pass

Marked as reviewed by aivanov (Reviewer).

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

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


From serb at openjdk.org  Mon Jan  9 20:09:54 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 9 Jan 2023 20:09:54 GMT
Subject: RFR: 8280359: Try to remove duplicate code for coordinate
 calculation
In-Reply-To: <UwqaayGxh98sMkmmpxlYvwatXRmkqZ07HTsdL1P2GHg=.1dcd808f-7c2f-4a58-9290-dc1ff40f02ad@github.com>
References: <UwqaayGxh98sMkmmpxlYvwatXRmkqZ07HTsdL1P2GHg=.1dcd808f-7c2f-4a58-9290-dc1ff40f02ad@github.com>
Message-ID: <xxlDZOCt5v6lTqn1H4rhGCRgEpaItlUnw8iS89uLli8=.b313c122-f313-478f-a563-85537460905f@github.com>

On Mon, 12 Dec 2022 01:49:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The code from `AccessibilityGraphicsEnvironment` is moved/merged back to the `SunGraphicsEnvironment` from where it was initially [copied](https://github.com/openjdk/jdk18/pull/72#issuecomment-1001050200). The required API is exported from the `sun.java2d` to the `jdk.accessibility`(on WIndows only).

@bridgekeeper not now

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

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


From tr at openjdk.org  Tue Jan 10 04:52:50 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 10 Jan 2023 04:52:50 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
In-Reply-To: <R5KpqeBP6UC7LgpvlCqEEFa7Imuu-rOluzwQqVrN5Pw=.e1226970-93fc-40f9-8a2e-42301b45be80@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <R5KpqeBP6UC7LgpvlCqEEFa7Imuu-rOluzwQqVrN5Pw=.e1226970-93fc-40f9-8a2e-42301b45be80@github.com>
Message-ID: <FJCr1YjS0OvOwRrDhrlveOjWSbrjxhWQD02P8-sfubI=.d6f4b0ee-3a35-4bcc-871c-1e29f32ab788@github.com>

On Mon, 9 Jan 2023 18:59:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> 



> If the programmer uses `CUSTOM_DIALOG`, they are responsible for setting the text and, if required, tooltip for the approve button, which is implied by the required `approveButtonText` parameter to [JFileChooser.showDialog](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JFileChooser.html#showDialog(java.awt.Component,java.lang.String)).
> 
> As such, I don't think that adding a new entry to `UIManager` is the correct way to fix the bug.
> 
> If `JFileChooser` is added into a frame or another container without using its `show*` methods, you have to explicitly set the text for approve button using [`setApproveButtonText`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JFileChooser.html#setApproveButtonText(java.lang.String)).
> 
> Taking the above into account, [JDK-8299522](https://bugs.openjdk.org/browse/JDK-8299522) is **Not an Issue**.

@aivanov-jdk Agree to your point. But I added the default text and tooltip as a fallback text which is already in aqua L&F. It's always safe to add a default text when user doesn't add explicitly, since it affects the button size in some L&F (like Metal) and empty text button in some other L&F (like windows).

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

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


From tr at openjdk.org  Tue Jan 10 05:18:52 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 10 Jan 2023 05:18:52 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
 [v2]
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <H9y1l565M9k3wyJN7qoNpNAUIJwPSDy5QvmySeKE_LE=.8755e787-a1d5-41ea-ad5b-24ec48545981@github.com>

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

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/11901/files
  - new: https://git.openjdk.org/jdk/pull/11901/files/6b374fcc..a95f0ff3

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

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

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


From tr at openjdk.org  Tue Jan 10 05:18:53 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 10 Jan 2023 05:18:53 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <HkVfnwvvjslBv2qyODOIVXHfX3Pngd0w3XbVgGCryvU=.f2bc0aa7-d502-4716-85b5-5d47d15c05dd@github.com>

On Mon, 9 Jan 2023 10:24:49 GMT, Tejesh R <tr at openjdk.org> wrote:

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

@DamonGuy I have handled all your review comments.

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

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


From tr at openjdk.org  Tue Jan 10 05:18:55 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 10 Jan 2023 05:18:55 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
 [v2]
In-Reply-To: <WvqdcUPMQstDQ8DkrXZH8NL3Efn_smdhsCnIA0lZRig=.dd36a822-a893-4ab3-a838-1b2a607f9466@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <I6npa8dAup5iQ19djUr8wRiq7TVcbCkuNCfOQda7cjM=.41f88fba-7dc8-4942-bdd4-c417be8d6425@github.com>
 <WvqdcUPMQstDQ8DkrXZH8NL3Efn_smdhsCnIA0lZRig=.dd36a822-a893-4ab3-a838-1b2a607f9466@github.com>
Message-ID: <jDBcxko0MskA_iQ1HGEP6twoaovSB0ChSlggE3ysLBo=.506a0b32-f815-477b-8e7d-00415e112580@github.com>

On Mon, 9 Jan 2023 18:49:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 413:
>> 
>>> 411:         helpButtonText   = UIManager.getString("FileChooser.helpButtonText",l);
>>> 412:         directoryOpenButtonText = UIManager.getString("FileChooser.directoryOpenButtonText",l);
>>> 413:         customApproveButtonText = UIManager.getString("FileChooser.customApproveButtonText", l);
>> 
>> Not sure if it needs to be addressed throughout the file, but for the "L" var at the end of each getString(), sometimes there's a space after the comma and sometimes there's none. Maybe it's better to follow the same convention throughout the file. Maybe it's better to just copy the lines above the one's you added to match the code block only.
>
> Follow the style in the surrounding code so that newly added lines aren't out of place.
> 
> For new isolated code, follow the common Java code style where spaces are added.

Yeah, updated.

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

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


From tr at openjdk.org  Tue Jan 10 05:18:57 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 10 Jan 2023 05:18:57 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
 [v2]
In-Reply-To: <I6npa8dAup5iQ19djUr8wRiq7TVcbCkuNCfOQda7cjM=.41f88fba-7dc8-4942-bdd4-c417be8d6425@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <I6npa8dAup5iQ19djUr8wRiq7TVcbCkuNCfOQda7cjM=.41f88fba-7dc8-4942-bdd4-c417be8d6425@github.com>
Message-ID: <V9L0ZUJhdEuvN0VLX2b68fht3qFTBf-a3AgMfduh0ho=.a15b7eaa-8799-43d7-961b-35ab91be3cfc@github.com>

On Mon, 9 Jan 2023 17:47:41 GMT, Damon Nguyen <dnguyen 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/javax/swing/JFileChooser/CustomApproveButtonTest.java line 93:
> 
>> 91:         }
>> 92: 
>> 93:         if(frame != null) {
> 
> Spacing

Updated.

> test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 115:
> 
>> 113:                 if (result == null) {
>> 114:                     result = button;
>> 115:                 }
> 
> What's the `result == null` for? 
> 
> Is it meant to not recursively call findCustomApproveButton() if a JButton result is found? Because then the break at line 107 resolves that I think.
> 
> If it's to only have a result for the first instance of a non-null result, then wouldn't adding a similar break after `result = button` be better so we don't have to recursively call findCustomApproveButton() if a result is already found?

Updated.

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

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


From tr at openjdk.org  Tue Jan 10 05:22:57 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 10 Jan 2023 05:22:57 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <jH6H-chU7-m3gPJRb1v2StPHplL06eKXHvUIrxV-FYE=.f6f34982-26c3-43b9-9ac0-ddb1a4fd1c9a@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
 <DD5uVC90-DPgmwfJXNEgnLj_wxHGTD7_uKMZBwNLHa8=.6a564a17-23d4-4da8-8381-c882b852aaaa@github.com>
 <c4Qx6gF9iiaJdMaOybsl_4cNgqu8KPNOQQH2zBDAOzU=.a72f2f21-5212-4337-b3f3-ccff0a39c728@github.com>
 <jH6H-chU7-m3gPJRb1v2StPHplL06eKXHvUIrxV-FYE=.f6f34982-26c3-43b9-9ac0-ddb1a4fd1c9a@github.com>
Message-ID: <PumLFS7NJwkLt_U6b3CCraoRha0lG6oy_K8v-uFTtV4=.5467e88c-f34b-449c-a71b-eefbe72999ba@github.com>

On Sun, 8 Jan 2023 09:09:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Did we check how the native code works w/o using JFileChooser, buy FileSystemView, or by the native example? Is it possible that it is intermittent because of timing related to "com" thread?
>> 
>> 
>> 
>>> 
>> 
>> I have tested in headful system multiple time, never reproduced this issue...... Can timing affect in headless and not in headful......?
>
>> I have tested in headful system multiple time, never reproduced this issue...... Can timing affect in headless and not in headful......?
> 
> It should not. Does it actually have any dependency on "headful" envirement? The native code we used does not create any UI element or something like that. It is better to debug it on the same/similar config/system where the bug is reproduced, since as far as I understand it is not a rare case.

> @mrserb, @TejeshR13, There could be a dependency on the host being headful even if we don't create UI. You may remember there were a couple of test failures where colours in `VolatileImage` were different from the colours in `BufferedImage` because `VolatileImage` used `IndexedColorModel` rather than the expected 32-bit colour.
> 
> Recently I saw another problem where a seemingly headless test didn't work as expected on the headless system. Windows L&F wasn't set correctly and `JTextField` didn't have the expected border.
> 
> Windows Server systems may not have full-featured desktop environment, in this case we may see problems with _headless_ tests which in fact need _headful (full-featured)_ desktop environment even though such tests don't show the UI.
> 
> I agree it is worth exploring further why fetching the icon of the _Downloads_ folder returns `null`. Could either of you submit a bug, please?

Not only _Downloads_ folder returns null, as I was mentioning it was varying for multiple test runs. Then submitting a new bug for ImageIcon failing to load Image in headless systems right?

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

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


From djelinski at openjdk.org  Tue Jan 10 07:16:56 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 10 Jan 2023 07:16:56 GMT
Subject: RFR: 8299261: Clean up AWT D3D exports
In-Reply-To: <dAxIVJYLOXHv0t-y1d21lQyPx8v2SM7WTRn5Hf0Q96Q=.a0c5f8ac-3c7d-4984-bf08-065a8e06364b@github.com>
References: <dAxIVJYLOXHv0t-y1d21lQyPx8v2SM7WTRn5Hf0Q96Q=.a0c5f8ac-3c7d-4984-bf08-065a8e06364b@github.com>
Message-ID: <CL7VCCqbwOemKmFge2uKlZE1YiJE9nAWdUcUd28qPKQ=.20adf886-92c7-43b9-9e4a-95615fe4e9ae@github.com>

On Thu, 22 Dec 2022 10:01:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes unnecessary exports from awt.dll.
> 
> The exports were introduced in e4c9db984fe1a3a9d06fb60e333e92df3b165454, and as far as I could tell, they were never used; the exported functions are only used inside awt.dll.
> 
> Verified that:
> - debug and release builds finish successfully
> - mach5 client libs tests pass

Thanks for the reviews!

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

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


From djelinski at openjdk.org  Tue Jan 10 07:16:56 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 10 Jan 2023 07:16:56 GMT
Subject: Integrated: 8299261: Clean up AWT D3D exports
In-Reply-To: <dAxIVJYLOXHv0t-y1d21lQyPx8v2SM7WTRn5Hf0Q96Q=.a0c5f8ac-3c7d-4984-bf08-065a8e06364b@github.com>
References: <dAxIVJYLOXHv0t-y1d21lQyPx8v2SM7WTRn5Hf0Q96Q=.a0c5f8ac-3c7d-4984-bf08-065a8e06364b@github.com>
Message-ID: <bsExB7vkHawSL9LbL4oAz4i89wPO44cA9uWFOjXnUM4=.f7507b1c-9b0e-421e-8881-df4c2a4f7848@github.com>

On Thu, 22 Dec 2022 10:01:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes unnecessary exports from awt.dll.
> 
> The exports were introduced in e4c9db984fe1a3a9d06fb60e333e92df3b165454, and as far as I could tell, they were never used; the exported functions are only used inside awt.dll.
> 
> Verified that:
> - debug and release builds finish successfully
> - mach5 client libs tests pass

This pull request has now been integrated.

Changeset: f95346e8
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f95346e870d314fdc224aed4e8b9c22159bd89d3
Stats:     144 lines in 8 files changed: 5 ins; 106 del; 33 mod

8299261: Clean up AWT D3D exports

Reviewed-by: serb, aivanov

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

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


From serb at openjdk.org  Tue Jan 10 07:29:51 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 10 Jan 2023 07:29:51 GMT
Subject: RFR: 4934362: see also refers to self [v4]
In-Reply-To: <YYfN2px7U82QiuHv4HHIe-5PGuaPfpx6D2lgL1np1BI=.263bd130-df76-44c3-b2a2-70f4e6d3e9d6@github.com>
References: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
 <YYfN2px7U82QiuHv4HHIe-5PGuaPfpx6D2lgL1np1BI=.263bd130-df76-44c3-b2a2-70f4e6d3e9d6@github.com>
Message-ID: <wzgbNbayIWWZsFIHIHtK1vp3MFW9XFNNVcjex13SuH0=.4e58a8e5-6ee1-4722-903c-ed2412cc7757@github.com>

On Mon, 9 Jan 2023 03:57:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Some methods and constants has a hyperreference to self in javadoc which is rectified to reference proper methods
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Point to isEditable method

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.org  Tue Jan 10 07:43:01 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 10 Jan 2023 07:43:01 GMT
Subject: [jdk20] RFR: 8299227: host `exif.org` not found in link in doc
 comment [v3]
In-Reply-To: <CSY2Hm3PVq5HPG8BrA2Hsr3YHG0jnfbycbp4mSdbr7A=.5f944f1b-dc09-43c5-9220-9e5e33a3534d@github.com>
References: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
 <CSY2Hm3PVq5HPG8BrA2Hsr3YHG0jnfbycbp4mSdbr7A=.5f944f1b-dc09-43c5-9220-9e5e33a3534d@github.com>
Message-ID: <BVUeHlxX6xmEoBBS30naKwjT2dU5nSBxfv9Egjxdt3w=.e76b8c53-4aea-4a6e-833f-3e83e1e83e6a@github.com>

On Fri, 23 Dec 2022 19:48:02 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Reported broken links are updated accordingly.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Links and spec version update

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/74


From asemenov at openjdk.org  Tue Jan 10 08:15:22 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 10 Jan 2023 08:15:22 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v5]
In-Reply-To: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
Message-ID: <0TMLcijDmL6RQ5mOgnp_xR_KV1a3UKWNU78YAlTwNpA=.d29771e5-20a4-417b-8471-f16900451ea9@github.com>

> [OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:

 - It is better to force the "ensureClassInitialized" as any other getters in this class. To make sure the field is up-to-date even if it was initialized on another thread.
 - Note that this class declares interfaces at the top, and then field/get/set at the bottom of the file.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11670/files
  - new: https://git.openjdk.org/jdk/pull/11670/files/bddabea5..6efb419e

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

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

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


From asemenov at openjdk.org  Tue Jan 10 08:15:24 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 10 Jan 2023 08:15:24 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v4]
In-Reply-To: <XoDoq-4eSMowk20xUz1W8tUDmEwi1oV02WbS_WKROAo=.449ad8d9-b852-49f7-a9a8-a4236e5d1210@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
 <s4E0bCDZWMPHuScZXBcfc5FuApSr15CuahnNuxmCadk=.e76d700e-37a7-435f-b653-e3ad33605c9e@github.com>
 <XoDoq-4eSMowk20xUz1W8tUDmEwi1oV02WbS_WKROAo=.449ad8d9-b852-49f7-a9a8-a4236e5d1210@github.com>
Message-ID: <I7CAkj7xEEqpRfaiy_6M9Mwlxgf4Iv3T_DyEAdrpFn4=.54009b54-bf9c-4108-8fd1-f366be58447e@github.com>

On Thu, 29 Dec 2022 20:52:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Artem Semenov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge master
>>  - update accessor
>>  - Please split the long lines to have 80 chars per line.
>>  - 8298644 JNI call of getCurrentComponent on a wrong thread
>
> src/java.desktop/share/classes/sun/swing/SwingAccessor.java line 60:
> 
>> 58: 
>> 59:     public static AccessibleComponentAccessor getAccessibleComponentAccessor() {
>> 60:         return accessibleComponentAccessor;
> 
> It is better to force the "ensureClassInitialized" as any other getters in this class. To make sure the field is up-to-date even if it was initialized on another thread.

Done

> src/java.desktop/share/classes/sun/swing/SwingAccessor.java line 71:
> 
>> 69:      * For example, the renderer of a list element, a table cell, or a tree node
>> 70:      */
>> 71:     public interface AccessibleComponentAccessor {
> 
> Note that this class declares interfaces at the top, and then field/get/set at the bottom of the file.

done

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

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


From asemenov at openjdk.org  Tue Jan 10 11:06:30 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 10 Jan 2023 11:06:30 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v6]
In-Reply-To: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
Message-ID: <JE88O0rb_LlP1p1_HgP7o4rZ8sirU6AE1XxDO3bw8qg=.b92950ab-c86e-4e26-b00e-fd0568296a2c@github.com>

> [OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

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

  It is better to force the "ensureClassInitialized" as any other getters in this class. To make sure the field is up-to-date even if it was initialized on another thread.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11670/files
  - new: https://git.openjdk.org/jdk/pull/11670/files/6efb419e..ed0752e8

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

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

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


From asemenov at openjdk.org  Tue Jan 10 11:21:19 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 10 Jan 2023 11:21:19 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v7]
In-Reply-To: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
Message-ID: <DEOd3o_OfErVHt23Dp_GzoY0SOvDiY6sl1dsx-gWR8Y=.07bb9b7a-9bfd-4635-ae6b-cf40e6f47cbe@github.com>

> [OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

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

  It is better to force the "ensureClassInitialized" as any other getters in this class. To make sure the field is up-to-date even if it was initialized on another thread.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11670/files
  - new: https://git.openjdk.org/jdk/pull/11670/files/ed0752e8..2841c5e4

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

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

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


From asemenov at openjdk.org  Tue Jan 10 11:27:50 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 10 Jan 2023 11:27:50 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v8]
In-Reply-To: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
Message-ID: <O3Az9Np5wHv6eR6gUX87qMZzXQIeNWVwlIisGhIHBTU=.1c645dc6-decc-4fdd-b8d0-92e98d0596fe@github.com>

> [OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

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

  It is better to force the "ensureClassInitialized" as any other getters in this class. To make sure the field is up-to-date even if it was initialized on another thread.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11670/files
  - new: https://git.openjdk.org/jdk/pull/11670/files/2841c5e4..9e4f87c4

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

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

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


From avu at openjdk.org  Tue Jan 10 11:33:54 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Tue, 10 Jan 2023 11:33:54 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v8]
In-Reply-To: <O3Az9Np5wHv6eR6gUX87qMZzXQIeNWVwlIisGhIHBTU=.1c645dc6-decc-4fdd-b8d0-92e98d0596fe@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
 <O3Az9Np5wHv6eR6gUX87qMZzXQIeNWVwlIisGhIHBTU=.1c645dc6-decc-4fdd-b8d0-92e98d0596fe@github.com>
Message-ID: <1i0VC4L1yvqmQDMU8bmoO3bM8pVzU2lCZyVp6geGjQY=.a303a6c6-e2cc-4ee6-ac04-8384f57866d8@github.com>

On Tue, 10 Jan 2023 11:27:50 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> [OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   It is better to force the "ensureClassInitialized" as any other getters in this class. To make sure the field is up-to-date even if it was initialized on another thread.

Marked as reviewed by avu (Committer).

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

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


From aivanov at openjdk.org  Tue Jan 10 12:14:57 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 10 Jan 2023 12:14:57 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <PumLFS7NJwkLt_U6b3CCraoRha0lG6oy_K8v-uFTtV4=.5467e88c-f34b-449c-a71b-eefbe72999ba@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
 <DD5uVC90-DPgmwfJXNEgnLj_wxHGTD7_uKMZBwNLHa8=.6a564a17-23d4-4da8-8381-c882b852aaaa@github.com>
 <c4Qx6gF9iiaJdMaOybsl_4cNgqu8KPNOQQH2zBDAOzU=.a72f2f21-5212-4337-b3f3-ccff0a39c728@github.com>
 <jH6H-chU7-m3gPJRb1v2StPHplL06eKXHvUIrxV-FYE=.f6f34982-26c3-43b9-9ac0-ddb1a4fd1c9a@github.com>
 <PumLFS7NJwkLt_U6b3CCraoRha0lG6oy_K8v-uFTtV4=.5467e88c-f34b-449c-a71b-eefbe72999ba@github.com>
Message-ID: <A2gaQz19gcGEOYHSrUI1kpoGZAGXfSzIyUdGG7tnQgk=.9b95ef26-91b8-4ef4-9a6b-4aab6ef4aae5@github.com>

On Tue, 10 Jan 2023 05:19:41 GMT, Tejesh R <tr at openjdk.org> wrote:

> Not only _Downloads_ folder returns null, as I was mentioning it was varying for multiple test runs.

I remember you were saying that only this one was affected. I may have missed that other folders were affected as well.

> Then submitting a new bug for ImageIcon failing to load Image in headless systems right?

Yes, for this particular problem: a folder icon cannot be fetched from Windows on a headless system.

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

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


From aivanov at openjdk.org  Tue Jan 10 13:15:53 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 10 Jan 2023 13:15:53 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
In-Reply-To: <FJCr1YjS0OvOwRrDhrlveOjWSbrjxhWQD02P8-sfubI=.d6f4b0ee-3a35-4bcc-871c-1e29f32ab788@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <R5KpqeBP6UC7LgpvlCqEEFa7Imuu-rOluzwQqVrN5Pw=.e1226970-93fc-40f9-8a2e-42301b45be80@github.com>
 <FJCr1YjS0OvOwRrDhrlveOjWSbrjxhWQD02P8-sfubI=.d6f4b0ee-3a35-4bcc-871c-1e29f32ab788@github.com>
Message-ID: <Pvk-G052XxbYR4nUwOO5Vk1r-lLReIqN7XP-YhuLsF4=.e55fd066-064d-4742-8f78-5f8b761ab806@github.com>

On Tue, 10 Jan 2023 04:50:08 GMT, Tejesh R <tr at openjdk.org> wrote:

> > Taking the above into account, [JDK-8299522](https://bugs.openjdk.org/browse/JDK-8299522) is **Not an Issue**.
> 
> @aivanov-jdk Agree to your point. But I added the default text and tooltip as a fallback text which is already in aqua L&F. It's always safe to add a default text when user doesn't add explicitly, since it affects the button size in some L&F (like Metal) and empty text button in some other L&F (like windows).

Yet it is explicitly stated in the documentation that you are expected to explicitly provide the text for the Approve button if you use `CUSTOM_DIALOG` type.

This case is handled gracefully when the `showDialog` method is used, the Approve button has `Open` text at least in Windows and Metal L&Fs. This happens in Aqua L&F too.

Thus, this situation is already handled by the API which is most commonly used with `JFileChooser`.

I suggest handling the missing text for the Approve button if a custom dialog is used with adding a `JFileChooser` instance as component by falling back to the `Open` type.

If you prefer going this route and add new properties, I suggest following what's used in Aqua L&F that is `choose-` prefix for the properties and member names.

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

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


From tr at openjdk.org  Tue Jan 10 14:15:57 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 10 Jan 2023 14:15:57 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
In-Reply-To: <Pvk-G052XxbYR4nUwOO5Vk1r-lLReIqN7XP-YhuLsF4=.e55fd066-064d-4742-8f78-5f8b761ab806@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <R5KpqeBP6UC7LgpvlCqEEFa7Imuu-rOluzwQqVrN5Pw=.e1226970-93fc-40f9-8a2e-42301b45be80@github.com>
 <FJCr1YjS0OvOwRrDhrlveOjWSbrjxhWQD02P8-sfubI=.d6f4b0ee-3a35-4bcc-871c-1e29f32ab788@github.com>
 <Pvk-G052XxbYR4nUwOO5Vk1r-lLReIqN7XP-YhuLsF4=.e55fd066-064d-4742-8f78-5f8b761ab806@github.com>
Message-ID: <xhvyqOZf_mgM9FjVclv-UMIlbbQBT5zJr6piEXZEkzg=.a3f27c54-9502-4915-87dc-1edaf2c0141a@github.com>

On Tue, 10 Jan 2023 13:13:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I suggest handling the missing text for the Approve button if a custom dialog is used with adding a `JFileChooser` instance as component by falling back to the `Open` type.

I didn't get this point ? Can you please tell me what does "falling back to the 'Open' type means?

> If you prefer going this route and add new properties, I suggest following what's used in Aqua L&F that is `choose-` prefix for the properties and member names

Yeah, sure can change the prefix. Along with the approve button text?

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

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


From tr at openjdk.org  Tue Jan 10 14:48:03 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 10 Jan 2023 14:48:03 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <A2gaQz19gcGEOYHSrUI1kpoGZAGXfSzIyUdGG7tnQgk=.9b95ef26-91b8-4ef4-9a6b-4aab6ef4aae5@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
 <DD5uVC90-DPgmwfJXNEgnLj_wxHGTD7_uKMZBwNLHa8=.6a564a17-23d4-4da8-8381-c882b852aaaa@github.com>
 <c4Qx6gF9iiaJdMaOybsl_4cNgqu8KPNOQQH2zBDAOzU=.a72f2f21-5212-4337-b3f3-ccff0a39c728@github.com>
 <jH6H-chU7-m3gPJRb1v2StPHplL06eKXHvUIrxV-FYE=.f6f34982-26c3-43b9-9ac0-ddb1a4fd1c9a@github.com>
 <PumLFS7NJwkLt_U6b3CCraoRha0lG6oy_K8v-uFTtV4=.5467e88c-f34b-449c-a71b-eefbe72999ba@github.com>
 <A2gaQz19gcGEOYHSrUI1kpoGZAGXfSzIyUdGG7tnQgk=.9b95ef26-91b8-4ef4-9a6b-4aab6ef4aae5@github.com>
Message-ID: <8NCbdLCtapYaDVZQrl2rLo6NlCO8JrFzXr4OYMe4AWU=.6f24a709-00ad-4413-be0c-4961cced1110@github.com>

On Tue, 10 Jan 2023 12:12:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > Not only _Downloads_ folder returns null, as I was mentioning it was varying for multiple test runs.
> 
> I remember you were saying that only this one was affected. I may have missed that other folders were affected as well.
> 
> > Then submitting a new bug for ImageIcon failing to load Image in headless systems right?
> 
> Yes, for this particular problem: a folder icon cannot be fetched from Windows on a headless system.

Created - [JDK-8299893](https://bugs.openjdk.org/browse/JDK-8299893). Shall I integrate this PR by removing the test from problemList?

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

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


From aivanov at openjdk.org  Tue Jan 10 15:09:55 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 10 Jan 2023 15:09:55 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
In-Reply-To: <xhvyqOZf_mgM9FjVclv-UMIlbbQBT5zJr6piEXZEkzg=.a3f27c54-9502-4915-87dc-1edaf2c0141a@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <R5KpqeBP6UC7LgpvlCqEEFa7Imuu-rOluzwQqVrN5Pw=.e1226970-93fc-40f9-8a2e-42301b45be80@github.com>
 <FJCr1YjS0OvOwRrDhrlveOjWSbrjxhWQD02P8-sfubI=.d6f4b0ee-3a35-4bcc-871c-1e29f32ab788@github.com>
 <Pvk-G052XxbYR4nUwOO5Vk1r-lLReIqN7XP-YhuLsF4=.e55fd066-064d-4742-8f78-5f8b761ab806@github.com>
 <xhvyqOZf_mgM9FjVclv-UMIlbbQBT5zJr6piEXZEkzg=.a3f27c54-9502-4915-87dc-1edaf2c0141a@github.com>
Message-ID: <fOSzd1UrxtdthoqREYNtBOVi1Q9ZsMjBiR0eYwuoX8o=.24a16062-03b1-47cc-b0ce-5c12be4401cf@github.com>

On Tue, 10 Jan 2023 14:11:50 GMT, Tejesh R <tr at openjdk.org> wrote:

> > I suggest handling the missing text for the Approve button if a custom dialog is used with adding a `JFileChooser` instance as component by falling back to the `Open` type.
> 
> I didn't get this point ? Can you please tell me what does "falling back to the 'Open' type means?

This code

new JFileChooser().showDialog(null, null);

produces the dialog that looks like:
<img width="662" alt="JFileChooser custom dialog falls back to Open dialog" src="https://user-images.githubusercontent.com/70774172/211583355-6fed7d24-fff2-4c4b-9887-0bdd75f98930.png">

It looks exactly the same as the one created by

new JFileChooser().showOpenDialog(null);


The above code works well in the three L&F that I tested, the custom dialog behaves as if it's an open dialog and the Approve button has the text "Open".

Thus, the issue exists only if you use `setDialogType(JFileChooser.CUSTOM_DIALOG);` then add the instance of `JFileChooser` to a container such as `JFrame`.
 
What I meant is that you can use `openButtonText` for the Approve button if it wasn't set explicitly without creating additional properties and members. This can be achieved as simple as

diff --git a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java b/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java
index c307a138114..bf214389bda 100644
--- a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java
+++ b/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java
@@ -922,7 +922,8 @@ public class BasicFileChooserUI extends FileChooserUI {
         String buttonText = fc.getApproveButtonText();
         if (buttonText != null) {
             return buttonText;
-        } else if (fc.getDialogType() == JFileChooser.OPEN_DIALOG) {
+        } else if (fc.getDialogType() == JFileChooser.OPEN_DIALOG
+                   || fc.getDialogType() == JFileChooser.CUSTOM_DIALOG) {
             return openButtonText;
         } else if (fc.getDialogType() == JFileChooser.SAVE_DIALOG) {
             return saveButtonText;

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

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


From aivanov at openjdk.org  Tue Jan 10 15:17:55 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 10 Jan 2023 15:17:55 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
 [v2]
In-Reply-To: <H9y1l565M9k3wyJN7qoNpNAUIJwPSDy5QvmySeKE_LE=.8755e787-a1d5-41ea-ad5b-24ec48545981@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <H9y1l565M9k3wyJN7qoNpNAUIJwPSDy5QvmySeKE_LE=.8755e787-a1d5-41ea-ad5b-24ec48545981@github.com>
Message-ID: <OkzR9Y2JO591O8Q_n4SaVyixq6F1Fip7hr8tGPvSKvg=.26a7de9e-872d-4d4b-85b2-5ccf1b9bf50f@github.com>

On Tue, 10 Jan 2023 05:18:52 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 85:

> 83:         }
> 84: 
> 85:         JButton customApproveButton = findCustomApproveButton(fileChooser);

Can't you use `fileChooser.getUI().getDefaultButton(fileChooser)` instead of searching for it?

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

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


From tr at openjdk.org  Tue Jan 10 17:32:59 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 10 Jan 2023 17:32:59 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
 [v2]
In-Reply-To: <H9y1l565M9k3wyJN7qoNpNAUIJwPSDy5QvmySeKE_LE=.8755e787-a1d5-41ea-ad5b-24ec48545981@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <H9y1l565M9k3wyJN7qoNpNAUIJwPSDy5QvmySeKE_LE=.8755e787-a1d5-41ea-ad5b-24ec48545981@github.com>
Message-ID: <wdsFQfQu8Zg5TlzYnNFtLYRyaY9QirhOkKH9yYYk-Ws=.e6048067-7e40-4857-ae92-09b226ab925a@github.com>

On Tue, 10 Jan 2023 05:18:52 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

> > > I suggest handling the missing text for the Approve button if a custom dialog is used with adding a `JFileChooser` instance as component by falling back to the `Open` type.
> > 
> > 
> > I didn't get this point ? Can you please tell me what does "falling back to the 'Open' type means?
> 
> This code
> 
> ```java
> new JFileChooser().showDialog(null, null);
> ```
> 
> produces the dialog that looks like: <img alt="JFileChooser custom dialog falls back to Open dialog" width="662" src="https://user-images.githubusercontent.com/70774172/211583355-6fed7d24-fff2-4c4b-9887-0bdd75f98930.png">
> 
> It looks exactly the same as the one created by
> 
> ```java
> new JFileChooser().showOpenDialog(null);
> ```
> 
> The above code works well in the three L&F that I tested, the custom dialog behaves as if it's an open dialog and the Approve button has the text "Open".
> 
> Thus, the issue exists only if you use `setDialogType(JFileChooser.CUSTOM_DIALOG);` then add the instance of `JFileChooser` to a container such as `JFrame`.
> 
> What I meant is that you can use `openButtonText` for the Approve button if it wasn't set explicitly without creating additional properties and members. This can be achieved as simple as
> 
> ```diff
> diff --git a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java b/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java
> index c307a138114..bf214389bda 100644
> --- a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java
> +++ b/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java
> @@ -922,7 +922,8 @@ public class BasicFileChooserUI extends FileChooserUI {
>          String buttonText = fc.getApproveButtonText();
>          if (buttonText != null) {
>              return buttonText;
> -        } else if (fc.getDialogType() == JFileChooser.OPEN_DIALOG) {
> +        } else if (fc.getDialogType() == JFileChooser.OPEN_DIALOG
> +                   || fc.getDialogType() == JFileChooser.CUSTOM_DIALOG) {
>              return openButtonText;
>          } else if (fc.getDialogType() == JFileChooser.SAVE_DIALOG) {
>              return saveButtonText;
> ```

Yeah, initially had thought of doing this, but to keep the default text open for future changes and to maintain the default for CUSTOM Type separately I added additional properties and members. If using the OPEN type properties is fine for CUSTOM also then can use the same I guess.

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

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


From aivanov at openjdk.org  Tue Jan 10 17:46:51 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 10 Jan 2023 17:46:51 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
 [v2]
In-Reply-To: <wdsFQfQu8Zg5TlzYnNFtLYRyaY9QirhOkKH9yYYk-Ws=.e6048067-7e40-4857-ae92-09b226ab925a@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <H9y1l565M9k3wyJN7qoNpNAUIJwPSDy5QvmySeKE_LE=.8755e787-a1d5-41ea-ad5b-24ec48545981@github.com>
 <wdsFQfQu8Zg5TlzYnNFtLYRyaY9QirhOkKH9yYYk-Ws=.e6048067-7e40-4857-ae92-09b226ab925a@github.com>
Message-ID: <qwZkqffz7GpOl5UTlO4UlZlLpwYIzrKc1LiGHTWlQT0=.61b211c9-c2ae-418e-aa2f-3e733706313a@github.com>

On Tue, 10 Jan 2023 17:30:27 GMT, Tejesh R <tr at openjdk.org> wrote:

> Yeah, initially had thought of doing this, but to keep the default text open for future changes and to maintain the default for CUSTOM Type separately I added additional properties and members. If using the OPEN type properties is fine for CUSTOM also then can use the same I guess.

It seems fine to me. It's the behaviour if you use the `showDialog` method which shows the same dialog as `showOpenDialog`.

However, Aqua L&F does use special properties, which are used only in the case where the file chooser is embedded in UI hierarchy as opposed to using the `show*Dialog` methods to display a modal dialog box.

> > If you prefer going this route and add new properties, I suggest following what's used in Aqua L&F that is `choose-` prefix for the properties and member names
> 
> Yeah, sure can change the prefix. Along with the approve button text?

Since the type is `CUSTOM_DIALOG`, using `custom-` prefix that you use is actually better as it makes the naming consistent.

However, I'm still inclined to closing this bug as *Not an Issue* because you, as the developer, have to explicitly set the text for the Approve button if you use the customer dialog ? it's _custom_ after all.

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

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


From tr at openjdk.org  Tue Jan 10 17:56:53 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 10 Jan 2023 17:56:53 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
 [v2]
In-Reply-To: <H9y1l565M9k3wyJN7qoNpNAUIJwPSDy5QvmySeKE_LE=.8755e787-a1d5-41ea-ad5b-24ec48545981@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <H9y1l565M9k3wyJN7qoNpNAUIJwPSDy5QvmySeKE_LE=.8755e787-a1d5-41ea-ad5b-24ec48545981@github.com>
Message-ID: <rJcKrfhsC4vSiLwQVTgduXt_AL_B9vYOtegDMLhcjo8=.dc902efc-af7c-4d0c-9be5-78b78f53604b@github.com>

On Tue, 10 Jan 2023 05:18:52 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

> > Yeah, initially had thought of doing this, but to keep the default text open for future changes and to maintain the default for CUSTOM Type separately I added additional properties and members. If using the OPEN type properties is fine for CUSTOM also then can use the same I guess.
> 
> It seems fine to me. It's the behaviour if you use the `showDialog` method which shows the same dialog as `showOpenDialog`.
> 
> However, Aqua L&F does use special properties, which are used only in the case where the file chooser is embedded in UI hierarchy as opposed to using the `show*Dialog` methods to display a modal dialog box.
> 
> > > If you prefer going this route and add new properties, I suggest following what's used in Aqua L&F that is `choose-` prefix for the properties and member names
> > 
> > 
> > Yeah, sure can change the prefix. Along with the approve button text?
> 
> Since the type is `CUSTOM_DIALOG`, using `custom-` prefix that you use is actually better as it makes the naming consistent.
> 
> However, I'm still inclined to closing this bug as _Not an Issue_ because you, as the developer, have to explicitly set the text for the Approve button if you use the customer dialog ? it's _custom_ after all.

Then instead of adding new properties and members let me do as you suggested, to use OPEN type so that the size issue will be handled, and no new properties/members will be introduced. Fine right?

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

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


From aivanov at openjdk.org  Tue Jan 10 18:06:54 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 10 Jan 2023 18:06:54 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
 [v2]
In-Reply-To: <rJcKrfhsC4vSiLwQVTgduXt_AL_B9vYOtegDMLhcjo8=.dc902efc-af7c-4d0c-9be5-78b78f53604b@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <H9y1l565M9k3wyJN7qoNpNAUIJwPSDy5QvmySeKE_LE=.8755e787-a1d5-41ea-ad5b-24ec48545981@github.com>
 <rJcKrfhsC4vSiLwQVTgduXt_AL_B9vYOtegDMLhcjo8=.dc902efc-af7c-4d0c-9be5-78b78f53604b@github.com>
Message-ID: <T6Zvh5FtrqUgd3h9Ez2v5MdOGZABEWhZl9INp2kX9f0=.cc0a6b4b-593d-443f-b074-8af21a6dfbef@github.com>

On Tue, 10 Jan 2023 17:54:35 GMT, Tejesh R <tr at openjdk.org> wrote:

> > However, I'm still inclined to closing this bug as _Not an Issue_ because you, as the developer, have to explicitly set the text for the Approve button if you use the customer dialog ? it's _custom_ after all.

Here I meant doing nothing at all. To fix the issue, call `JFileChooser.setApproveButtonText` to set the text for the Approve button.

> Then instead of adding new properties and members let me do as you suggested, to use OPEN type so that the size issue will be handled, and no new properties/members will be introduced. Fine right?

This kind of change shouldn't require a CSR.

[`FileChooserUI.getApproveButtonText`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/plaf/FileChooserUI.html#getApproveButtonText(javax.swing.JFileChooser)) does not specify any details. If you apply the diff I suggested, the implementation will remain conformant.

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

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


From honkar at openjdk.org  Tue Jan 10 18:38:54 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 10 Jan 2023 18:38:54 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v2]
In-Reply-To: <khi7qxHGfmXGpnh4dI8xvdF7Vhk8VGNEvAXnApSCX_4=.7ab787b4-3233-452e-b7f6-2ee699a2befe@github.com>
References: <iYA9P9YljBfvinZEbBIF8tWJXtZLXgBxdcBmgLKb7CU=.79a7273a-cb2e-4a80-8c29-18347a9de767@github.com>
 <Scc8KQ4HtOWbXTPeR0GKZDVY7joh65CvO4RUsAw4Te4=.67bf9abd-86be-4f00-b4d9-a6f53e548c4b@github.com>
 <khi7qxHGfmXGpnh4dI8xvdF7Vhk8VGNEvAXnApSCX_4=.7ab787b4-3233-452e-b7f6-2ee699a2befe@github.com>
Message-ID: <5t0qbd9_FCYD10NRnnAo89JCM0ZhtwYsSuV52x80bzM=.e3faf6d1-8e4c-4bee-a361-55ce69da606a@github.com>

On Tue, 3 Jan 2023 12:03:00 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Test case passed even without doing changes in `skin.laf`. Tested in Windows11.

The above is true for Win10 as well. The text appears in red without the skin.laf changes.

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

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


From mcimadamore at openjdk.org  Tue Jan 10 18:52:56 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 10 Jan 2023 18:52:56 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
Message-ID: <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>

On Sat, 7 Jan 2023 21:08:07 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix incorrect @bug numbers in unit tests.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2345:

> 2343:         if (!innerType.hasTag(CLASS) || !outerType.hasTag(CLASS))
> 2344:             return false;
> 2345:         innerType = erasure(innerType);

The javac way to write this would be either to compare types using `Types.isSameType` or to compare the underlying class symbols with == (as class symbols are shared across multiple type instances).

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 85:

> 83:  *
> 84:  * <p>
> 85:  * When tracking references, we distinguish between direct references and indirect references,

I'm trying to understand the code and it's not obvious to me as to where this difference comes into play. I believe (but I'm not sure) the spirit is to treat reference to `this` in the original constructor as "direct" while treat a reference to a parameter "a" in a method called from the constructor, where "a" is assigned "this", as indirect?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1098:

> 1096:     private <T extends JCTree> void visitLooped(T tree, Consumer<T> visitor) {
> 1097:         this.visitScoped(tree, false, t -> {
> 1098:             while (true) {

Why is this needed? Can the tracking state of `this` change after multiple "execution" of the same code?

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

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


From tr at openjdk.org  Tue Jan 10 19:01:31 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 10 Jan 2023 19:01:31 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
 [v3]
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <qLnwbeao8QFUJqJRh6pezl3tsk6fVALQH99TwCF0sEI=.343e942b-89a9-42b5-a794-b2e556dff7a6@github.com>

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

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/11901/files
  - new: https://git.openjdk.org/jdk/pull/11901/files/a95f0ff3..415f5918

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

  Stats: 70 lines in 3 files changed: 8 ins; 57 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11901.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11901/head:pull/11901

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


From duke at openjdk.org  Tue Jan 10 19:22:58 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 10 Jan 2023 19:22:58 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
Message-ID: <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>

On Mon, 9 Jan 2023 15:03:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix incorrect @bug numbers in unit tests.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 85:
> 
>> 83:  *
>> 84:  * <p>
>> 85:  * When tracking references, we distinguish between direct references and indirect references,
> 
> I'm trying to understand the code and it's not obvious to me as to where this difference comes into play. I believe (but I'm not sure) the spirit is to treat reference to `this` in the original constructor as "direct" while treat a reference to a parameter "a" in a method called from the constructor, where "a" is assigned "this", as indirect?

It's slightly different from that.

Considering any of the various things in scope that can point to an object (these are: the current 'this' instance, the current outer 'this' instance, method parameter/variable, method return value, top of Java stack), such a thing has a "direct" reference if it might possibly _directly_ point to the 'this' we're tracking, while a thing has an "indirect" reference if it might possibly point to the 'this' we're tracking through _at least one level of indirection_.

This is just an attempt to eliminate some false positives by distinguishing between those two cases. Originally I was going to try to track fields (in a very limited way), and so this distinction was going to be more important, but even without tracking fields it's still useful. For example, if some method invokes `x.y.foo()` and `x` represents a direct but not an indirect 'this' reference, then there is no leak declared.

Considering the other options... (a) if you only track direct references, then you suffer from more false negatives (how many? unclear); (b) if you lump direct and indirect references into one bucket, then you suffer from more false positives (as in previous example `x.y.foo()`).

You can see an example of an indirect reference being tracked and exposed in the unit test `ThisEscapeArrayElement.java`.

Another motivating example is lambdas. The act of simply _creating_ a lambda never creates a leak, and a lambda never represents a _direct_ reference. But it might represent an _indirect_ reference.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1098:
> 
>> 1096:     private <T extends JCTree> void visitLooped(T tree, Consumer<T> visitor) {
>> 1097:         this.visitScoped(tree, false, t -> {
>> 1098:             while (true) {
> 
> Why is this needed? Can the tracking state of `this` change after multiple "execution" of the same code?

Yes, because the 'this' reference can bounce around through different variables in scope each time around the loop. So we have to repeat the loop until all 'this' references have "flooded" into all the nooks and crannies.

The `ThisEscapeLoop.java` unit test demonstrates:

public class ThisEscapeLoop { 
    
    public ThisEscapeLoop() { 
        ThisEscapeLoop ref1 = this;
        ThisEscapeLoop ref2 = null;
        ThisEscapeLoop ref3 = null;
        ThisEscapeLoop ref4 = null;
        for (int i = 0; i < 100; i++) {
            ref4 = ref3;
            ref3 = ref2;
            ref2 = ref1;
            if (ref4 != null)
                ref4.mightLeak();
        }
    }

    public void mightLeak() {
    }
}

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

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


From duke at openjdk.org  Tue Jan 10 19:44:56 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 10 Jan 2023 19:44:56 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
Message-ID: <oWX_ZhpcpYhGU0fVGA-R3I_p0yYPNkW6NKBT9c7FwoU=.3219ea09-6087-409f-a55e-3b1abdc3dc20@github.com>

On Mon, 9 Jan 2023 14:23:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix incorrect @bug numbers in unit tests.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2345:
> 
>> 2343:         if (!innerType.hasTag(CLASS) || !outerType.hasTag(CLASS))
>> 2344:             return false;
>> 2345:         innerType = erasure(innerType);
> 
> The javac way to write this would be either to compare types using `Types.isSameType` or to compare the underlying class symbols with == (as class symbols are shared across multiple type instances).

OK I'm glad you pointed that out because I'm a little unclear on the best way to do this bit.

Just to confirm, you are saying that this:

`if (erasure(type).equalsIgnoreMetadata(outerType)) {`

should be replaced with this?

`if (isSameType(type, outerType)) {`

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

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


From duke at openjdk.org  Tue Jan 10 20:22:16 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 10 Jan 2023 20:22:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v6]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <-cVR0e9azbb3U9vWObNm1dBbUGIDuI7T6bAOpuPSG8I=.a55f2d47-00ae-471c-a51c-df638c104487@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Add this-escape to the Javadoc list of strings supported by @SuppressWarnings.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/7e2fdb07..d70d12f4

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

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

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


From aivanov at openjdk.org  Tue Jan 10 21:40:21 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 10 Jan 2023 21:40:21 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v2]
In-Reply-To: <NSe5ZVQIz159nKk8zeuC-O01YzdbdBbKXM5Wlo3aqtE=.4fcd9130-ed6a-4508-bad4-fce86ee3093d@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
 <NSe5ZVQIz159nKk8zeuC-O01YzdbdBbKXM5Wlo3aqtE=.4fcd9130-ed6a-4508-bad4-fce86ee3093d@github.com>
Message-ID: <bS-A0cv8NvVX8Uw2vhhLGAlXrSqfYQ3MsCsAa6q5_qQ=.f8d4e9ca-cdc1-4d55-a99a-f8268478a158@github.com>

On Fri, 6 Jan 2023 07:21:12 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
>> 
>> Fix:
>> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
>> Also updated the screen capture code, made frame undecorated, added some prints for better debugging.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Replaced one robot.waitForIdle with robot.delay(), formatting corrections, taken the insets into account for initial frame position

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 77:

> 75:                 while (point.x <
> 76:                        screenBounds.x + screenBounds.width - insets.right -
> 77:                        SIZE) {

Suggestion:

            final int yBound = screenBounds.y + screenBounds.height
                               - insets.bottom - SIZE;
            final int xBound = screenBounds.x + screenBounds.width
                               - insets.right - SIZE;
            while (point.y < yBound) {
                while (point.x < xBound) {


I think this looks clearer and more readable than the wrapped condition.

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 87:

> 85:     }
> 86: 
> 87:     private static void test(final Point tmp) {

Suggestion:

    private static void test(final Point loc) {

Let's give a better name to the parameter.

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 104:

> 102:             frame.setSize(SIZE, SIZE);
> 103:             frame.setVisible(true);
> 104:             frame.setLocation(tmp.x, tmp.y);

Suggestion:

            frame.setLocation(tmp);
            frame.setVisible(true);

You can pass a `Point` object to `setLocation` directly.

Setting the location before making the frame visible avoids flickering where the frame appears at 0, 0 and then moves to another location.

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

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


From aivanov at openjdk.org  Tue Jan 10 21:40:22 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 10 Jan 2023 21:40:22 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v2]
In-Reply-To: <hzBu8ey7PmsXzX0DwJWwGOdKnIiONiGGt4wmFCWtRoY=.fcc782d0-f7dc-4f6e-aaf5-70a1b20f2229@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
 <bCjlBewHa7tXT7d5mtQmLxcMbGDApK2ZvtN3RSnCpCM=.fb8b14dd-1585-44d7-a153-9ec72ac20670@github.com>
 <bxzrjMDW_3h7vTjV8AL5ziDpF1fsujnTd1yojkhadbs=.f72d0e06-08b8-4cbc-9953-efe05647b20b@github.com>
 <hzBu8ey7PmsXzX0DwJWwGOdKnIiONiGGt4wmFCWtRoY=.fcc782d0-f7dc-4f6e-aaf5-70a1b20f2229@github.com>
Message-ID: <WW7u_sdpAbc2xxsgibzRI1T31thA5FIaN57l6ghADRs=.99459089-fbd7-46a3-9cc8-bae112901a05@github.com>

On Fri, 6 Jan 2023 07:16:49 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Yes, this `robot.waitForIdle` makes the test unbearably slow. Worth submitting a separate bug with the reproducer. At this point, the pop is shown on the screen and its first item is highlighted.
>> 
>> I replaced it with
>> 
>> robot.delay(200);
>
> Replaced robot.waitForIdle with robot.delay(200). I will check the possibility of raising a new bug.

Since no one expected for `robot.waitForIdle` to make the test so slow here, I suggest submitting a bug for evaluation. You have a working test case for this. The frame doesn't need to move across the screen.

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

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


From mik3hall at gmail.com  Tue Jan 10 23:07:39 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 10 Jan 2023 17:07:39 -0600
Subject: OS/X GUI applications
In-Reply-To: <1409C528-2A83-4A41-B3BE-4FFB869748E7@gmail.com>
References: <CA1D7F10-343A-4052-8E35-D21C32F9719B@gmail.com>
 <22d33eca-eb38-8401-291a-c7a62c25d1ee@oracle.com>
 <12bbb5e2-dc26-5bbe-22e5-816027ffc32b@oracle.com>
 <629416D3-AA95-4B07-903B-FCF264FF8A42@gmail.com>
 <1409C528-2A83-4A41-B3BE-4FFB869748E7@gmail.com>
Message-ID: <F4FB7D19-910E-412C-B586-022E62473C8F@gmail.com>

I bug reported

internal review ID : 9074634


From mcimadamore at openjdk.org  Tue Jan 10 23:41:19 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 10 Jan 2023 23:41:19 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <oWX_ZhpcpYhGU0fVGA-R3I_p0yYPNkW6NKBT9c7FwoU=.3219ea09-6087-409f-a55e-3b1abdc3dc20@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <oWX_ZhpcpYhGU0fVGA-R3I_p0yYPNkW6NKBT9c7FwoU=.3219ea09-6087-409f-a55e-3b1abdc3dc20@github.com>
Message-ID: <0Hksmg2eLQg0c9W5CB6y6dXw2vaEXxy-UY9_D0DtLQY=.351da0ec-208c-4f8d-bf16-318de07ca63e@github.com>

On Tue, 10 Jan 2023 19:42:06 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2345:
>> 
>>> 2343:         if (!innerType.hasTag(CLASS) || !outerType.hasTag(CLASS))
>>> 2344:             return false;
>>> 2345:         innerType = erasure(innerType);
>> 
>> The javac way to write this would be either to compare types using `Types.isSameType` or to compare the underlying class symbols with == (as class symbols are shared across multiple type instances).
>
> OK I'm glad you pointed that out because I'm a little unclear on the best way to do this bit.
> 
> Just to confirm, you are saying that this:
> 
> `if (erasure(type).equalsIgnoreMetadata(outerType)) {`
> 
> should be replaced with this?
> 
> `if (isSameType(type, outerType)) {`

yes

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

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


From mcimadamore at openjdk.org  Tue Jan 10 23:49:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 10 Jan 2023 23:49:12 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
Message-ID: <8PxlV-Syo2Y48TBgSQupSjArfJxMqnA8BZQIYTfYGPA=.057f204c-330b-4fb9-96e5-f8dc8fe348aa@github.com>

On Tue, 10 Jan 2023 19:18:04 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 85:
>> 
>>> 83:  *
>>> 84:  * <p>
>>> 85:  * When tracking references, we distinguish between direct references and indirect references,
>> 
>> I'm trying to understand the code and it's not obvious to me as to where this difference comes into play. I believe (but I'm not sure) the spirit is to treat reference to `this` in the original constructor as "direct" while treat a reference to a parameter "a" in a method called from the constructor, where "a" is assigned "this", as indirect?
>
> It's slightly different from that.
> 
> Considering any of the various things in scope that can point to an object (these are: the current 'this' instance, the current outer 'this' instance, method parameter/variable, method return value, top of Java stack), such a thing has a "direct" reference if it might possibly _directly_ point to the 'this' we're tracking, while a thing has an "indirect" reference if it might possibly point to the 'this' we're tracking through _at least one level of indirection_.
> 
> This is just an attempt to eliminate some false positives by distinguishing between those two cases. Originally I was going to try to track fields (in a very limited way), and so this distinction was going to be more important, but even without tracking fields it's still useful. For example, if some method invokes `x.y.foo()` and `x` represents a direct but not an indirect 'this' reference, then there is no leak declared.
> 
> Considering the other options... (a) if you only track direct references, then you suffer from more false negatives (how many? unclear); (b) if you lump direct and indirect references into one bucket, then you suffer from more false positives (as in previous example `x.y.foo()`).
> 
> You can see an example of an indirect reference being tracked and exposed in the unit test `ThisEscapeArrayElement.java`.
> 
> Another motivating example is lambdas. The act of simply _creating_ a lambda never creates a leak, and a lambda never represents a _direct_ reference. But it might represent an _indirect_ reference.

So, if I understand correctly your array element test, when we have `new Object[][] { { this } }` the analysis is able to detect that there might be some direct reference nested inside the array. So the outer array is an indirect reference. The inner array is also an indirect reference - but any element accessed on the inner array are direct reference - and so you detect a leak there. Correct?

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

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


From duke at openjdk.org  Wed Jan 11 00:07:14 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 00:07:14 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <8PxlV-Syo2Y48TBgSQupSjArfJxMqnA8BZQIYTfYGPA=.057f204c-330b-4fb9-96e5-f8dc8fe348aa@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <8PxlV-Syo2Y48TBgSQupSjArfJxMqnA8BZQIYTfYGPA=.057f204c-330b-4fb9-96e5-f8dc8fe348aa@github.com>
Message-ID: <HODQOhvCyM19eFBP_7D9TSbUv6HqKnEA6JfEG13N5wk=.2562e5f0-8468-4f7a-a9f8-49e6183845b1@github.com>

On Tue, 10 Jan 2023 23:45:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> It's slightly different from that.
>> 
>> Considering any of the various things in scope that can point to an object (these are: the current 'this' instance, the current outer 'this' instance, method parameter/variable, method return value, top of Java stack), such a thing has a "direct" reference if it might possibly _directly_ point to the 'this' we're tracking, while a thing has an "indirect" reference if it might possibly point to the 'this' we're tracking through _at least one level of indirection_.
>> 
>> This is just an attempt to eliminate some false positives by distinguishing between those two cases. Originally I was going to try to track fields (in a very limited way), and so this distinction was going to be more important, but even without tracking fields it's still useful. For example, if some method invokes `x.y.foo()` and `x` represents a direct but not an indirect 'this' reference, then there is no leak declared.
>> 
>> Considering the other options... (a) if you only track direct references, then you suffer from more false negatives (how many? unclear); (b) if you lump direct and indirect references into one bucket, then you suffer from more false positives (as in previous example `x.y.foo()`).
>> 
>> You can see an example of an indirect reference being tracked and exposed in the unit test `ThisEscapeArrayElement.java`.
>> 
>> Another motivating example is lambdas. The act of simply _creating_ a lambda never creates a leak, and a lambda never represents a _direct_ reference. But it might represent an _indirect_ reference.
>
> So, if I understand correctly your array element test, when we have `new Object[][] { { this } }` the analysis is able to detect that there might be some direct reference nested inside the array. So the outer array is an indirect reference. The inner array is also an indirect reference - but any element accessed on the inner array are direct reference - and so you detect a leak there. Correct?

Yes - although it's not tracked being tracked any more precisely than "one or more levels of indirection".

And of course by "reference" we only mean "the possibility of a reference" - in general we don't know for sure.

Here's the logic:
* The analysis knows `this` is a direct reference
* Therefore the array expression `{ this }` has an indirect reference (but no direct reference)
* The outer array expression `{ { this } }` therefore _also_ has an indirect reference (but no direct reference)

At this point, we don't know how many levels of indirection there are in `array` though.... only that its ? 1.

* There expression `array[0]` therefore is determined to have both direct and indirect references (they are both _possible_ because we've dereferenced something with an indirect reference)
* As does `array[0][0]` for the same reason

So invoking `array[0][0].hashCode()` means invoking `hashCode()` on something that has a possible direct reference, and is therefore a leak.

Note that because of the imprecision in the number of levels of indirection, invoking `array[0].hashCode()` would also have generated a warning - but in that case, a false positive.

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

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


From mcimadamore at openjdk.org  Wed Jan 11 00:07:15 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jan 2023 00:07:15 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
Message-ID: <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>

On Tue, 10 Jan 2023 19:20:35 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1098:
>> 
>>> 1096:     private <T extends JCTree> void visitLooped(T tree, Consumer<T> visitor) {
>>> 1097:         this.visitScoped(tree, false, t -> {
>>> 1098:             while (true) {
>> 
>> Why is this needed? Can the tracking state of `this` change after multiple "execution" of the same code?
>
> Yes, because the 'this' reference can bounce around through different variables in scope each time around the loop. So we have to repeat the loop until all 'this' references have "flooded" into all the nooks and crannies.
> 
> The `ThisEscapeLoop.java` unit test demonstrates:
> 
> public class ThisEscapeLoop { 
>     
>     public ThisEscapeLoop() { 
>         ThisEscapeLoop ref1 = this;
>         ThisEscapeLoop ref2 = null;
>         ThisEscapeLoop ref3 = null;
>         ThisEscapeLoop ref4 = null;
>         for (int i = 0; i < 100; i++) {
>             ref4 = ref3;
>             ref3 = ref2;
>             ref2 = ref1;
>             if (ref4 != null)
>                 ref4.mightLeak();
>         }
>     }
> 
>     public void mightLeak() {
>     }
> }

So, if the code was be like this:


ThisEscapeLoop ref11 = this;
ThisEscapeLoop ref12 = null;
ThisEscapeLoop ref13 = null;
ThisEscapeLoop ref14 = null;
for (int i = 0; i < 100; i++) {
    ref14 = ref13;
    ref13 = ref12;
    ref12 = ref11;
    ThisEscapeLoop ref21 = ref14;
    ThisEscapeLoop ref22 = null;
    ThisEscapeLoop ref23 = null;
    ThisEscapeLoop ref24 = null;
    for (int i = 0; i < 100; i++) {
        ref24 = ref23;
        ref23 = ref22;
        ref22 = ref21;
        if (ref24 != null)
            ref24.mightLeak();
    }
}


Then it would take not 3 iterations but 3 * 3 to figure out that it is a potential leak?

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

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


From duke at openjdk.org  Wed Jan 11 00:25:10 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 00:25:10 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
Message-ID: <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>

On Wed, 11 Jan 2023 00:04:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Yes, because the 'this' reference can bounce around through different variables in scope each time around the loop. So we have to repeat the loop until all 'this' references have "flooded" into all the nooks and crannies.
>> 
>> The `ThisEscapeLoop.java` unit test demonstrates:
>> 
>> public class ThisEscapeLoop { 
>>     
>>     public ThisEscapeLoop() { 
>>         ThisEscapeLoop ref1 = this;
>>         ThisEscapeLoop ref2 = null;
>>         ThisEscapeLoop ref3 = null;
>>         ThisEscapeLoop ref4 = null;
>>         for (int i = 0; i < 100; i++) {
>>             ref4 = ref3;
>>             ref3 = ref2;
>>             ref2 = ref1;
>>             if (ref4 != null)
>>                 ref4.mightLeak();
>>         }
>>     }
>> 
>>     public void mightLeak() {
>>     }
>> }
>
> So, if the code was be like this:
> 
> 
> ThisEscapeLoop ref11 = this;
> ThisEscapeLoop ref12 = null;
> ThisEscapeLoop ref13 = null;
> ThisEscapeLoop ref14 = null;
> for (int i = 0; i < 100; i++) {
>     ref14 = ref13;
>     ref13 = ref12;
>     ref12 = ref11;
>     ThisEscapeLoop ref21 = ref14;
>     ThisEscapeLoop ref22 = null;
>     ThisEscapeLoop ref23 = null;
>     ThisEscapeLoop ref24 = null;
>     for (int i = 0; i < 100; i++) {
>         ref24 = ref23;
>         ref23 = ref22;
>         ref22 = ref21;
>         if (ref24 != null)
>             ref24.mightLeak();
>     }
> }
> 
> 
> Then it would take not 3 iterations but 3 * 3 to figure out that it is a potential leak?

Actually I think it would take 1 + 1 + 3 iterations.

During the first two iterations of the outer loop, nothing changes after the first go round of the inner loop - i.e., the total set of possible references in existence does not change, because all of the assignments in the inner loop won't involve any 'this' references.

It's only the during the third iteration of the outer loop that any 'this' references seep into any of the variables seen by the inner loop. Then it will take 3 cycles for the reference set to converge again.

However, this is not to say that there aren't some pathological examples out there. I guess the question is could they exist in "normal" code.

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

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


From duke at openjdk.org  Wed Jan 11 03:30:03 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 03:30:03 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Use the more appropriate Type comparison method Types.isSameType().
 - Add some more comments to clarify how the analysis works.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/d70d12f4..6e96a7d7

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

  Stats: 31 lines in 2 files changed: 16 ins; 10 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

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


From duke at openjdk.org  Wed Jan 11 03:30:05 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 03:30:05 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <0Hksmg2eLQg0c9W5CB6y6dXw2vaEXxy-UY9_D0DtLQY=.351da0ec-208c-4f8d-bf16-318de07ca63e@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <oWX_ZhpcpYhGU0fVGA-R3I_p0yYPNkW6NKBT9c7FwoU=.3219ea09-6087-409f-a55e-3b1abdc3dc20@github.com>
 <0Hksmg2eLQg0c9W5CB6y6dXw2vaEXxy-UY9_D0DtLQY=.351da0ec-208c-4f8d-bf16-318de07ca63e@github.com>
Message-ID: <7jUSzUYT_eWYGbHkDes10f2-1i5DNdmDGDACe8qsXU4=.5bca0f1b-e004-48bc-87e0-48d6fb9deb96@github.com>

On Tue, 10 Jan 2023 23:38:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> OK I'm glad you pointed that out because I'm a little unclear on the best way to do this bit.
>> 
>> Just to confirm, you are saying that this:
>> 
>> `if (erasure(type).equalsIgnoreMetadata(outerType)) {`
>> 
>> should be replaced with this?
>> 
>> `if (isSameType(type, outerType)) {`
>
> yes

Thanks... updated in `6e96a7d76f8`.

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

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


From psadhukhan at openjdk.org  Wed Jan 11 05:36:12 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 11 Jan 2023 05:36:12 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <QDs0PphbeFMHkJImTzpS_xzfku460k7LO0NuNZmLhL0=.dbd6baa9-81c8-416e-8d92-16473a0b2fca@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
 <UkTmmsjU6an23Wvu-4SQr9Dhit0Y7P168edjmIYODXs=.07ae6e07-0ed8-4daa-9588-2a0db2989528@github.com>
 <QDs0PphbeFMHkJImTzpS_xzfku460k7LO0NuNZmLhL0=.dbd6baa9-81c8-416e-8d92-16473a0b2fca@github.com>
Message-ID: <pc3CuaZTIxu3YaHHZ81dNtCGsyj9oIEz9Et3Lmud-Gk=.0174bf0f-2a5f-4180-ba2c-415cc893a327@github.com>

On Mon, 9 Jan 2023 16:51:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I dont think there is any difference between passing method argument vis-a-vis this as I think both point to same object..
> 
> Are you sure that it is always the same? Right now we ignore the component passed from the SynthListUI.propertyChange() and use list, after the change we will use the source of the event, I think that could be tested.

Actually, component argument passed to updateStyle() points to widget and "this" actually points to the UI delegate. 
For ex as seen in SwingSet2
for JTable widget, "c" points to JTable and "this" points to SynthTableUI
for TabbedPane, "c" points to JTabbedPane and "this" points to SynthTabbedPaneUI
for SplitPanedemo , "c" points to JSplitPane and "this" points to SynthSplitPaneUI
for SLider  "c" points to JSIlder and "this" points to SynthSliderUI

Similarly, for List Demo in SwingSet2, "c" points to JList and "this" points to SynthListUI

And regarding the other point of using "source of the event" from propertyChange() for SynthList for this fix,
this is what is being used for all other widgets too like below and am not sure how this can be tested
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java#L708
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSliderUI.java#L894
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java#L248
 etc to list a few

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

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


From psadhukhan at openjdk.org  Wed Jan 11 05:52:57 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 11 Jan 2023 05:52:57 GMT
Subject: RFR: 8284825:
 sun/java2d/DirectX/MultiPaintEventTest/MultiPaintEventTest.java failed with
 "RuntimeException: Processed unnecessary paint()."
Message-ID: <UfqXn2MVVu2jeJkbc4UP-OG8OCJXfE8_HPEwa5Qt0DU=.61ec7cea-1619-4a47-aa4f-b35af6f57be2@github.com>

Now that [commit](https://git.openjdk.org/jdk/commit/4072412c1fd1e28febff71c6b37a9813f22bdc4b)
has reverted [JDK-8275715](https://bugs.openjdk.org/browse/JDK-8275715)  along with the test
there's no need of keeping the non-existent test problemlisted, which we can remove

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

Commit messages:
 - JDK-8284825: sun/java2d/DirectX/MultiPaintEventTest/MultiPaintEventTest.java failed with RuntimeException: Processed unnecessary paint().

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

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


From mvs at openjdk.org  Wed Jan 11 06:14:41 2023
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 11 Jan 2023 06:14:41 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v3]
In-Reply-To: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
Message-ID: <wuNA2dNT--n0ntTqRpNYiY-AZPgTqg4BbJR0cHAzcsg=.e65f88cb-05c5-4b67-8b70-8a853f508bca@github.com>

> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
> 
> Fix:
> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
> Also updated the screen capture code, made frame undecorated, added some prints for better debugging.

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: Refactoring, formatting corrections, frame.setVisible(true) position changed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10655/files
  - new: https://git.openjdk.org/jdk/pull/10655/files/b3ac566d..fe4f9bb4

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

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

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


From tr at openjdk.org  Wed Jan 11 06:35:49 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 11 Jan 2023 06:35:49 GMT
Subject: RFR: 8299522: JFilechooser open button size is incorrectly shown
 [v4]
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <999t6e7nMiYkRBFxmGYeuFgp1qX3V9BvfGBL1ZzqgHc=.3ab7ce37-1729-4e5d-9eb1-76474e2dcd9e@github.com>

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

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

  Reverting aqua check condition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11901/files
  - new: https://git.openjdk.org/jdk/pull/11901/files/415f5918..dbbc68cb

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

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

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


From abhiscxk at openjdk.org  Wed Jan 11 06:40:14 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 11 Jan 2023 06:40:14 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
Message-ID: <o35MdDEuJEfvK5pZ6Iqfsylu70Vm63Ckr0n8jDiisRg=.f4a80a3a-d6c2-4462-b3eb-a2b56f3217af@github.com>

On Thu, 22 Dec 2022 05:13:34 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.
>
> 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 abhiscxk (Author).

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

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


From aturbanov at openjdk.org  Wed Jan 11 07:05:14 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 11 Jan 2023 07:05:14 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v4]
In-Reply-To: <999t6e7nMiYkRBFxmGYeuFgp1qX3V9BvfGBL1ZzqgHc=.3ab7ce37-1729-4e5d-9eb1-76474e2dcd9e@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <999t6e7nMiYkRBFxmGYeuFgp1qX3V9BvfGBL1ZzqgHc=.3ab7ce37-1729-4e5d-9eb1-76474e2dcd9e@github.com>
Message-ID: <pX2WZBv46bDsVHcpI1XoQ5WidQYxORLUHGTIrzk5PO0=.6e208325-1195-44f3-b5d7-e4049144cd55@github.com>

On Wed, 11 Jan 2023 06:35:49 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting aqua check condition

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 586:

> 584:         }
> 585: 
> 586:         if(fc.getDialogType() == JFileChooser.OPEN_DIALOG ||

Suggestion:

        if (fc.getDialogType() == JFileChooser.OPEN_DIALOG ||

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

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


From psadhukhan at openjdk.org  Wed Jan 11 07:27:11 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 11 Jan 2023 07:27:11 GMT
Subject: RFR: 8299309: Test
 "java/awt/Dialog/ModalDialogTest/ModalDialogTest.java" fails because new frame
 was not displayed when "New Frame" button was clicked
In-Reply-To: <br2h0HuFz8KcbRSyzPJeqj-_gLWwYf5yn4Wi17z76tk=.8ec014f8-a081-4cf1-98f8-fafe20d83c5c@github.com>
References: <br2h0HuFz8KcbRSyzPJeqj-_gLWwYf5yn4Wi17z76tk=.8ec014f8-a081-4cf1-98f8-fafe20d83c5c@github.com>
Message-ID: <WbScpkZuYYzVwEQRVwSNQ9I-MCf1NOIX2byZntPRzds=.8cdbe01a-c779-450e-b660-1f7b5992e6e5@github.com>

On Thu, 5 Jan 2023 05:26:26 GMT, Tejesh R <tr at openjdk.org> wrote:

> Windows count check was added as part of [JDK-8290469](https://bugs.openjdk.org/browse/JDK-8290469) fix, to avoid window positional shift which happens during application startup. The condition handled only for windows type of Window and not for Frame/Dialog which is the root cause for the bug. I have updated the condition for other Window types as a fix.

Marked as reviewed by psadhukhan (Reviewer).

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

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


From tr at openjdk.org  Wed Jan 11 07:38:20 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 11 Jan 2023 07:38:20 GMT
Subject: Integrated: 8299309: Test
 "java/awt/Dialog/ModalDialogTest/ModalDialogTest.java" fails because new frame
 was not displayed when "New Frame" button was clicked
In-Reply-To: <br2h0HuFz8KcbRSyzPJeqj-_gLWwYf5yn4Wi17z76tk=.8ec014f8-a081-4cf1-98f8-fafe20d83c5c@github.com>
References: <br2h0HuFz8KcbRSyzPJeqj-_gLWwYf5yn4Wi17z76tk=.8ec014f8-a081-4cf1-98f8-fafe20d83c5c@github.com>
Message-ID: <8sJpu7PtMlLYAMBUmdo19QBXFDgKNikZePm2vXQnJfY=.0b7d1fed-c442-46bb-a97c-f259e02d0ced@github.com>

On Thu, 5 Jan 2023 05:26:26 GMT, Tejesh R <tr at openjdk.org> wrote:

> Windows count check was added as part of [JDK-8290469](https://bugs.openjdk.org/browse/JDK-8290469) fix, to avoid window positional shift which happens during application startup. The condition handled only for windows type of Window and not for Frame/Dialog which is the root cause for the bug. I have updated the condition for other Window types as a fix.

This pull request has now been integrated.

Changeset: 95b102c9
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/95b102c9b1e6a46771f4bea0ca2101c05476172d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8299309: Test "java/awt/Dialog/ModalDialogTest/ModalDialogTest.java" fails because new frame was not displayed when "New Frame" button was clicked

Reviewed-by: honkar, dnguyen, psadhukhan

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

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


From serb at openjdk.org  Wed Jan 11 07:44:14 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Jan 2023 07:44:14 GMT
Subject: RFR: 8284825:
 sun/java2d/DirectX/MultiPaintEventTest/MultiPaintEventTest.java failed with
 "RuntimeException: Processed unnecessary paint()."
In-Reply-To: <UfqXn2MVVu2jeJkbc4UP-OG8OCJXfE8_HPEwa5Qt0DU=.61ec7cea-1619-4a47-aa4f-b35af6f57be2@github.com>
References: <UfqXn2MVVu2jeJkbc4UP-OG8OCJXfE8_HPEwa5Qt0DU=.61ec7cea-1619-4a47-aa4f-b35af6f57be2@github.com>
Message-ID: <G1jyZHc4s0LsDITUPxuDH-5aA43ECJ-GJWQ75omw8ZI=.79c3fb2f-873b-47d5-8aff-e33a91ab78ef@github.com>

On Wed, 11 Jan 2023 05:44:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Now that [commit](https://git.openjdk.org/jdk/commit/4072412c1fd1e28febff71c6b37a9813f22bdc4b)
> has reverted [JDK-8275715](https://bugs.openjdk.org/browse/JDK-8275715)  along with the test
> there's no need of keeping the non-existent test problemlisted, which we can remove

Marked as reviewed by serb (Reviewer).

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

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


From abhiscxk at openjdk.org  Wed Jan 11 07:46:14 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 11 Jan 2023 07:46:14 GMT
Subject: [jdk20] Integrated: 8299227: host `exif.org` not found in link in doc
 comment
In-Reply-To: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
References: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
Message-ID: <QLllkRqYzazTJwqUYsxMkk8L2WXhp97tmYW9lr9-yVw=.806836be-c531-4ec0-a161-ae3605c3a48e@github.com>

On Thu, 22 Dec 2022 21:32:05 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Reported broken links are updated accordingly.

This pull request has now been integrated.

Changeset: 0abb87a4
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Committer: Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/0abb87a488e99cdbc418e14411a6bbf7a3f28079
Stats:     14 lines in 3 files changed: 4 ins; 0 del; 10 mod

8299227: host `exif.org` not found in link in doc comment

Reviewed-by: prr, serb

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

PR: https://git.openjdk.org/jdk20/pull/74


From serb at openjdk.org  Wed Jan 11 07:55:12 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Jan 2023 07:55:12 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
Message-ID: <mNZ-1gX-Q7lQ9jE5CyMcLXPkonw23E21s-Z2NNi1_lo=.bbe0fc1c-b048-4302-b240-0d020a78268f@github.com>

On Fri, 6 Jan 2023 04:42:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems Synth has two cases of updateStyle() where its argument is not passed to the getContext() call. It seems to be an oversight as in other Synth classes, the component argument passed to updateStyle is being passed to getContext().
> 
> CI tests are ok with this change and there is no new regeression with CI tests run in NimbusL&F by default..

You can trigger the property listener method and pass some "separate" component as a source, before your change the context will be created for the list, after the change the context will be created for the "event.source". Is it possible to change the current UI style based on the context from the separate component?

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

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


From tr at openjdk.org  Wed Jan 11 08:04:13 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 11 Jan 2023 08:04:13 GMT
Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java
 fails with AssertionError [v2]
In-Reply-To: <S_M1SbhJdSLe3AnmmmoY3KtQ28K6zKI5yBs_r8TpYIs=.35f706d3-2120-4043-9d89-ee78ebda4b3f@github.com>
References: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
 <S_M1SbhJdSLe3AnmmmoY3KtQ28K6zKI5yBs_r8TpYIs=.35f706d3-2120-4043-9d89-ee78ebda4b3f@github.com>
Message-ID: <xFqat2W8jXbEW-wt73c8QSRviaJL-QR7xZD63HpgqhU=.ebe951ef-654d-46da-a0eb-a9e3f44c5eab@github.com>

On Fri, 6 Jan 2023 22:02:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This assertion happens when we try to build the path linked by the shortcut file when part of that path is not accessible. For example, if the ".lnk" file is pointed to the "windows-update. settings" inside the "Internet.settings". 
>> 
>> After the change, we will skip the target of the link if any part of the path to the target is not a folder and is not traversable in JFileChooser.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Looks Good to me.

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

Marked as reviewed by tr (Committer).

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


From psadhukhan at openjdk.org  Wed Jan 11 08:10:17 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 11 Jan 2023 08:10:17 GMT
Subject: Integrated: 8284825:
 sun/java2d/DirectX/MultiPaintEventTest/MultiPaintEventTest.java failed with
 "RuntimeException: Processed unnecessary paint()."
In-Reply-To: <UfqXn2MVVu2jeJkbc4UP-OG8OCJXfE8_HPEwa5Qt0DU=.61ec7cea-1619-4a47-aa4f-b35af6f57be2@github.com>
References: <UfqXn2MVVu2jeJkbc4UP-OG8OCJXfE8_HPEwa5Qt0DU=.61ec7cea-1619-4a47-aa4f-b35af6f57be2@github.com>
Message-ID: <KFbOsZXfdCg-51zOGG42dp2o_G9jXfuTTRP_KVR1KME=.2899c815-43fc-4ccf-8d82-19ebb0c104da@github.com>

On Wed, 11 Jan 2023 05:44:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Now that [commit](https://git.openjdk.org/jdk/commit/4072412c1fd1e28febff71c6b37a9813f22bdc4b)
> has reverted [JDK-8275715](https://bugs.openjdk.org/browse/JDK-8275715)  along with the test
> there's no need of keeping the non-existent test problemlisted, which we can remove

This pull request has now been integrated.

Changeset: ef32fdb8
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef32fdb8cc9681cf7f1b7a40e3c5a3239491ec75
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8284825: sun/java2d/DirectX/MultiPaintEventTest/MultiPaintEventTest.java failed with "RuntimeException: Processed unnecessary paint()."

Reviewed-by: serb

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

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


From tr at openjdk.org  Wed Jan 11 10:29:52 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 11 Jan 2023 10:29:52 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v5]
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <9ybbK-vje2WkFfoDXlLU1jJJc3QKi5VTf57_KKVfQIk=.50851a17-ad46-476b-87eb-16734fdea50c@github.com>

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

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

  Spacing updation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11901/files
  - new: https://git.openjdk.org/jdk/pull/11901/files/dbbc68cb..ede54bad

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

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

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


From psadhukhan at openjdk.org  Wed Jan 11 11:24:21 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 11 Jan 2023 11:24:21 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground' is
 finished
Message-ID: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>

SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
but there's no mechanism in place to honor that claim.
The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
also says the state should be DONE after doInBackground() returns which is also not done.

Modified the code to honour the specification.

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

Commit messages:
 - Fix
 - Fix
 - 8081474: SwingWorker calls 'done' before the 'doInBackground' is finished

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

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


From psadhukhan at openjdk.org  Wed Jan 11 11:33:43 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 11 Jan 2023 11:33:43 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v2]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <2ZHOyW1znkGexCRUDlPgJdLdKeIQeKwGSZIrWRNtW5s=.0fed5796-165b-45fe-89c7-14e211617835@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

  Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/ae0af869..70e4a8ce

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

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

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


From mcimadamore at openjdk.org  Wed Jan 11 14:15:18 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jan 2023 14:15:18 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
Message-ID: <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>

On Wed, 11 Jan 2023 00:22:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> So, if the code was be like this:
>> 
>> 
>> ThisEscapeLoop ref11 = this;
>> ThisEscapeLoop ref12 = null;
>> ThisEscapeLoop ref13 = null;
>> ThisEscapeLoop ref14 = null;
>> for (int i = 0; i < 100; i++) {
>>     ref14 = ref13;
>>     ref13 = ref12;
>>     ref12 = ref11;
>>     ThisEscapeLoop ref21 = ref14;
>>     ThisEscapeLoop ref22 = null;
>>     ThisEscapeLoop ref23 = null;
>>     ThisEscapeLoop ref24 = null;
>>     for (int i = 0; i < 100; i++) {
>>         ref24 = ref23;
>>         ref23 = ref22;
>>         ref22 = ref21;
>>         if (ref24 != null)
>>             ref24.mightLeak();
>>     }
>> }
>> 
>> 
>> Then it would take not 3 iterations but 3 * 3 to figure out that it is a potential leak?
>
> Actually I think it would take 1 + 1 + 3 iterations.
> 
> During the first two iterations of the outer loop, nothing changes after the first go round of the inner loop - i.e., the total set of possible references in existence does not change, because all of the assignments in the inner loop won't involve any 'this' references.
> 
> It's only the during the third iteration of the outer loop that any 'this' references seep into any of the variables seen by the inner loop. Then it will take 3 cycles for the reference set to converge again.
> 
> However, this is not to say that there aren't some pathological examples out there. I guess the question is could they exist in "normal" code.

True - probably 3 * 3 can be achieved if this:


    ThisEscapeLoop ref21 = ref14;

Is replaced with   


    ThisEscapeLoop ref21 = this;


In which case the inner loop won't converge immediately (as it will have to propagate from ref21 to ref22 to ref23 to ref24).

I guess what I'm uncomfortable with is that we have effectively unbounded computation here (especially when we also consider the fact that the analysis "follows" method bodies as well, if they are found in the same compilation unit).

I suggest one experiment where you:
1. downgrade the warnings to notes (so that they won't make the JDK build fail)
2. enable this Lint everywhere
3. compare JDK `clean images` time w/ and w/o the Lint

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

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


From mcimadamore at openjdk.org  Wed Jan 11 16:02:16 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jan 2023 16:02:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
Message-ID: <jkX4MXwtRWUOJZzkkkg1OpQtZkQ8eVvJgYq0mMze9P4=.edf63f99-3155-4f1a-bb63-d28d88dd0698@github.com>

On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use the more appropriate Type comparison method Types.isSameType().
>  - Add some more comments to clarify how the analysis works.

More questions. Let's say that we only tracked escaping of direct references to `this`. Do you have any sense of how many "less" warnings would be reported in real code (e.g. JDK) ? What I mean by this - let's say that we don't care about tracking _where_ `this` ends up going exactly (e.g. if it's aliased by another variable) - and perhaps also let's say we don't care about inspecting the method to which `this` is leaked too closely - e.g. we treat any early escape of `this` as a possible issue. Of course you could construct examples (like your tests) in which such a simplistic analysis would be defeated. What I'm interested in though is what incremental improvement is brought by the more complex analysis you have in this PR?

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

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


From mcimadamore at openjdk.org  Wed Jan 11 16:17:16 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jan 2023 16:17:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
Message-ID: <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>

On Wed, 11 Jan 2023 14:12:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Actually I think it would take 1 + 1 + 3 iterations.
>> 
>> During the first two iterations of the outer loop, nothing changes after the first go round of the inner loop - i.e., the total set of possible references in existence does not change, because all of the assignments in the inner loop won't involve any 'this' references.
>> 
>> It's only the during the third iteration of the outer loop that any 'this' references seep into any of the variables seen by the inner loop. Then it will take 3 cycles for the reference set to converge again.
>> 
>> However, this is not to say that there aren't some pathological examples out there. I guess the question is could they exist in "normal" code.
>
> True - probably 3 * 3 can be achieved if this:
> 
> 
>     ThisEscapeLoop ref21 = ref14;
> 
> Is replaced with   
> 
> 
>     ThisEscapeLoop ref21 = this;
> 
> 
> In which case the inner loop won't converge immediately (as it will have to propagate from ref21 to ref22 to ref23 to ref24).
> 
> I guess what I'm uncomfortable with is that we have effectively unbounded computation here (especially when we also consider the fact that the analysis "follows" method bodies as well, if they are found in the same compilation unit).
> 
> I suggest one experiment where you:
> 1. downgrade the warnings to notes (so that they won't make the JDK build fail)
> 2. enable this Lint everywhere
> 3. compare JDK `clean images` time w/ and w/o the Lint

Also, looking at the loop test more closely, it seems to me that what the compiler needs to do is to prove that there can be possible paths by which a `this` can land into ref4.

If we build a graph of all the assignments, we get:

ref4 <- ref3 <- ref2 <- ref1 <- this

So, if we ask "can ref4 possibly contain `this`?" we could "walk" the variable dependencies backwards and discover that, yes, there exist a possible path in which `this` would get there.

Now, of course without a loop this can never be a real issue (since you can never send a `this` fully down the chain) - but again, this is a question of how much effort should be spend to handle false negatives in what look like a pathological case.

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

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


From jwilhelm at openjdk.org  Wed Jan 11 17:56:07 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 11 Jan 2023 17:56:07 GMT
Subject: RFR: Merge jdk20
Message-ID: <Yn_7_yZ9O05eJRGO3U4IGvq2a8RDpOZwH_QCIDz8fMc=.b50b927a-bc2f-44ec-972b-658ab79a45ed@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8299862: OfAddress setter should disallow heap segments
 - 8299849: Revert JDK-8294461: wrong effectively final determination by javac
 - 8299227: host `exif.org` not found in link in doc comment
 - 8299715: IR test: VectorGatherScatterTest.java fails with SVE randomly
 - 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop
 - 8299733: AArch64: "unexpected literal addressing mode" assertion failure with -XX:+PrintC1Statistics
 - 8299693: Change to Xcode12.4+1.1 devkit for building on macOS at Oracle

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11952&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11952&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11952/files
  Stats: 98 lines in 16 files changed: 53 ins; 19 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/11952.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11952/head:pull/11952

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


From duke at openjdk.org  Wed Jan 11 18:47:14 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 18:47:14 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
Message-ID: <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>

On Wed, 11 Jan 2023 16:14:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> True - probably 3 * 3 can be achieved if this:
>> 
>> 
>>     ThisEscapeLoop ref21 = ref14;
>> 
>> Is replaced with   
>> 
>> 
>>     ThisEscapeLoop ref21 = this;
>> 
>> 
>> In which case the inner loop won't converge immediately (as it will have to propagate from ref21 to ref22 to ref23 to ref24).
>> 
>> I guess what I'm uncomfortable with is that we have effectively unbounded computation here (especially when we also consider the fact that the analysis "follows" method bodies as well, if they are found in the same compilation unit).
>> 
>> I suggest one experiment where you:
>> 1. downgrade the warnings to notes (so that they won't make the JDK build fail)
>> 2. enable this Lint everywhere
>> 3. compare JDK `clean images` time w/ and w/o the Lint
>
> Also, looking at the loop test more closely, it seems to me that what the compiler needs to do is to prove that there can be possible paths by which a `this` can land into ref4.
> 
> If we build a graph of all the assignments, we get:
> 
> ref4 <- ref3 <- ref2 <- ref1 <- this
> 
> So, if we ask "can ref4 possibly contain `this`?" we could "walk" the variable dependencies backwards and discover that, yes, there exist a possible path in which `this` would get there.
> 
> Now, of course without a loop this can never be a real issue (since you can never send a `this` fully down the chain) - but again, this is a question of how much effort should be spend to handle false negatives in what look like a pathological case.

Good idea. Looks like the difference is in the noise, at least on my Macbook:

Builds of master (jdk-21+3-69-gc6588d5bb3f)
==================================

Build times:

    real	2m24.650s
    user	13m46.727s
    sys	2m33.554s

    real	2m27.224s
    user	13m43.464s
    sys	2m37.251s

    real	2m26.658s
    user	13m42.578s
    sys	2m36.133s

Builds of ThisEscape (jdk-21+3-125-g6e96a7d76f8)
==================================

Modifications:

    - Reverted files in the make/ subdirectory to enable warning
    - Commented out lines 363-382 in ThisEscapeAnalyzer.java
      so no warnings are actually reported

Build times:

    real	2m25.912s
    user	13m45.860s
    sys	2m32.741s

    real	2m27.213s
    user	13m44.830s
    sys	2m36.596s

    real	2m25.756s
    user	13m42.889s
    sys	2m35.659s

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

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


From mvs at openjdk.org  Wed Jan 11 18:48:21 2023
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 11 Jan 2023 18:48:21 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v3]
In-Reply-To: <WW7u_sdpAbc2xxsgibzRI1T31thA5FIaN57l6ghADRs=.99459089-fbd7-46a3-9cc8-bae112901a05@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
 <bCjlBewHa7tXT7d5mtQmLxcMbGDApK2ZvtN3RSnCpCM=.fb8b14dd-1585-44d7-a153-9ec72ac20670@github.com>
 <bxzrjMDW_3h7vTjV8AL5ziDpF1fsujnTd1yojkhadbs=.f72d0e06-08b8-4cbc-9953-efe05647b20b@github.com>
 <hzBu8ey7PmsXzX0DwJWwGOdKnIiONiGGt4wmFCWtRoY=.fcc782d0-f7dc-4f6e-aaf5-70a1b20f2229@github.com>
 <WW7u_sdpAbc2xxsgibzRI1T31thA5FIaN57l6ghADRs=.99459089-fbd7-46a3-9cc8-bae112901a05@github.com>
Message-ID: <A6VrOXbNKLv16NKU7ammyYz8FSxfaDlIFWtZ0ylkKqk=.1c17e505-2b34-4b0b-9c96-f10b907acc88@github.com>

On Tue, 10 Jan 2023 21:35:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Replaced robot.waitForIdle with robot.delay(200). I will check the possibility of raising a new bug.
>
> Since no one expected for `robot.waitForIdle` to make the test so slow here, I suggest submitting a bug for evaluation. You have a working test case for this. The frame doesn't need to move across the screen.

I raised a new bug for this issue JDK-8299937

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

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


From aivanov at openjdk.org  Wed Jan 11 19:08:33 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 11 Jan 2023 19:08:33 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v3]
In-Reply-To: <wuNA2dNT--n0ntTqRpNYiY-AZPgTqg4BbJR0cHAzcsg=.e65f88cb-05c5-4b67-8b70-8a853f508bca@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
 <wuNA2dNT--n0ntTqRpNYiY-AZPgTqg4BbJR0cHAzcsg=.e65f88cb-05c5-4b67-8b70-8a853f508bca@github.com>
Message-ID: <ONNHgUS_apZH4xXCY27dqbuG5Ofslp6HxZh74taVq_8=.07713874-6ddd-43b1-b0a7-23b8f1aa9a30@github.com>

On Wed, 11 Jan 2023 06:14:41 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
>> 
>> Fix:
>> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
>> Also updated the screen capture code, made frame undecorated, added some prints for better debugging.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Refactoring, formatting corrections, frame.setVisible(true) position changed

Marked as reviewed by aivanov (Reviewer).

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

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


From duke at openjdk.org  Wed Jan 11 19:13:16 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 19:13:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
Message-ID: <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>

On Wed, 11 Jan 2023 18:44:20 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Also, looking at the loop test more closely, it seems to me that what the compiler needs to do is to prove that there can be possible paths by which a `this` can land into ref4.
>> 
>> If we build a graph of all the assignments, we get:
>> 
>> ref4 <- ref3 <- ref2 <- ref1 <- this
>> 
>> So, if we ask "can ref4 possibly contain `this`?" we could "walk" the variable dependencies backwards and discover that, yes, there exist a possible path in which `this` would get there.
>> 
>> Now, of course without a loop this can never be a real issue (since you can never send a `this` fully down the chain) - but again, this is a question of how much effort should be spend to handle false negatives in what look like a pathological case.
>
> Good idea. Looks like the difference is in the noise, at least on my Macbook:
> 
> Builds of master (jdk-21+3-69-gc6588d5bb3f)
> ==================================
> 
> Build times:
> 
>     real	2m24.650s
>     user	13m46.727s
>     sys	2m33.554s
> 
>     real	2m27.224s
>     user	13m43.464s
>     sys	2m37.251s
> 
>     real	2m26.658s
>     user	13m42.578s
>     sys	2m36.133s
> 
> Builds of ThisEscape (jdk-21+3-125-g6e96a7d76f8)
> ==================================
> 
> Modifications:
> 
>     - Reverted files in the make/ subdirectory to enable warning
>     - Commented out lines 363-382 in ThisEscapeAnalyzer.java
>       so no warnings are actually reported
> 
> Build times:
> 
>     real	2m25.912s
>     user	13m45.860s
>     sys	2m32.741s
> 
>     real	2m27.213s
>     user	13m44.830s
>     sys	2m36.596s
> 
>     real	2m25.756s
>     user	13m42.889s
>     sys	2m35.659s

Regarding the assignment graph approach, I think that would work if the references are bouncing around strictly between variables, but what if the chain includes any of the more complicated stuff that is currently being tracked, such as various Java expressions, method invocations, conditionals, etc.?

Consider this example:

public class ThisEscapeLoop { 
    
    public ThisEscapeLoop() { 
        ThisEscapeLoop ref1 = this;
        ThisEscapeLoop ref2 = null;
        ThisEscapeLoop ref3 = null;
        ThisEscapeLoop ref4 = null;
        for (int i = 0; i < 100; i++) {
            ref4 = this.returnMe(ref3);
            ref3 = ref2;
            ref2 = ref1;
            if (ref4 != null)
                ref4.mightLeak();
        }
    }

    public <T> T returnMe(T x) {
        return x;
    }

    public void mightLeak() {
    }
}

If you are only looking at variable assignments with values that are other variables, then the chain "breaks" when `ref4` is assigned indirectly via `returnMe()`, and you miss the leak.

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

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


From duke at openjdk.org  Wed Jan 11 19:47:16 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 19:47:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <jkX4MXwtRWUOJZzkkkg1OpQtZkQ8eVvJgYq0mMze9P4=.edf63f99-3155-4f1a-bb63-d28d88dd0698@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <jkX4MXwtRWUOJZzkkkg1OpQtZkQ8eVvJgYq0mMze9P4=.edf63f99-3155-4f1a-bb63-d28d88dd0698@github.com>
Message-ID: <tjWnyDfAJ3jkcI_faWMqZLwpffQGr06RXG2OGnlp2cA=.754cd23a-1782-4d80-b32e-a27fd23bba30@github.com>

On Wed, 11 Jan 2023 15:59:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> What I'm interested in though is what incremental improvement is brought by the more complex analysis you have in this PR?

It's a good question. Here are some thoughts...

One meta-goal is that this analysis be conservative. In other words, if your code does NOT generate any warnings, then you should feel confident that there is a high probability that there are no leaks.

This is analogous to how you can be confident that you won't get any `ClassCastExceptions` at runtime if your code doesn't generate any `unchecked` warnings at compile time.

I think this point is generally agreed upon.

If so, then we would want?any simpler analysis to err on the side of generating more false positives rather than more false negatives.

Assuming that, then the question comes down to a trade-off between code complexity vs. rate of false positives.

>From my casual looking over the JDK, the current algorithm generates very few false positives - almost all of the warnings represent actual leaks (I'd be interested in any false positives you do see).
 
(Of course, an irony is that most of these leaks have no real-world effect. For example package-private classes in the JDK (a) have already been debugged long ago, so any intra-package bugs due to 'this' escapes have already been fixed; and (b) are unlikely to be subclassed by anyone. And the ones that have a real-world effect (e.g., `HashSet(Collection)`) can't be fixed because of backward compatibility concerns. So this warning is most useful when writing new code.)

So the current code is clearly "complex enough" already. FWIW that's ~975 lines of code excluding blank lines and comments.

Now to answer your question about a theoretical simpler analysis:

> let's say that we don't care about tracking where `this` ends up going exactly (e.g. if it's aliased by another variable) - and perhaps also let's say we don't care about inspecting the method to which `this` is leaked too closely - e.g. we treat any early escape of this as a possible issue.

I'm not sure I completely understand the semantics. But are you saying that if a constructor invokes a private or static method, then this simpler analysis would always declare a leak?

If that's the case then I think there are a lot of new false positives, because this is common in constructors.

I would then worry that if we dilute the warnings with a bunch of new false positives people are just going to get discouraged and turn the warning off completely.

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

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


From dnguyen at openjdk.org  Wed Jan 11 19:53:21 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 11 Jan 2023 19:53:21 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v3]
In-Reply-To: <wuNA2dNT--n0ntTqRpNYiY-AZPgTqg4BbJR0cHAzcsg=.e65f88cb-05c5-4b67-8b70-8a853f508bca@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
 <wuNA2dNT--n0ntTqRpNYiY-AZPgTqg4BbJR0cHAzcsg=.e65f88cb-05c5-4b67-8b70-8a853f508bca@github.com>
Message-ID: <hX4jvPPvgeEX7UPDfRANsBrULNUrT7GhnBTh0OpKYEk=.bc71b362-61a3-4666-acf1-aedec55b8bd3@github.com>

On Wed, 11 Jan 2023 06:14:41 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
>> 
>> Fix:
>> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
>> Also updated the screen capture code, made frame undecorated, added some prints for better debugging.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Refactoring, formatting corrections, frame.setVisible(true) position changed

Looks good. My main concern was the really long delay from waitForIdle. Glad a bug was raised for that and all of the minor issues were addressed.

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

Marked as reviewed by dnguyen (Author).

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


From aivanov at openjdk.org  Wed Jan 11 20:09:25 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 11 Jan 2023 20:09:25 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v5]
In-Reply-To: <9ybbK-vje2WkFfoDXlLU1jJJc3QKi5VTf57_KKVfQIk=.50851a17-ad46-476b-87eb-16734fdea50c@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <9ybbK-vje2WkFfoDXlLU1jJJc3QKi5VTf57_KKVfQIk=.50851a17-ad46-476b-87eb-16734fdea50c@github.com>
Message-ID: <PEXwLuJYsSJxMmbGYQEMDTY4A_ON_xkpG5ckMxj6Sjg=.efa1304d-f310-4431-853a-2c33e9cbd8bd@github.com>

On Wed, 11 Jan 2023 10:29:52 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spacing updation

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 586:

> 584:         }
> 585: 
> 586:         if (fc.getDialogType() == JFileChooser.OPEN_DIALOG ||

Since you added spaces after `if`, you should probably update the `if` above too.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 587:

> 585: 
> 586:         if (fc.getDialogType() == JFileChooser.OPEN_DIALOG ||
> 587:                 fc.getDialogType() == JFileChooser.CUSTOM_DIALOG) {

Suggestion:

        if (fc.getDialogType() == JFileChooser.OPEN_DIALOG
                || fc.getDialogType() == JFileChooser.CUSTOM_DIALOG) {

I prefer it this way: wrapping before the operator makes it clear that it's a continuation line.

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 62:

> 60:     private CustomApproveButtonTest(String lookAndFeel) {
> 61:         System.out.println("Testing Look & Feel : " + lookAndFeel);
> 62:         frame = new JFrame("CustomApproveButtonTest");

You should create the frame after you set the Look-and-Feel.

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 69:

> 67:             throw new RuntimeException("Failed to set " + lookAndFeel +
> 68:                     " LookAndFeel. Error : " + e);
> 69:         }

You should probably quietly ignore the Look-and-Feel if `UnsupportedLookAndFeelException` is thrown.

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 75:

> 73:         frame.add(fileChooser);
> 74:         frame.setVisible(true);
> 75:         frame.pack();

Suggestion:

        frame.pack();
        frame.setVisible(true);


Usually, `pack()` goes before `setVisible` to ensure the size is calculated before the frame is made visible so that no flickering occurs because the size gets updated.

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 83:

> 81:             return;
> 82:         }
> 83:         if (customApproveButton.getText() == null) {

Now that you test that the text on the Approve is non-null only, why is Aqua L&F excluded?

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 96:

> 94:         if (frame != null) {
> 95:             frame.dispose();
> 96:         }

The easiest way to avoid duplicate code for disposing of the frame is to use `try`-`finally` block which is commonly used in tests:


// Set Look-and-Feel
try {
    frame = new JFrame("title");
    // The rest of the test code

    // You can throw any exception to fail the test,
    // the finally block below will still dispose of the frame.
} finally {
    if (frame != null) {
        frame.dispose();
    }
}

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

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


From darcy at openjdk.org  Wed Jan 11 20:51:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 11 Jan 2023 20:51:17 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
Message-ID: <xJ6AcFTseO0APz3UiElSegTmB9XAPdncXTpLvBvDzSk=.3f25a420-18e5-4500-8180-3a09e12b8a75@github.com>

On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use the more appropriate Type comparison method Types.isSameType().
>  - Add some more comments to clarify how the analysis works.

Per the discussion in "Effective Java" on calling overridable methods in a constructor, future refinements of the check under review here could be extended to examine the bodies of clone and readObject methods.

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

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


From aivanov at openjdk.org  Wed Jan 11 20:54:22 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 11 Jan 2023 20:54:22 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v5]
In-Reply-To: <LQryZvfoeTq3YYiQzSE6SaDiDgMnSRFnaPxNLDtPf9U=.d7efc83c-90d8-44f6-86c0-4a3244787f80@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <LQryZvfoeTq3YYiQzSE6SaDiDgMnSRFnaPxNLDtPf9U=.d7efc83c-90d8-44f6-86c0-4a3244787f80@github.com>
Message-ID: <aN-c2EJcfzqUL0ld54R6GOccHEZ4fA6dsnyFpwclm7c=.b40b7a89-213e-4c78-bd18-f0876135c937@github.com>

On Thu, 5 Jan 2023 19:03:17 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as functional parameter to the method.  
>> 
>> Following are the usual steps for any border scaling -
>> 
>> - Resetting transform.
>> - Calculating new width, height, x & y-translations.
>> - Perform the required border rendering.
>> - And at the end restore the previous transform.
>> 
>> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
>> 
>> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
>> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
>> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
>> 
>> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved strokeWidth logic to individual classes

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 46:

> 44: import sun.awt.SunToolkit;
> 45: 
> 46: 

One line is enough between regular imports and static ones.

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 176:

> 174:             // or if scale=1, skip resetting the transform
> 175:             resetTransform = ((at.getShearX() == 0) && (at.getShearY() == 0)) &&
> 176:                     ((at.getScaleX() > 1) || (at.getScaleY() > 1));

Suggestion:

            resetTransform = ((at.getShearX() == 0) && (at.getShearY() == 0))
                    && ((at.getScaleX() > 1) || (at.getScaleY() > 1));

The operator at the start of a line makes it clear it's an continuation line. This style was advocated in the Java Style Guidelines.

I don't insist though.

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 196:

> 194: 
> 195:         // Step 2: Call respective paintBorder with transformed values
> 196:         painter.paintUnscaledBorder(c, g, x, y, width, height, scaleFactor);

Why do you pass the original `x` and `y`? They must be 0 inside `paintUnscaledBorder`. As such, `x` and `y` parameters can be dropped.

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 203:

> 201:             Graphics2D g2d = (Graphics2D) g;
> 202:             g2d.setTransform(at);
> 203:             g2d.setStroke(oldStk);

The stroke should always be restored even if the transform wasn't reset. Or it should be done in the implementation of `paintUnscaledBorder`.

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 156:

> 154: 
> 155:     private void paintUnscaledBorder(Component c, Graphics g, int x, int y,
> 156:                                     int w, int h, double scaleFactor) {

Suggestion:

    private void paintUnscaledBorder(Component c, Graphics g, int x, int y,
                                     int w, int h, double scaleFactor) {

One more space is missing to align.

src/java.desktop/share/classes/javax/swing/border/LineBorder.java line 27:

> 25: package javax.swing.border;
> 26: 
> 27: import com.sun.java.swing.SwingUtilities3;

Let's be consistent: it should go after `java.*` and `javax.*` packages.

Either there should be a blank line before `com.*` or `sun.*` imports or there shouldn't be.

src/java.desktop/share/classes/javax/swing/border/LineBorder.java line 155:

> 153:             int offs = this.thickness * (int) scaleFactor;
> 154:             Color oldColor = g.getColor();
> 155:             g.setColor(this.lineColor);

I'd rather leave the lines unchanged. I mean `getColor` and `setColor` could still use `g2d` as before.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 69:

> 67: import static sun.java2d.pipe.Region.clipRound;
> 68: 
> 69: 

It's probably unnecessary.

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

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


From mcimadamore at openjdk.org  Wed Jan 11 21:48:18 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jan 2023 21:48:18 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
Message-ID: <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboIFFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>

On Wed, 11 Jan 2023 19:10:04 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Good idea. Looks like the difference is in the noise, at least on my Macbook:
>> 
>> Builds of master (jdk-21+3-69-gc6588d5bb3f)
>> ==================================
>> 
>> Build times:
>> 
>>     real	2m24.650s
>>     user	13m46.727s
>>     sys	2m33.554s
>> 
>>     real	2m27.224s
>>     user	13m43.464s
>>     sys	2m37.251s
>> 
>>     real	2m26.658s
>>     user	13m42.578s
>>     sys	2m36.133s
>> 
>> Builds of ThisEscape (jdk-21+3-125-g6e96a7d76f8)
>> ==================================
>> 
>> Modifications:
>> 
>>     - Reverted files in the make/ subdirectory to enable warning
>>     - Commented out lines 363-382 in ThisEscapeAnalyzer.java
>>       so no warnings are actually reported
>> 
>> Build times:
>> 
>>     real	2m25.912s
>>     user	13m45.860s
>>     sys	2m32.741s
>> 
>>     real	2m27.213s
>>     user	13m44.830s
>>     sys	2m36.596s
>> 
>>     real	2m25.756s
>>     user	13m42.889s
>>     sys	2m35.659s
>
> Regarding the assignment graph approach, I think that would work if the references are bouncing around strictly between variables, but what if the chain includes any of the more complicated stuff that is currently being tracked, such as various Java expressions, method invocations, conditionals, etc.?
> 
> Consider this example:
> 
> public class ThisEscapeLoop { 
>     
>     public ThisEscapeLoop() { 
>         ThisEscapeLoop ref1 = this;
>         ThisEscapeLoop ref2 = null;
>         ThisEscapeLoop ref3 = null;
>         ThisEscapeLoop ref4 = null;
>         for (int i = 0; i < 100; i++) {
>             ref4 = this.returnMe(ref3);
>             ref3 = ref2;
>             ref2 = ref1;
>             if (ref4 != null)
>                 ref4.mightLeak();
>         }
>     }
> 
>     public <T> T returnMe(T x) {
>         return x;
>     }
> 
>     public void mightLeak() {
>     }
> }
> 
> If you are only looking at variable assignments with values that are other variables, then the chain "breaks" when `ref4` is assigned indirectly via `returnMe()`, and you miss the leak.

> Good idea. Looks like the difference is in the noise, at least on my Macbook:
> 
> ```
> Builds of master (jdk-21+3-69-gc6588d5bb3f)
> ==================================
> 
> Build times:
> 
>     real	2m24.650s
>     user	13m46.727s
>     sys	2m33.554s
> 
>     real	2m27.224s
>     user	13m43.464s
>     sys	2m37.251s
> 
>     real	2m26.658s
>     user	13m42.578s
>     sys	2m36.133s
> 
> Builds of ThisEscape (jdk-21+3-125-g6e96a7d76f8)
> ==================================
> 
> Modifications:
> 
>     - Reverted files in the make/ subdirectory to enable warning
>     - Commented out lines 363-382 in ThisEscapeAnalyzer.java
>       so no warnings are actually reported
> 
> Build times:
> 
>     real	2m25.912s
>     user	13m45.860s
>     sys	2m32.741s
> 
>     real	2m27.213s
>     user	13m44.830s
>     sys	2m36.596s
> 
>     real	2m25.756s
>     user	13m42.889s
>     sys	2m35.659s
> ```

Thanks for trying it out - good to know that build time isn't affected.

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

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


From mcimadamore at openjdk.org  Wed Jan 11 21:54:17 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jan 2023 21:54:17 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboIFFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
Message-ID: <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>

On Wed, 11 Jan 2023 21:45:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Regarding the assignment graph approach, I think that would work if the references are bouncing around strictly between variables, but what if the chain includes any of the more complicated stuff that is currently being tracked, such as various Java expressions, method invocations, conditionals, etc.?
>> 
>> Consider this example:
>> 
>> public class ThisEscapeLoop { 
>>     
>>     public ThisEscapeLoop() { 
>>         ThisEscapeLoop ref1 = this;
>>         ThisEscapeLoop ref2 = null;
>>         ThisEscapeLoop ref3 = null;
>>         ThisEscapeLoop ref4 = null;
>>         for (int i = 0; i < 100; i++) {
>>             ref4 = this.returnMe(ref3);
>>             ref3 = ref2;
>>             ref2 = ref1;
>>             if (ref4 != null)
>>                 ref4.mightLeak();
>>         }
>>     }
>> 
>>     public <T> T returnMe(T x) {
>>         return x;
>>     }
>> 
>>     public void mightLeak() {
>>     }
>> }
>> 
>> If you are only looking at variable assignments with values that are other variables, then the chain "breaks" when `ref4` is assigned indirectly via `returnMe()`, and you miss the leak.
>
>> Good idea. Looks like the difference is in the noise, at least on my Macbook:
>> 
>> ```
>> Builds of master (jdk-21+3-69-gc6588d5bb3f)
>> ==================================
>> 
>> Build times:
>> 
>>     real	2m24.650s
>>     user	13m46.727s
>>     sys	2m33.554s
>> 
>>     real	2m27.224s
>>     user	13m43.464s
>>     sys	2m37.251s
>> 
>>     real	2m26.658s
>>     user	13m42.578s
>>     sys	2m36.133s
>> 
>> Builds of ThisEscape (jdk-21+3-125-g6e96a7d76f8)
>> ==================================
>> 
>> Modifications:
>> 
>>     - Reverted files in the make/ subdirectory to enable warning
>>     - Commented out lines 363-382 in ThisEscapeAnalyzer.java
>>       so no warnings are actually reported
>> 
>> Build times:
>> 
>>     real	2m25.912s
>>     user	13m45.860s
>>     sys	2m32.741s
>> 
>>     real	2m27.213s
>>     user	13m44.830s
>>     sys	2m36.596s
>> 
>>     real	2m25.756s
>>     user	13m42.889s
>>     sys	2m35.659s
>> ```
> 
> Thanks for trying it out - good to know that build time isn't affected.

> Regarding the assignment graph approach, I think that would work if the references are bouncing around strictly between variables, but what if the chain includes any of the more complicated stuff that is currently being tracked, such as various Java expressions, method invocations, conditionals, etc.?
> 
> Consider this example:
> 
> ```java
> public class ThisEscapeLoop { 
>     
>     public ThisEscapeLoop() { 
>         ThisEscapeLoop ref1 = this;
>         ThisEscapeLoop ref2 = null;
>         ThisEscapeLoop ref3 = null;
>         ThisEscapeLoop ref4 = null;
>         for (int i = 0; i < 100; i++) {
>             ref4 = this.returnMe(ref3);
>             ref3 = ref2;
>             ref2 = ref1;
>             if (ref4 != null)
>                 ref4.mightLeak();
>         }
>     }
> 
>     public <T> T returnMe(T x) {
>         return x;
>     }
> 
>     public void mightLeak() {
>     }
> }
> ```
> 
> If you are only looking at variable assignments with values that are other variables, then the chain "breaks" when `ref4` is assigned indirectly via `returnMe()`, and you miss the leak.

So, in this example though you are calling an instance method before the object is initialized, which would seem to me like a leak (leaving aside heroics to try and chase the method body and see what the body of the method actually does).

And, if the method is static, same story - you are passing `ref3` somewhere else, and `ref3` potentially contains `this`. 

While I know that this is not perfect, and bound to generate false positives, I get the spirit of my question is, really: is there a (much) simpler scheme we can get away with, which has bounded complexity, and which has the property we care about (which seems to be no false negative). I'm less worried about contrived cases emitting false positives, as it's an optional warning that can be shut down - but I'd like perhaps to move the discussion from trying to detect _precisely_ if the leak happens to try to detect if _potentially_ a leak can happen, and see if there's some simpler analysis that can be used to get there (e.g. one which doesn't require flooding). It's possible that you have already considered all these options and the analysis you have here is the best trade off between complexity and precision - but I'd like to have a better understanding of what the trade offs are, and, more importantly, what happens to real code when we tweak the analysis this or that way (as this is
  a problem where I feel it's easy to get in the land of diminishing returns).

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

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


From jwilhelm at openjdk.org  Wed Jan 11 21:54:24 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 11 Jan 2023 21:54:24 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <Yn_7_yZ9O05eJRGO3U4IGvq2a8RDpOZwH_QCIDz8fMc=.b50b927a-bc2f-44ec-972b-658ab79a45ed@github.com>
References: <Yn_7_yZ9O05eJRGO3U4IGvq2a8RDpOZwH_QCIDz8fMc=.b50b927a-bc2f-44ec-972b-658ab79a45ed@github.com>
Message-ID: <ZpBEyPH4e6fccqJ226CbGMlT7q7QtzeKc5uT3V0suec=.e09e9031-c765-4643-81c1-189b53f16efe@github.com>

On Wed, 11 Jan 2023 17:47:27 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 33f3bd8f
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33f3bd8fadb26a0f99c6a13474f8676639f91c0c
Stats:     98 lines in 16 files changed: 53 ins; 19 del; 26 mod

Merge

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

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


From duke at openjdk.org  Wed Jan 11 22:43:16 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 22:43:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
 <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
Message-ID: <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>

On Wed, 11 Jan 2023 21:51:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> So, in this example though you are calling an instance method before the object is initialized, which would seem to me like a leak

D'oh, you're right. But if you made `returnMe()` static or private then the argument would still hold.

> And, if the method is static, same story - you are passing ref3 somewhere else, and ref3 potentially contains this.

Not true... static methods are safe to "invoke" because they can't be overridden. When the analyzer "invokes" the method, it will see that all it does with its parameter is return it.

In other words, any method (or constructor) in the current compilation unit that can't be overridden is never considered "somewhere else".

> While I know that this is not perfect, and bound to generate false positives, I get the spirit of my question is, really: is there a (much) simpler scheme we can get away with, which has bounded complexity, and which has the property we care about (which seems to be no false negative). I'm less worried about contrived cases emitting false positives, as it's an optional warning that can be shut down - but I'd like perhaps to move the discussion from trying to detect precisely if the leak happens to try to detect if potentially a leak can happen, and see if there's some simpler analysis that can be used to get there (e.g. one which doesn't require flooding). It's possible that you have already considered all these options and the analysis you have here is the best trade off between complexity and precision - but I'd like to have a better understanding of what the trade offs are, and, more importantly, what happens to real code when we tweak the analysis this or that way (as this is a
  problem where I feel it's easy to get in the land of diminishing returns).

I can only report from my own experience. I thought about this a bit and tried a few different things and what I ended up was the best I could come up with in terms of that trade-off. Of course there was a good bit of intuition and SWAG'ing in that and also a lot of thought experiments.

Of course if you have a clever idea for how to do this in a simpler way that achieves basically the same result, I'm all ears :)

But I don't really have an analysis of all the trade-offs. Really, at a certain point I stumbled on what I thought was a fairly straightforward way to achieve a good false negative rate and a very low false positive rate, without a lot of work. And frankly at that point I stopped caring about the question you're asking, although I agree it's certainly interesting from an academic point of view (I'm a practical person).

A lot of my initial ideas were too simple for my taste, because I could easily find real-world false negatives.

An example of "too simple": at first I was not trying to track an outer 'this'. But I found a lot of constructors out there that instantiate nested classes and then do things with them. Without tracking outer 'this' these would all be missed.

To take a random example of that:

public class FileChooserDemo extends JPanel implements ActionListener {
    ...
    public FileChooserDemo() {
        ...
        // create a radio listener to listen to option changes
        OptionListener optionListener = new OptionListener();
 
         // Create options
        openRadioButton = new JRadioButton("Open");
        openRadioButton.setSelected(true);
        openRadioButton.addActionListener(optionListener);  // <- LEAK HERE
        ...
    }

    private class OptionListener implements ActionListener {
        ...
    }
}

That particular leak is (probably) innocuous, but it still qualifies as a leak and should be reported. Note that failing to track an outer 'this' causes false negatives, which are a bigger problem than false positives.

On the flip side, I started out trying to explicitly track field references, but that seemed like more complexity than needed, at least for phase 1, so that was left out.

The "flooding" aspect didn't really worry me because the reference set is "append only" and there is small, finite set of possible references at each scope, so it can't really get that out of hand. Testing indeed shows it's not a problem. By the way recursion also "floods" until convergence, just like looping.

I would have been pleased to find "a much simpler scheme". But the more I thought about those options, the more I came up with easy misses. And after a certain point, it actually became easier to simply "execute" the code by scanning the AST while carrying around a `Set<Ref>` to track possible references. It's really that simple. Instead of trying to be "smart" we just let the code tell us what happens.

Apologies if this is not a very good answer to your question.

In the big picture, the false positive rate is traded-off against code complexity, and we want the best possible trade-off, right?

But how are you defining "complexity"?

If you really mean performance, then I don't see a problem... the JDK build times are essentially unchanged.

If you mean lines of code or whatever, then it doesn't seem inordinate. And the algorithm is more or less just an AST scan, like lots of other examples in the compiler code. So I don't see a problem there either.

Yes, there may be a much simpler way that's just as good, but if I could have thought of it I would have already. Perhaps you or someone else has better insight.

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

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


From achung at openjdk.org  Wed Jan 11 22:59:15 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 11 Jan 2023 22:59:15 GMT
Subject: RFR: 8282217: Key events (key char and key code) changed for Swiss
 keyboard
In-Reply-To: <N9XfS6cL8s1G98UAiEr7ZvgzQB-HX6qKGptKZe7d810=.1f5932c5-fd00-4fe8-9c0b-99f2fa71d880@github.com>
References: <N9XfS6cL8s1G98UAiEr7ZvgzQB-HX6qKGptKZe7d810=.1f5932c5-fd00-4fe8-9c0b-99f2fa71d880@github.com>
Message-ID: <f4tbeIMLuDLmlsUQ-f7toipPH88LmSAVG6uqxdiOaYM=.61535709-d20f-4b2b-a0eb-ba41c862eb8f@github.com>

On Fri, 6 Jan 2023 22:07:33 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removed check for MapVirtualKeyEx return value causing some keys to become undefined

I checked that the behavior of the test in https://bugs.openjdk.org/browse/JDK-8139189 is unchanged

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

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


From honkar at openjdk.org  Wed Jan 11 23:20:02 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 11 Jan 2023 23:20:02 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v6]
In-Reply-To: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
Message-ID: <8au3Az8YmQ2nUEBoHLfFhGP1x12IisI0y_LnU07xhNE=.4933ff2e-2683-42a7-ae01-6b8da98b0d58@github.com>

> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as functional parameter to the method.  
> 
> Following are the usual steps for any border scaling -
> 
> - Resetting transform.
> - Calculating new width, height, x & y-translations.
> - Perform the required border rendering.
> - And at the end restore the previous transform.
> 
> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
> 
> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
> 
> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.

Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - removed unused parameters, old stroke changes
 - Merge branch 'master' into RefactorBorder_8294484
 - moved strokeWidth logic to individual classes
 - review changes
 - Revert "test changes"
   
   This reverts commit abed51bd420941d8efa7b779b86257978f56810e.
 - test changes
 - minor changes
 - Merge branch 'master' into RefactorBorder_8294484
 - Merge branch 'master' into RefactorBorder_8294484
 - review changes
 - ... and 5 more: https://git.openjdk.org/jdk/compare/43847c43...9caca6b2

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

Changes: https://git.openjdk.org/jdk/pull/11571/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11571&range=05
  Stats: 248 lines in 4 files changed: 95 ins; 142 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/11571.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11571/head:pull/11571

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


From honkar at openjdk.org  Wed Jan 11 23:29:18 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 11 Jan 2023 23:29:18 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v5]
In-Reply-To: <aN-c2EJcfzqUL0ld54R6GOccHEZ4fA6dsnyFpwclm7c=.b40b7a89-213e-4c78-bd18-f0876135c937@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <LQryZvfoeTq3YYiQzSE6SaDiDgMnSRFnaPxNLDtPf9U=.d7efc83c-90d8-44f6-86c0-4a3244787f80@github.com>
 <aN-c2EJcfzqUL0ld54R6GOccHEZ4fA6dsnyFpwclm7c=.b40b7a89-213e-4c78-bd18-f0876135c937@github.com>
Message-ID: <UCK_mYp0nk1coekDY9HCV4_h6uzz6bhS_VaVVejUBBM=.f45a3527-cc59-49cd-8365-c3c517e9cd46@github.com>

On Wed, 11 Jan 2023 20:37:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   moved strokeWidth logic to individual classes
>
> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 196:
> 
>> 194: 
>> 195:         // Step 2: Call respective paintBorder with transformed values
>> 196:         painter.paintUnscaledBorder(c, g, x, y, width, height, scaleFactor);
> 
> Why do you pass the original `x` and `y`? They must be 0 inside `paintUnscaledBorder`. As such, `x` and `y` parameters can be dropped.

Thanks for catching. Removed unused parameters.

> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 203:
> 
>> 201:             Graphics2D g2d = (Graphics2D) g;
>> 202:             g2d.setTransform(at);
>> 203:             g2d.setStroke(oldStk);
> 
> The stroke should always be restored even if the transform wasn't reset. Or it should be done in the implementation of `paintUnscaledBorder`.

@aivanov-jdk Earlier strokeWidth was set when resetTransform was true and it was restored on the same condition. Now since the stroke width is moved to individual implementation of paintUnscaledBorder, it make sense to restore it outside of resetTranform.

To avoid missing this step, I have restored it in common code than in individual paintUnscaledBorder implementations.

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

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


From mcimadamore at openjdk.org  Thu Jan 12 00:18:11 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 00:18:11 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
 <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
 <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>
Message-ID: <Z1YrthZISaALPMxL1F5GnGEdE7xgmw1cUY-O4ogt1DQ=.3c8554be-1739-4a1a-b4f5-4bde0e0c1a2b@github.com>

On Wed, 11 Jan 2023 22:40:43 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> 
> D'oh, you're right. But if you made `returnMe()` static or private then the argument would still hold.
> 
> > And, if the method is static, same story - you are passing ref3 somewhere else, and ref3 potentially contains this.
> 
> Not true... static methods are safe to "invoke" because they can't be overridden. When the analyzer "invokes" the method, it will see that all it does with its parameter is return it.
> 

So, for static methods, it could go down two ways: either we don't even look at referenced method bodies, give up and just declare "sorry, escaping". Or, if we look into method bodies, and see that the relationship between inner and outer parameter is as simple, it's just like assignment again:

ref1 -> ref2 -> ref3 -> x -> ref4

> But I don't really have an analysis of all the trade-offs. Really, at a certain point I stumbled on what I thought was a fairly straightforward way to achieve a good false negative rate and a very low false positive rate, without a lot of work. And frankly at that point I stopped caring about the question you're asking, although I agree it's certainly interesting from an academic point of view (I'm a practical person).

The reason I'm asking these questions is that I'm trying to understand which ingredients went into the analysis and why, in order to try and build a mental problem of what the problem that needs to be solved is, what are the constraints, etc. I'm also a practical person :-) and I often find it easier to understand a piece of code if I know some of the reasoning that went behind it, or what's the behavior supposed to be.

I do not know, off-hands, whether there is a simpler solution - I was mostly probing for war stories of the kind "I tried X and I got Y", and I apologize if that came off the wrong way.

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

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


From serb at openjdk.org  Thu Jan 12 01:58:24 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 12 Jan 2023 01:58:24 GMT
Subject: Integrated: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java
 fails with AssertionError
In-Reply-To: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
References: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>
Message-ID: <zUTRhGYCzmTHlELnar15CuXD99IiQIa4WWvoMYpa7d4=.3f664914-50ab-4dee-9182-a76f45062657@github.com>

On Mon, 26 Dec 2022 05:17:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This assertion happens when we try to build the path linked by the shortcut file when part of that path is not accessible. For example, if the ".lnk" file is pointed to the "windows-update. settings" inside the "Internet.settings". 
> 
> After the change, we will skip the target of the link if any part of the path to the target is not a folder and is not traversable in JFileChooser.

This pull request has now been integrated.

Changeset: 78b1686c
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78b1686c150aeaa29c5d969b70c9c42c872246a2
Stats:     88 lines in 4 files changed: 82 ins; 0 del; 6 mod

8227257: javax/swing/JFileChooser/4847375/bug4847375.java fails with AssertionError

Reviewed-by: aivanov, tr

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

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


From serb at openjdk.org  Thu Jan 12 02:06:14 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 12 Jan 2023 02:06:14 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v8]
In-Reply-To: <O3Az9Np5wHv6eR6gUX87qMZzXQIeNWVwlIisGhIHBTU=.1c645dc6-decc-4fdd-b8d0-92e98d0596fe@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
 <O3Az9Np5wHv6eR6gUX87qMZzXQIeNWVwlIisGhIHBTU=.1c645dc6-decc-4fdd-b8d0-92e98d0596fe@github.com>
Message-ID: <B0oej171BPDzXfFdqLXh23zAoOVS8mWeYRGFKkoplwE=.f102826c-8259-4ce6-a452-dd7cacb3e3bc@github.com>

On Tue, 10 Jan 2023 11:27:50 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> [OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   It is better to force the "ensureClassInitialized" as any other getters in this class. To make sure the field is up-to-date even if it was initialized on another thread.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.org  Thu Jan 12 02:10:17 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 12 Jan 2023 02:10:17 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <8NCbdLCtapYaDVZQrl2rLo6NlCO8JrFzXr4OYMe4AWU=.6f24a709-00ad-4413-be0c-4961cced1110@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
 <DD5uVC90-DPgmwfJXNEgnLj_wxHGTD7_uKMZBwNLHa8=.6a564a17-23d4-4da8-8381-c882b852aaaa@github.com>
 <c4Qx6gF9iiaJdMaOybsl_4cNgqu8KPNOQQH2zBDAOzU=.a72f2f21-5212-4337-b3f3-ccff0a39c728@github.com>
 <jH6H-chU7-m3gPJRb1v2StPHplL06eKXHvUIrxV-FYE=.f6f34982-26c3-43b9-9ac0-ddb1a4fd1c9a@github.com>
 <PumLFS7NJwkLt_U6b3CCraoRha0lG6oy_K8v-uFTtV4=.5467e88c-f34b-449c-a71b-eefbe72999ba@github.com>
 <A2gaQz19gcGEOYHSrUI1kpoGZAGXfSzIyUdGG7tnQgk=.9b95ef26-91b8-4ef4-9a6b-4aab6ef4aae5@github.com>
 <8NCbdLCtapYaDVZQrl2rLo6NlCO8JrFzXr4OYMe4AWU=.6f24a709-00ad-4413-be0c-4961cced1110@github.com>
Message-ID: <3HxXiTzAl_so2TGaDPvdW-rL7hY2nMKNA3225gWPkQc=.17692405-3738-4139-97a7-8438182e4266@github.com>

On Tue, 10 Jan 2023 14:44:38 GMT, Tejesh R <tr at openjdk.org> wrote:

> Created - [JDK-8299893](https://bugs.openjdk.org/browse/JDK-8299893). Shall I integrate this PR by removing the test from problemList?

Did we have a chance to reproduce it at least once other than accidentally in mach5? If not that not necessarily is a root cause, I doubt that the new bug will not be fixed any time soon.

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

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


From serb at openjdk.org  Thu Jan 12 02:10:20 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 12 Jan 2023 02:10:20 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
Message-ID: <OEhpJZ3GXOLFI6EOgkacQ08jN0jb-yW25Ibzbv9dDJM=.e3d5d4d1-cbad-4a03-ac7d-ac2449b73514@github.com>

On Thu, 22 Dec 2022 05:13:34 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

test/jdk/javax/swing/JFileChooser/8046391/bug8046391.java line 30:

> 28:  * @summary JFileChooser hangs if displayed in Windows L&F
> 29:  * @author Alexey Ivanov
> 30:  * @key headful

If we assume that the bug is fixed by the code change we do not need to change the test.

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

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


From duke at openjdk.org  Thu Jan 12 02:17:16 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 02:17:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <Z1YrthZISaALPMxL1F5GnGEdE7xgmw1cUY-O4ogt1DQ=.3c8554be-1739-4a1a-b4f5-4bde0e0c1a2b@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
 <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
 <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>
 <Z1YrthZISaALPMxL1F5GnGEdE7xgmw1cUY-O4ogt1DQ=.3c8554be-1739-4a1a-b4f5-4bde0e0c1a2b@github.com>
Message-ID: <NsEcde65vTzRWfOo9UVogBDQNaoKIRnguLx3Y2IN2a4=.8005b605-5aa6-42b3-b4f7-9396a98081cf@github.com>

On Thu, 12 Jan 2023 00:15:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> So, for static methods, it could go down two ways: either we don't even look at referenced method bodies, give up and just declare "sorry, escaping". Or, if we look into method bodies, and see that the relationship between inner and outer parameter is as simple, it's just like assignment again:

Right - and just to reconfirm, it's only the non-overridable methods in the same compilation unit that are "invoked" (i.e., analyzed & tracked). Any method that (might) exist in another compilation unit is off limits, so we have to assume the worst case and declare a leak if we are passing it any 'this' references.

>  in order to try and build a mental problem of what the problem that needs to be solved is

Gotcha.

Let's be clear about what exactly we're worrying about. It's this situation: You have a class `B extends A`, where `B` and `A` are in different compilation units, and during the `super()` call that constructor `B()` makes to its superclass constructor `A()`, some code in class `B` gets executed (really, it's some field in `B` getting accessed that actually matters) prior to `A()` returning.

So the basic goal is to analyze `A` constructors and watch 'this' references until if/when they go to someplace where we can no longer watch them. At that point we have to assume that some code in `B` might get invoked and so we generate a warning.

OK, so where can a 'this' reference go?

Well, here are all of the possible places a Java reference can exist:
1. On the Java stack
    (a) The current 'this' instance
    (b) A method parameter
    (c) A local variable
    (d) A temporary value that is part of the current expression being evaluated
    (e) The return value from a method that just returned
    (f) A caught exception
1. In a field of some object...
    (a) A normal field
    (b) An outer 'this' instance
    (c) Other synthetic field (e.g., captured free variable)
1. As an element in a reference array
1. In native code as a native reference

Those are the only possibilities AFAIK.

So one way to locate yourself on the spectrum from "simple" to "complex" is to answer this question: Which of those are you going to try to keep track of, and for each one, how hard are you going to try?

The `this-escape` analysis being proposed tracks 1(a-e) and 2(b) pretty closely (it tries hard), and it adds a very course tracking of 2(a-c), and 3 using the notion of indirect references (it doesn't try very hard). We do not track 1(f) or 4.

So to think about the overall problem, imagine how you might or might not address all of those cases.

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

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


From tr at openjdk.org  Thu Jan 12 04:42:15 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 12 Jan 2023 04:42:15 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <3HxXiTzAl_so2TGaDPvdW-rL7hY2nMKNA3225gWPkQc=.17692405-3738-4139-97a7-8438182e4266@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
 <DD5uVC90-DPgmwfJXNEgnLj_wxHGTD7_uKMZBwNLHa8=.6a564a17-23d4-4da8-8381-c882b852aaaa@github.com>
 <c4Qx6gF9iiaJdMaOybsl_4cNgqu8KPNOQQH2zBDAOzU=.a72f2f21-5212-4337-b3f3-ccff0a39c728@github.com>
 <jH6H-chU7-m3gPJRb1v2StPHplL06eKXHvUIrxV-FYE=.f6f34982-26c3-43b9-9ac0-ddb1a4fd1c9a@github.com>
 <PumLFS7NJwkLt_U6b3CCraoRha0lG6oy_K8v-uFTtV4=.5467e88c-f34b-449c-a71b-eefbe72999ba@github.com>
 <A2gaQz19gcGEOYHSrUI1kpoGZAGXfSzIyUdGG7tnQgk=.9b95ef26-91b8-4ef4-9a6b-4aab6ef4aae5@github.com>
 <8NCbdLCtapYaDVZQrl2rLo6NlCO8JrFzXr4OYMe4AWU=.6f24a709-00ad-4413-be0c-4961cced1110@github.com>
 <3HxXiTzAl_so2TGaDPvdW-rL7hY2nMKNA3225gWPkQc=.17692405-3738-4139-97a7-8438182e4266@github.com>
Message-ID: <3jXU8Knnl2wEmd2Nqw6B9y0roPO7n1PutgWosvGABpc=.e0f35bf1-ec72-44e9-b6e2-e8b922781c11@github.com>

On Thu, 12 Jan 2023 02:07:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Created - [JDK-8299893](https://bugs.openjdk.org/browse/JDK-8299893). Shall I integrate this PR by removing the test from problemList?
> 
> Did we have a chance to reproduce it at least once other than accidentally in mach5? If not that not necessarily is a root cause, I doubt that the new bug will not be fixed any time soon.

Other than accidentally in mach5, NO. Out of 200 repeated tests, 8 tests failures were observed, again the numbers are not fixed.

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

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


From tr at openjdk.org  Thu Jan 12 04:50:17 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 12 Jan 2023 04:50:17 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <OEhpJZ3GXOLFI6EOgkacQ08jN0jb-yW25Ibzbv9dDJM=.e3d5d4d1-cbad-4a03-ac7d-ac2449b73514@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
 <OEhpJZ3GXOLFI6EOgkacQ08jN0jb-yW25Ibzbv9dDJM=.e3d5d4d1-cbad-4a03-ac7d-ac2449b73514@github.com>
Message-ID: <_blWT-RE_MlCC0xpqwn90gJMkpi0uxM48H9X9J9s6EE=.45a14401-d937-453c-9521-8e4069ec2e21@github.com>

On Thu, 12 Jan 2023 02:07:51 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/javax/swing/JFileChooser/8046391/bug8046391.java line 30:
> 
>> 28:  * @summary JFileChooser hangs if displayed in Windows L&F
>> 29:  * @author Alexey Ivanov
>> 30:  * @key headful
> 
> If we assume that the bug is fixed by the code change we do not need to change the test.

Since we are not 100% sure that the issue is not with headless and is with code, I guess it is safe to change the test to headful. Anyhow it will take time to analyse and conclude that the issue is with the code and so the new bug has been raised. This PR addresses handling the error cases also if you can go through the previous conversations, so the new can bug can be focused on whether the bug is w.r.t headless/code.

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

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


From tr at openjdk.org  Thu Jan 12 04:55:15 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 12 Jan 2023 04:55:15 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v5]
In-Reply-To: <PEXwLuJYsSJxMmbGYQEMDTY4A_ON_xkpG5ckMxj6Sjg=.efa1304d-f310-4431-853a-2c33e9cbd8bd@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <9ybbK-vje2WkFfoDXlLU1jJJc3QKi5VTf57_KKVfQIk=.50851a17-ad46-476b-87eb-16734fdea50c@github.com>
 <PEXwLuJYsSJxMmbGYQEMDTY4A_ON_xkpG5ckMxj6Sjg=.efa1304d-f310-4431-853a-2c33e9cbd8bd@github.com>
Message-ID: <BHx-0TiUqJWPfbeMM1MvgsHRqsWu0FhiHL7fMEphucM=.1238973f-7ac3-4786-8aaf-334ec2d96395@github.com>

On Wed, 11 Jan 2023 19:49:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Spacing updation
>
> test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 83:
> 
>> 81:             return;
>> 82:         }
>> 83:         if (customApproveButton.getText() == null) {
> 
> Now that you test that the text on the Approve is non-null only, why is Aqua L&F excluded?

Since in aqua the fallback text is handled already and in aqua there is a sub panel which handles the Approve button, I excluded it.

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

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


From tr at openjdk.org  Thu Jan 12 06:06:32 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 12 Jan 2023 06:06:32 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v6]
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <RpUGKQWl-Gg_TWMmpzgIJMEYVkYW5Nvy1sIIiMbEdHQ=.3ca53ed6-a203-42ce-9423-3ac2623e5dd4@github.com>

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

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/11901/files
  - new: https://git.openjdk.org/jdk/pull/11901/files/ede54bad..14b358c1

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

  Stats: 55 lines in 2 files changed: 23 ins; 15 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/11901.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11901/head:pull/11901

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


From tr at openjdk.org  Thu Jan 12 06:09:18 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 12 Jan 2023 06:09:18 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v4]
In-Reply-To: <pX2WZBv46bDsVHcpI1XoQ5WidQYxORLUHGTIrzk5PO0=.6e208325-1195-44f3-b5d7-e4049144cd55@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <999t6e7nMiYkRBFxmGYeuFgp1qX3V9BvfGBL1ZzqgHc=.3ab7ce37-1729-4e5d-9eb1-76474e2dcd9e@github.com>
 <pX2WZBv46bDsVHcpI1XoQ5WidQYxORLUHGTIrzk5PO0=.6e208325-1195-44f3-b5d7-e4049144cd55@github.com>
Message-ID: <53o0vwqbKT7pbkXmuBiKouxX0OoBX-jOCjBBF7yFB9M=.1242698f-46d6-46dd-9e66-585d91148bd1@github.com>

On Wed, 11 Jan 2023 07:02:18 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverting aqua check condition
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 586:
> 
>> 584:         }
>> 585: 
>> 586:         if(fc.getDialogType() == JFileChooser.OPEN_DIALOG ||
> 
> Suggestion:
> 
>         if (fc.getDialogType() == JFileChooser.OPEN_DIALOG ||

Updated.

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

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


From tr at openjdk.org  Thu Jan 12 06:09:35 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 12 Jan 2023 06:09:35 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v5]
In-Reply-To: <PEXwLuJYsSJxMmbGYQEMDTY4A_ON_xkpG5ckMxj6Sjg=.efa1304d-f310-4431-853a-2c33e9cbd8bd@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <9ybbK-vje2WkFfoDXlLU1jJJc3QKi5VTf57_KKVfQIk=.50851a17-ad46-476b-87eb-16734fdea50c@github.com>
 <PEXwLuJYsSJxMmbGYQEMDTY4A_ON_xkpG5ckMxj6Sjg=.efa1304d-f310-4431-853a-2c33e9cbd8bd@github.com>
Message-ID: <mR4vp2J19qHNF8jcfIsL7XpKUURfJQB9DgzJ2yu5Qro=.a1bbcb69-51ab-45ad-9e51-d833fa0a14fb@github.com>

On Wed, 11 Jan 2023 19:44:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Spacing updation
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 586:
> 
>> 584:         }
>> 585: 
>> 586:         if (fc.getDialogType() == JFileChooser.OPEN_DIALOG ||
> 
> Since you added spaces after `if`, you should probably update the `if` above too.

Updated.

> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 587:
> 
>> 585: 
>> 586:         if (fc.getDialogType() == JFileChooser.OPEN_DIALOG ||
>> 587:                 fc.getDialogType() == JFileChooser.CUSTOM_DIALOG) {
> 
> Suggestion:
> 
>         if (fc.getDialogType() == JFileChooser.OPEN_DIALOG
>                 || fc.getDialogType() == JFileChooser.CUSTOM_DIALOG) {
> 
> I prefer it this way: wrapping before the operator makes it clear that it's a continuation line.

Updated.

> test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 62:
> 
>> 60:     private CustomApproveButtonTest(String lookAndFeel) {
>> 61:         System.out.println("Testing Look & Feel : " + lookAndFeel);
>> 62:         frame = new JFrame("CustomApproveButtonTest");
> 
> You should create the frame after you set the Look-and-Feel.

Updated.

> test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 69:
> 
>> 67:             throw new RuntimeException("Failed to set " + lookAndFeel +
>> 68:                     " LookAndFeel. Error : " + e);
>> 69:         }
> 
> You should probably quietly ignore the Look-and-Feel if `UnsupportedLookAndFeelException` is thrown.

Updated.

> test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 75:
> 
>> 73:         frame.add(fileChooser);
>> 74:         frame.setVisible(true);
>> 75:         frame.pack();
> 
> Suggestion:
> 
>         frame.pack();
>         frame.setVisible(true);
> 
> 
> Usually, `pack()` goes before `setVisible` to ensure the size is calculated before the frame is made visible so that no flickering occurs because the size gets updated.

Updated.

> test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 96:
> 
>> 94:         if (frame != null) {
>> 95:             frame.dispose();
>> 96:         }
> 
> The easiest way to avoid duplicate code for disposing of the frame is to use `try`-`finally` block which is commonly used in tests:
> 
> 
> // Set Look-and-Feel
> try {
>     frame = new JFrame("title");
>     // The rest of the test code
> 
>     // You can throw any exception to fail the test,
>     // the finally block below will still dispose of the frame.
> } finally {
>     if (frame != null) {
>         frame.dispose();
>     }
> }

Updated.

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

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


From psadhukhan at openjdk.org  Thu Jan 12 06:14:32 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 12 Jan 2023 06:14:32 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v4]
In-Reply-To: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
Message-ID: <KyXt0enZuPEsiGn7Yc2jvDEtqssvtR9qgdt4ykCdPKI=.821dea40-4aa9-4349-9e0e-3c3a0a070301@github.com>

> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
> says:
> "...MetalLookAndFeel registers an entry for each of the classes
> in the package javax.swing.plaf.metal that are named MetalXXXUI.
> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
> that do not have a class in metal, the corresponding class in
> javax.swing.plaf.basic is used. For example, metal does not
> have a class named "MetalColorChooserUI", as such,
> javax.swing.plaf.basic.BasicColorChooserUI is used".
> 
> There is class MetalMenuBarUI, but the method populates given defaults table with the value
> "javax.swing.plaf.basic.BasicMenuBarUI".
> 
> Added entry for MetalMenuBarUI..
> CI tests including JCK tests are ok.

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

  Update spec wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11646/files
  - new: https://git.openjdk.org/jdk/pull/11646/files/71965da8..4a38b8c1

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

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

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


From tr at openjdk.org  Thu Jan 12 06:26:15 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 12 Jan 2023 06:26:15 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v5]
In-Reply-To: <BHx-0TiUqJWPfbeMM1MvgsHRqsWu0FhiHL7fMEphucM=.1238973f-7ac3-4786-8aaf-334ec2d96395@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <9ybbK-vje2WkFfoDXlLU1jJJc3QKi5VTf57_KKVfQIk=.50851a17-ad46-476b-87eb-16734fdea50c@github.com>
 <PEXwLuJYsSJxMmbGYQEMDTY4A_ON_xkpG5ckMxj6Sjg=.efa1304d-f310-4431-853a-2c33e9cbd8bd@github.com>
 <BHx-0TiUqJWPfbeMM1MvgsHRqsWu0FhiHL7fMEphucM=.1238973f-7ac3-4786-8aaf-334ec2d96395@github.com>
Message-ID: <2k9HDwh7mMFiCfbsBZ1C092fL8DeBlsnx7D2z4041o4=.edce5b20-518b-4cf0-8550-6e37c01bcb83@github.com>

On Thu, 12 Jan 2023 04:52:32 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 83:
>> 
>>> 81:             return;
>>> 82:         }
>>> 83:         if (customApproveButton.getText() == null) {
>> 
>> Now that you test that the text on the Approve is non-null only, why is Aqua L&F excluded?
>
> Since in aqua the fallback text is handled already and in aqua there is a sub panel which handles the Approve button, I excluded it.

Also, `getDefaultApproveButton()` returns null for Aqua L&F, to include Aqua in the test we can use `getApproveButtonText()`.

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

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


From psadhukhan at openjdk.org  Thu Jan 12 08:12:07 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 12 Jan 2023 08:12:07 GMT
Subject: RFR: 8041447: Test javax/swing/dnd/7171812/bug7171812.java fails with
 java.lang.RuntimeException: Test failed, scroll on drag doesn't work
Message-ID: <uOs8YGOmi-VhtYfqBhZ2sp63E6LC38r2SPo8OS_PBgM=.2567b104-b687-44d6-b3f0-69edbc9fefa3@github.com>

Test probably was failing few years back due to samevm mode.
It's not failing now but made some robot safeguards.
Several iterations are passing in all CI platforms. Link in JBS.

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

Commit messages:
 - 8041447: Test javax/swing/dnd/7171812/bug7171812.java fails with java.lang.RuntimeException: Test failed, scroll on drag doesn't work

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

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


From asemenov at openjdk.org  Thu Jan 12 08:22:19 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 12 Jan 2023 08:22:19 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v8]
In-Reply-To: <O3Az9Np5wHv6eR6gUX87qMZzXQIeNWVwlIisGhIHBTU=.1c645dc6-decc-4fdd-b8d0-92e98d0596fe@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
 <O3Az9Np5wHv6eR6gUX87qMZzXQIeNWVwlIisGhIHBTU=.1c645dc6-decc-4fdd-b8d0-92e98d0596fe@github.com>
Message-ID: <X6wQq_3HPHzfH-JQr-eYbytM5d-hoxSt2AavzIX-66A=.68ae40da-9f90-4f37-a07d-51bb976ce275@github.com>

On Tue, 10 Jan 2023 11:27:50 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> [OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   It is better to force the "ensureClassInitialized" as any other getters in this class. To make sure the field is up-to-date even if it was initialized on another thread.

@prrace @azuev-java please review

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

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


From mcimadamore at openjdk.org  Thu Jan 12 10:00:21 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 10:00:21 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <NsEcde65vTzRWfOo9UVogBDQNaoKIRnguLx3Y2IN2a4=.8005b605-5aa6-42b3-b4f7-9396a98081cf@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
 <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
 <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>
 <Z1YrthZISaALPMxL1F5GnGEdE7xgmw1cUY-O4ogt1DQ=.3c8554be-1739-4a1a-b4f5-4bde0e0c1a2b@github.com>
 <NsEcde65vTzRWfOo9UVogBDQNaoKIRnguLx3Y2IN2a4=.8005b605-5aa6-42b3-b4f7-9396a98081cf@github.com>
Message-ID: <Cq9llhpGlvwFe1IYfakr-bd1POmSCTDfQ1kPFeTJQVI=.9048fd23-9fff-4941-8d51-e249f920783f@github.com>

On Thu, 12 Jan 2023 02:14:10 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>>> 
>>> D'oh, you're right. But if you made `returnMe()` static or private then the argument would still hold.
>>> 
>>> > And, if the method is static, same story - you are passing ref3 somewhere else, and ref3 potentially contains this.
>>> 
>>> Not true... static methods are safe to "invoke" because they can't be overridden. When the analyzer "invokes" the method, it will see that all it does with its parameter is return it.
>>> 
>> 
>> So, for static methods, it could go down two ways: either we don't even look at referenced method bodies, give up and just declare "sorry, escaping". Or, if we look into method bodies, and see that the relationship between inner and outer parameter is as simple, it's just like assignment again:
>> 
>> ref1 -> ref2 -> ref3 -> x -> ref4
>> 
>>> But I don't really have an analysis of all the trade-offs. Really, at a certain point I stumbled on what I thought was a fairly straightforward way to achieve a good false negative rate and a very low false positive rate, without a lot of work. And frankly at that point I stopped caring about the question you're asking, although I agree it's certainly interesting from an academic point of view (I'm a practical person).
>> 
>> The reason I'm asking these questions is that I'm trying to understand which ingredients went into the analysis and why, in order to try and build a mental problem of what the problem that needs to be solved is, what are the constraints, etc. I'm also a practical person :-) and I often find it easier to understand a piece of code if I know some of the reasoning that went behind it, or what's the behavior supposed to be.
>> 
>> I do not know, off-hands, whether there is a simpler solution - I was mostly probing for war stories of the kind "I tried X and I got Y", and I apologize if that came off the wrong way.
>
>> So, for static methods, it could go down two ways: either we don't even look at referenced method bodies, give up and just declare "sorry, escaping". Or, if we look into method bodies, and see that the relationship between inner and outer parameter is as simple, it's just like assignment again:
> 
> Right - and just to reconfirm, it's only the non-overridable methods in the same compilation unit that are "invoked" (i.e., analyzed & tracked). Any method that (might) exist in another compilation unit is off limits, so we have to assume the worst case and declare a leak if we are passing it any 'this' references.
> 
>>  in order to try and build a mental problem of what the problem that needs to be solved is
> 
> Gotcha.
> 
> Let's be clear about what exactly we're worrying about. It's this situation: You have a class `B extends A`, where `B` and `A` are in different compilation units, and during the `super()` call that constructor `B()` makes to its superclass constructor `A()`, some code in class `B` gets executed (really, it's some field in `B` getting accessed that actually matters) prior to `A()` returning.
> 
> So the basic goal is to analyze `A` constructors and watch 'this' references until if/when they go to someplace where we can no longer watch them. At that point we have to assume that some code in `B` might get invoked and so we generate a warning.
> 
> OK, so where can a 'this' reference go?
> 
> Well, here are all of the possible places a Java reference can exist:
> 1. On the Java stack
>     (a) The current 'this' instance
>     (b) A method parameter
>     (c) A local variable
>     (d) A temporary value that is part of the current expression being evaluated
>     (e) The return value from a method that just returned
>     (f) A caught exception
> 1. In a field of some object...
>     (a) A normal field
>     (b) An outer 'this' instance
>     (c) Other synthetic field (e.g., captured free variable)
> 1. As an element in a reference array
> 1. In native code as a native reference
> 
> Those are the only possibilities AFAIK.
> 
> So one way to locate yourself on the spectrum from "simple" to "complex" is to answer this question: Which of those are you going to try to keep track of, and for each one, how hard are you going to try?
> 
> The `this-escape` analysis being proposed tracks 1(a-e) and 2(b) pretty closely (it tries hard), and it adds a very course tracking of 2(a-c), and 3 using the notion of indirect references (it doesn't try very hard). We do not track 1(f) or 4.
> 
> So to think about the overall problem, imagine how you might or might not address all of those cases.

> * On the Java stack
>   (a) The current 'this' instance
>   (b) A method parameter
>   (c) A local variable
>   (d) A temporary value that is part of the current expression being evaluated
>   (e) The return value from a method that just returned
>   (f) A caught exception
> 
> * In a field of some object...
>   (a) A normal field
>   (b) An outer 'this' instance
>   (c) Other synthetic field (e.g., captured free variable)
> 
> * As an element in a reference array
> 
> * In native code as a native reference

Thanks for the classification. This is helpful.

I'm not sure what you mean by (1f). You mean `this` can be embedded in an exception being thrown? Is that different from (2)?

Also, it seems to me that (3) is a special case of (2) - in the sense that you can imagine a reference array as a big object that has many fields as there are elements - so the same reasoning applies.

When looking at (2d) and (2e) the fact that Javac's AST is not in SSA form means that, yes, we need to track _expressions_ not just variables (e.g. for chains of methods calls, ternary operators and such).

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

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


From serb at openjdk.org  Thu Jan 12 10:33:18 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 12 Jan 2023 10:33:18 GMT
Subject: RFR: 8041447: Test javax/swing/dnd/7171812/bug7171812.java fails
 with java.lang.RuntimeException: Test failed,
 scroll on drag doesn't work
In-Reply-To: <uOs8YGOmi-VhtYfqBhZ2sp63E6LC38r2SPo8OS_PBgM=.2567b104-b687-44d6-b3f0-69edbc9fefa3@github.com>
References: <uOs8YGOmi-VhtYfqBhZ2sp63E6LC38r2SPo8OS_PBgM=.2567b104-b687-44d6-b3f0-69edbc9fefa3@github.com>
Message-ID: <IACA2l1GF2LugImVdGDUXgQ-Rzo_j3Gzo2LdI_FBWf8=.0e71ccba-eb39-4e0d-a228-34f40dc1fb17@github.com>

On Thu, 12 Jan 2023 08:02:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test probably was failing few years back due to samevm mode.
> It's not failing now but made some robot safeguards.
> Several iterations are passing in all CI platforms. Link in JBS.

test/jdk/javax/swing/dnd/7171812/bug7171812.java line 69:

> 67:         robot.waitForIdle();
> 68:         robot.delay(1000);
> 69:         robot.mouseMove(scrollPane.getLocationOnScreen().x + 5,

The scrollPane should be accessed on EDT.

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

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


From serb at openjdk.org  Thu Jan 12 10:45:17 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 12 Jan 2023 10:45:17 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v2]
In-Reply-To: <2ZHOyW1znkGexCRUDlPgJdLdKeIQeKwGSZIrWRNtW5s=.0fed5796-165b-45fe-89c7-14e211617835@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <2ZHOyW1znkGexCRUDlPgJdLdKeIQeKwGSZIrWRNtW5s=.0fed5796-165b-45fe-89c7-14e211617835@github.com>
Message-ID: <q0nbGDroN8GsUeLspa4LhLx_bgfDV_-OpSXMjsnR_nk=.2859494d-d288-4cbf-a0c6-21c5c03c74bf@github.com>

On Wed, 11 Jan 2023 11:33:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

src/java.desktop/share/classes/javax/swing/SwingWorker.java line 757:

> 755:                 do {
> 756:                     try {
> 757:                         Thread.sleep(100);

I did not look closely at the discussion in JBS about this change, but this "sleep(100)" looks broken. I do not think we can block EDT like this.

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

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


From psadhukhan at openjdk.org  Thu Jan 12 11:43:47 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 12 Jan 2023 11:43:47 GMT
Subject: RFR: 8041447: Test javax/swing/dnd/7171812/bug7171812.java fails
 with java.lang.RuntimeException: Test failed,
 scroll on drag doesn't work [v2]
In-Reply-To: <uOs8YGOmi-VhtYfqBhZ2sp63E6LC38r2SPo8OS_PBgM=.2567b104-b687-44d6-b3f0-69edbc9fefa3@github.com>
References: <uOs8YGOmi-VhtYfqBhZ2sp63E6LC38r2SPo8OS_PBgM=.2567b104-b687-44d6-b3f0-69edbc9fefa3@github.com>
Message-ID: <5KV1a4L29hNCfjALWGJ8T0NQPE1XebPmwN3ntCLLWVo=.2542dc44-1a49-4beb-acde-e5246d21c48b@github.com>

> Test probably was failing few years back due to samevm mode.
> It's not failing now but made some robot safeguards.
> Several iterations are passing in all CI platforms. Link in JBS.

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

  Access swing comp in EDT

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11959/files
  - new: https://git.openjdk.org/jdk/pull/11959/files/5623f4b3..01f13be8

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

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

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


From duke at openjdk.org  Thu Jan 12 12:13:19 2023
From: duke at openjdk.org (ScientificWare)
Date: Thu, 12 Jan 2023 12:13:19 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v12]
In-Reply-To: <PyHPvsC1dCoNrM2H0WJxpyqFCrAd85tcM1nDQDQLTHQ=.b4b3b40a-ce82-4d78-8236-b72b63d155cf@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <PyHPvsC1dCoNrM2H0WJxpyqFCrAd85tcM1nDQDQLTHQ=.b4b3b40a-ce82-4d78-8236-b72b63d155cf@github.com>
Message-ID: <OtpoB4JIpHJuZVgTm40QSQ8CtIRKvbPlSa8kCgeqxNo=.2f35a128-f1fe-4fe5-9f6c-d4897010b9c5@github.com>

On Wed, 14 Dec 2022 20:13:52 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 one additional commit since the last revision:
> 
>   Update imports
>   
>   Remove java.util.Pattern and add java.util.Map imports

Still waiting a review.

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

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


From ihse at openjdk.org  Thu Jan 12 12:16:18 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 12 Jan 2023 12:16:18 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
Message-ID: <M5rLDA8SccWTlvv2IaT5nm4enfgYICmjd5cUPWLh6rY=.1933b28a-5a2f-4507-8fda-a44728743516@github.com>

On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use the more appropriate Type comparison method Types.isSameType().
>  - Add some more comments to clarify how the analysis works.

FWIW, the make changes look good. I have nothing to say about the actual lint code itself.

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.org  Thu Jan 12 12:22:15 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 12 Jan 2023 12:22:15 GMT
Subject: RFR: 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: <Y5kqJyjNq8_ooSRQjPpilkyD6adFTZPd-MamS2_222g=.7111d6ee-82b9-4673-8099-09d74cc123ec@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.

Build changes look great! I have also looked through the code changes itself, and they look sane to me, but you'll need an approval from someone on the client team as well.

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

Marked as reviewed by ihse (Reviewer).

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


From mcimadamore at openjdk.org  Thu Jan 12 12:31:39 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 12:31:39 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
Message-ID: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>

On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use the more appropriate Type comparison method Types.isSameType().
>  - Add some more comments to clarify how the analysis works.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 163:

> 161:      *  invoked from the target constructor; if empty, we're still in the constructor.
> 162:      */
> 163:     private final ArrayDeque<DiagnosticPosition> callStack = new ArrayDeque<>();

There is a concept of push/popScope and then there's a separate concept of call stack (which is just a list of diagnostic position up to the point). I wonder if this could be better modeled by using a single class e.g. Scope/Frame which has a diagnostic position, plus other useful things. Perhaps it might even be helpful to have a ref set on each scope, so that you don't have to attach a "depth" to each ref - the depth of the ref would be determined by the "scope" in which it appears.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 175:

> 173:     private DiagnosticPosition[] pendingWarning;
> 174: 
> 175: // These fields are scoped to the CONSTRUCTOR OR INVOKED METHOD BEING ANALYZED

Watch out for "all caps"

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 218:

> 216:         new TreeScanner() {
> 217: 
> 218:             private Lint lint = ThisEscapeAnalyzer.this.lint;

On a first look I'm not sure about the granularity of suppression here. I believe that suppressing at the class level, or at the constructor level is enough. Allowing to further annotate var declarations and non-constructor methods, while doable, might actually be counter productive - in the sense that the annotation does not occur in the constructor (where you'd want to see it) but in some other method. I think the fact that a constructor is escaping (willingly) should be a visible thing. Something to consider.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 220:

> 218:             private Lint lint = ThisEscapeAnalyzer.this.lint;
> 219:             private JCClassDecl currentClass;
> 220:             private boolean privateOuter;

I don't think this is needed - see below

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 227:

> 225:                 final boolean privateOuterPrev = this.privateOuter;
> 226:                 final Lint lintPrev = this.lint;
> 227:                 this.lint = this.lint.augment(tree.sym);

general stylistic comment - I see here and everywhere in this class `this.xyz` - this is not the norm in the rest of the javac codebase, and it would be better to replace it with just `xyz`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 230:

> 228:                 try {
> 229:                     this.currentClass = tree;
> 230:                     this.privateOuter |= tree.sym.isAnonymous();

These can be inlined in the check below

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 270:

> 268:                     final boolean analyzable = this.currentClassIsExternallyExtendable() &&
> 269:                         TreeInfo.isConstructor(tree) &&
> 270:                         !tree.sym.isPrivate() &&

Why aren't private constructors analyzed? If we have a class with a private constructor and public static factory invoking said constructor, and the constructor makes `this` escape, isn't that an issue we should detect?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 294:

> 292:                   !(this.currentClass.sym.isSealed() && this.currentClass.permitting.isEmpty()) &&
> 293:                   !(this.currentClass.sym.owner.kind == MTH) &&
> 294:                   !this.privateOuter;

Here, note that is the owner of the current class symbol is a method, that covers anonymous classes too, which is a part of `privateOuter`. So the only think we need to check here is whether "currentClass" is private, which is a simple predicate. No need to carry `privateOuter` I believe

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 304:

> 302: 
> 303:             // We are looking for analyzable constructors only
> 304:             final Symbol sym = entry.getKey();

This seems unused. And, if so, perhaps we only need a `Set<MethodInfo>`, not a map.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 348:

> 346:         final Comparator<DiagnosticPosition[]> ordering = (warning1, warning2) -> {
> 347:             for (int index1 = 0, index2 = 0; true; index1++, index2++) {
> 348:                 final boolean end1 = index1 >= warning1.length;

Another stylistic comment - the `final` here is not super helpful. The compiler performs effectively final analysis, so if your locals are only written once, you are good to go - and can even use them inside lambdas. From a documentation perspective it might carry a bit of value, but again, the rest of the javac code generally doesn't do that.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 411:

> 409:         final boolean referenceExpressionNode;
> 410:         switch (tree.getTag()) {
> 411:         case CASE:

surprised to see `CASE` here - as that's not an expression

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 444:

> 442:         if (referenceExpressionNode) {
> 443: 
> 444:             // We treat instance methods as having a "value" equal to their instance

The comment is slightly misleading - e.g. I'd suggest clarifying "having a "value" whose type is the same as that of the class in which the method is defined"

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 454:

> 452: 
> 453:             // If the expression type is incompatible with 'this', discard it
> 454:             if (type != null && !this.isSubtype(this.targetClass.sym.type, type))

Instead of adding the direct reference, and then having to check if the reference needs to be removed, would it be possible not to add the reference in the first place if the types mismatch?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 504:

> 502:         // Recurse on method expression
> 503:         this.scan(invoke.meth);
> 504:         final boolean direct = this.refs.remove(ExprRef.direct(this.depth));

Understanding checkpoint. Considering this code:


rec.m()

There are two cases:

* `rec` might be a direct reference to this (e.g. a local)
* `rec` might be an indirect reference to this (a lambda containing `this`)

So the receiver of the method might be direct or indirect. This will then determine how to interpret `this` in the context of that method analysis - e.g. when we see a `JCIdent` for `this`, we create a direct/indirect `ExprRef` based on what the receiver kind was. Correct?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 817:

> 815:         // Methods - the "value" of a non-static method is a reference to its instance
> 816:         final Symbol sym = tree.sym;
> 817:         if (sym.kind == MTH) {

This is perhaps where filtering based on the declaring class could make sense (to avoid having to filter later) ? Perhaps this could also be centralized - e.g. whenever you create an ExprRef you also pass the type for it, and if the type matches that for the current class you create it and add to the list, otherwise you skip it.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 875:

> 873:         // Reference to this?
> 874:         if (tree.name == names._this || tree.name == names._super) {
> 875:             if (this.refs.contains(ThisRef.direct()))

This idiom occurs quite a lot. If I'm correct, this basically amounts at asking as to whether the receiver of the method we're currently evaluating is direct or not (which is an invariant, given a method body - e.g. for a given method this "fact" should stay the same). If that's the case, perhaps capturing this in a flag could be better - then you could have just have a single method e.g. `XYZRef.create(boolean direct)`, and remove the branching (here and elsewhere).

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 900:

> 898:             final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
> 899:             final Type methodOwnerType = sym.owner.type;
> 900:             if (this.isSubtype(currentClassType, methodOwnerType)) {

I believe what you need here is not subtyping but subclassing - see `Symbol.isSubclass`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 909:

> 907: 
> 908:             // Check for implicit outer 'this' reference
> 909:             if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {

Similarly here - look for `Symbol.isEnclosedBy`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1302:

> 1300:      *  In other words, a reference that's sitting on top of the stack.
> 1301:      */
> 1302:     private static class ExprRef extends Ref {

Maybe I'm wrong - but it seems that the only thing we need to track is whether the top of stack (e.g. last evaluated expression) has a direct reference or indirect reference (or none). Do we really need a set for this? (this seems the same as for ThisRef which is used inside method, which can be one of the same three options). While I do see value for tracking which variables are aliases for this (either direct or indirect), it seems like (at least on a superficial look) that expression refs might be replaced by a visitor field/parameter.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1319:

> 1317:     /** A reference from the return value of the current method being "invoked".
> 1318:      */
> 1319:     private static class ReturnRef extends Ref {

Isn't this just an ExprRef? This might also be related with the fact that we deal with return values in different ways than with e.g. values returned from a nested scope (where we just pop, and then copy all pending expression to the outer depth).

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

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


From mcimadamore at openjdk.org  Thu Jan 12 13:04:18 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 13:04:18 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
Message-ID: <PWUpnB72y0RJmSv_2fTWPwtHxWfD_vbDK0Xo96H8cWo=.4e62955d-7a89-4f8f-9032-42cba96a8628@github.com>

On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use the more appropriate Type comparison method Types.isSameType().
>  - Add some more comments to clarify how the analysis works.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 334:

> 332:         // of the stack trace of B. For example, if constructor Foo(int x) has a leak, and constructor
> 333:         // Foo() invokes this(0), then emitting a warning for Foo() would be redundant.
> 334:         final BiPredicate<DiagnosticPosition[], DiagnosticPosition[]> extendsAsPrefix = (warning1, warning2) -> {

Another strategy would be to give a single warning per leaking constructor.

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

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


From psadhukhan at openjdk.org  Thu Jan 12 13:17:15 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 12 Jan 2023 13:17:15 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v3]
In-Reply-To: <B6D0PzCSu9-jXcKh_LGLnn212HtK_N6txx5odEG4zU8=.93a86e0e-3a40-4dc3-bbf5-71908cb39af9@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <23xwHp6apwTTidFVoGzCjc-oSkW7v8hOVFZ4D_lP6c0=.eba74ea0-5731-4c4a-a971-95ec36248796@github.com>
 <B6D0PzCSu9-jXcKh_LGLnn212HtK_N6txx5odEG4zU8=.93a86e0e-3a40-4dc3-bbf5-71908cb39af9@github.com>
Message-ID: <1yefOkVuEwnZVWNx0_SO0kwMi4h1MZo-25cMEDnLuKs=.dcd4a9a5-5787-4d96-95a5-617b18b592ce@github.com>

On Sat, 7 Jan 2023 02:19:18 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Spec update
>
> We need to clarify here what we want before the CSR can be completed.
> One comment in the draft CSR got my attention -
> 
> "MetalMenuBarUI entry is not registered in this method although is is part of javax.swing.plaf.metal since it is registered in OceanTheme class, which is used by MetalLookAndFeel by default."
> 
> Hmm .. so now I'm wondering if we are phrasing things correctly.
> If themes register the UIs they use why does this method do *anything*  ?
> Or is there some *assumption* that all themes use MOST of them and so they are always registerr but
> some UIs are registered only by themes that use them ? 
> You tell me what actually happens and I can help you word it.

@prrace please review updated spec..

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

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


From duke at openjdk.org  Thu Jan 12 15:02:22 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 15:02:22 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <Cq9llhpGlvwFe1IYfakr-bd1POmSCTDfQ1kPFeTJQVI=.9048fd23-9fff-4941-8d51-e249f920783f@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
 <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
 <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>
 <Z1YrthZISaALPMxL1F5GnGEdE7xgmw1cUY-O4ogt1DQ=.3c8554be-1739-4a1a-b4f5-4bde0e0c1a2b@github.com>
 <NsEcde65vTzRWfOo9UVogBDQNaoKIRnguLx3Y2IN2a4=.8005b605-5aa6-42b3-b4f7-9396a98081cf@github.com>
 <Cq9llhpGlvwFe1IYfakr-bd1POmSCTDfQ1kPFeTJQVI=.9048fd23-9fff-4941-8d51-e249f920783f@github.com>
Message-ID: <Y1uRe5qwe5DMX5bi82veVOrQnP4JcLL94ZYLInWq9Is=.7973d572-e8ee-4b6c-bdd6-6ff9a488231a@github.com>

On Thu, 12 Jan 2023 09:57:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I'm not sure what you mean by (1f). You mean this can be embedded in an exception being thrown? Is that different from (2)?

Yes, this would be a different case from any other that you'd have to handle in the code if you wanted to deal with it. 

An example of how this could happen would be:

public class ThrownThis extends RuntimeException {

    public ThrownThis(Object obj) {
        try {
            this.validate(obj);
        } catch (RuntimeException e) {
            e.mightLeak();  // LEAK HERE
        }
    }

    private void validate(Object obj) {
        if (obj.hashCode() != 123)
            throw this;
    }

    public void mightLeak() {
    }
}

Of course, that's an absurd example and the likelihood that any random piece of actually code does that is negligible.

Regardless, I did briefly consider including handling for thrown exceptions but quickly decided it couldn't possibly be worth the trouble.

As a result, if you compile that example with `-Xlint:this-escape` you don't get a warning. No major loss!

> Also, it seems to me that (3) is a special case of (2) - in the sense that you can imagine a reference array as a big object that has many fields as there are elements - so the same reasoning applies.

Yes it's effectively the same thing, but fields and array elements are accessed by different mechanisms in Java, so from the point of the analyzer they have to be handled separately for that reason, which is why I broke them out.

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

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


From mcimadamore at openjdk.org  Thu Jan 12 15:12:56 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 15:12:56 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <Y1uRe5qwe5DMX5bi82veVOrQnP4JcLL94ZYLInWq9Is=.7973d572-e8ee-4b6c-bdd6-6ff9a488231a@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
 <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
 <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>
 <Z1YrthZISaALPMxL1F5GnGEdE7xgmw1cUY-O4ogt1DQ=.3c8554be-1739-4a1a-b4f5-4bde0e0c1a2b@github.com>
 <NsEcde65vTzRWfOo9UVogBDQNaoKIRnguLx3Y2IN2a4=.8005b605-5aa6-42b3-b4f7-9396a98081cf@github.com>
 <Cq9llhpGlvwFe1IYfakr-bd1POmSCTDfQ1kPFeTJQVI=.9048fd23-9fff-4941-8d51-e249f920783f@github.com>
 <Y1uRe5qwe5DMX5bi82veVOrQnP4JcLL94ZYLInWq9Is=.7973d572-e8ee-4b6c-bdd6-6ff9a488231a@github.com>
Message-ID: <G-1dQGlxNC0tMTi8ScMEdlxRBaK1ghCnUZw0X88GkiA=.748a82f4-8848-49cb-b6dc-54ebb30caa7e@github.com>

On Thu, 12 Jan 2023 14:59:12 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>>> * On the Java stack
>>>   (a) The current 'this' instance
>>>   (b) A method parameter
>>>   (c) A local variable
>>>   (d) A temporary value that is part of the current expression being evaluated
>>>   (e) The return value from a method that just returned
>>>   (f) A caught exception
>>> 
>>> * In a field of some object...
>>>   (a) A normal field
>>>   (b) An outer 'this' instance
>>>   (c) Other synthetic field (e.g., captured free variable)
>>> 
>>> * As an element in a reference array
>>> 
>>> * In native code as a native reference
>> 
>> Thanks for the classification. This is helpful.
>> 
>> I'm not sure what you mean by (1f). You mean `this` can be embedded in an exception being thrown? Is that different from (2)?
>> 
>> Also, it seems to me that (3) is a special case of (2) - in the sense that you can imagine a reference array as a big object that has many fields as there are elements - so the same reasoning applies.
>> 
>> When looking at (2d) and (2e) the fact that Javac's AST is not in SSA form means that, yes, we need to track _expressions_ not just variables (e.g. for chains of methods calls, ternary operators and such).
>
>> I'm not sure what you mean by (1f). You mean this can be embedded in an exception being thrown? Is that different from (2)?
> 
> Yes, this would be a different case from any other that you'd have to handle in the code if you wanted to deal with it. 
> 
> An example of how this could happen would be:
> 
> public class ThrownThis extends RuntimeException {
> 
>     public ThrownThis(Object obj) {
>         try {
>             this.validate(obj);
>         } catch (RuntimeException e) {
>             e.mightLeak();  // LEAK HERE
>         }
>     }
> 
>     private void validate(Object obj) {
>         if (obj.hashCode() != 123)
>             throw this;
>     }
> 
>     public void mightLeak() {
>     }
> }
> 
> Of course, that's an absurd example and the likelihood that any random piece of actually code does that is negligible.
> 
> Regardless, I did briefly consider including handling for thrown exceptions but quickly decided it couldn't possibly be worth the trouble.
> 
> As a result, if you compile that example with `-Xlint:this-escape` you don't get a warning. No major loss!
> 
>> Also, it seems to me that (3) is a special case of (2) - in the sense that you can imagine a reference array as a big object that has many fields as there are elements - so the same reasoning applies.
> 
> Yes it's effectively the same thing, but fields and array elements are accessed by different mechanisms in Java, so from the point of the analyzer they have to be handled separately for that reason, which is why I broke them out.

> Yes, this would be a different case from any other that you'd have to handle in the code if you wanted to deal with it.
> 
> An example of how this could happen would be:
> 
> ```java
> public class ThrownThis extends RuntimeException {
> 
>     public ThrownThis(Object obj) {
>         try {
>             this.validate(obj);
>         } catch (RuntimeException e) {
>             e.mightLeak();  // LEAK HERE
>         }
>     }
> 
>     private void validate(Object obj) {
>         if (obj.hashCode() != 123)
>             throw this;
>     }
> 
>     public void mightLeak() {
>     }
> }
> ```
> 
Interesting example - I thought you might have been referring to a case where the class being analyzed was itself an exception.

Question - shouldn't we conclude that `this` leak when we see `throw this` ? E.g. what if the constructor did not have a `catch` (or if the catch was of a different type) ?
> Of course, that's an absurd example and the likelihood that any random piece of actually code does that is negligible.
> 
> Regardless, I did briefly consider including handling for thrown exceptions but quickly decided it couldn't possibly be worth the trouble.
> 
> As a result, if you compile that example with `-Xlint:this-escape` you don't get a warning. No major loss!
> 
> > Also, it seems to me that (3) is a special case of (2) - in the sense that you can imagine a reference array as a big object that has many fields as there are elements - so the same reasoning applies.
> 
> Yes it's effectively the same thing, but fields and array elements are accessed by different mechanisms in Java, so from the point of the analyzer they have to be handled separately for that reason, which is why I broke them out.

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

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


From duke at openjdk.org  Thu Jan 12 15:19:44 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 15:19:44 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <PWUpnB72y0RJmSv_2fTWPwtHxWfD_vbDK0Xo96H8cWo=.4e62955d-7a89-4f8f-9032-42cba96a8628@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <PWUpnB72y0RJmSv_2fTWPwtHxWfD_vbDK0Xo96H8cWo=.4e62955d-7a89-4f8f-9032-42cba96a8628@github.com>
Message-ID: <i7A6Abb4ofaGhdVFwfMMRfnW3m6sxTj7NovAlduTbm0=.1e93c191-bafa-4b37-9ec4-12e6532a745c@github.com>

On Thu, 12 Jan 2023 13:01:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 334:
> 
>> 332:         // of the stack trace of B. For example, if constructor Foo(int x) has a leak, and constructor
>> 333:         // Foo() invokes this(0), then emitting a warning for Foo() would be redundant.
>> 334:         final BiPredicate<DiagnosticPosition[], DiagnosticPosition[]> extendsAsPrefix = (warning1, warning2) -> {
> 
> Another strategy would be to give a single warning per leaking constructor.

We already impose a limit of at most one warning per constructor.

But for this limit what is technically meant by "per constructor" is "At most one warning per constructor, assuming that constructor is the one being analyzed (i.e., the one invoked by the subclass and not via `this()`)."

So that limitation doesn't stop a constructor from generating the same warning multiple times due to it being invoked indirectly by other constructors via `this()`. Those duplicate warnings are what the code above eliminates.

So this code only generates one warning, and it's reported for the second constructor:

public class DupWarn1 {

    public DupWarn1() {
        this(0);
    }

    public DupWarn1(int x) {
        this.mightLeak();
    }

    public void mightLeak() {
    }
}

DupWarn1.java:8: warning: [this-escape] possible 'this' escape before subclass is fully initialized
        this.mightLeak();
                      ^

This is appropriate. The leak is really in the second constructor; the first constructor has nothing to do with it. Reporting a leak for both constructors would be redundant.

An interesting side question: Is it possible to come up with an example where constructor A has a 'this' leak, and some other constructor B invokes `this()` to delegate to A, but when B delegates to A the leak occurs differently, or not at all?

Because of the "flood" analysis, and the fact that you can't pass 'this' references to `this()` or `super()` (these are static contexts), I don't think it's possible.

So in fact the deduplication will always apply whenever `this()` is involved.

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

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


From duke at openjdk.org  Thu Jan 12 15:29:30 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 15:29:30 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <G-1dQGlxNC0tMTi8ScMEdlxRBaK1ghCnUZw0X88GkiA=.748a82f4-8848-49cb-b6dc-54ebb30caa7e@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
 <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
 <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>
 <Z1YrthZISaALPMxL1F5GnGEdE7xgmw1cUY-O4ogt1DQ=.3c8554be-1739-4a1a-b4f5-4bde0e0c1a2b@github.com>
 <NsEcde65vTzRWfOo9UVogBDQNaoKIRnguLx3Y2IN2a4=.8005b605-5aa6-42b3-b4f7-9396a98081cf@github.com>
 <Cq9llhpGlvwFe1IYfakr-bd1POmSCTDfQ1kPFeTJQVI=.9048fd23-9fff-4941-8d51-e249f920783f@github.com>
 <Y1uRe5qwe5DMX5bi82veVOrQnP4JcLL94ZYLInWq9Is=.7973d572-e8ee-4b6c-bdd6-6ff9a488231a@github.com>
 <G-1dQGlxNC0tMTi8ScMEdlxRBaK1ghCnUZw0X88GkiA=.748a82f4-8848-49cb-b6dc-54ebb30caa7e@github.com>
Message-ID: <Tppxs2q5PpvfPZpAwGXNJHXLoXvsF5sgr2__feG7tsM=.37059060-38f7-4e0e-8c27-58a7b7d586d4@github.com>

On Thu, 12 Jan 2023 15:10:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Interesting example - I thought you might have been referring to a case where the class being analyzed was itself an exception.

Yes - although that example doesn't compile (oops!). Just replace `catch (RuntimeException e)` with `catch (ThrownThis e)` and it should.

> Question - shouldn't we conclude that this leak when we see throw this ? E.g. what if the constructor did not have a catch (or if the catch was of a different type) ?

A thorough analysis would evaluate whether the exception was caught or not. But you're right - since we're not doing a thorough analysis, we should immediately declare a leak anytime we see `throw x` where `x` is a possible direct or indirect reference. Of course, this scenario should be unlikely in normal code.

I will add a check for that.

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

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


From duke at openjdk.org  Thu Jan 12 16:06:28 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 16:06:28 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <nAV8hmaFOM_k77iuhmz3YoAd88Qq0pwb1YFInECVrWU=.fd7105ab-2c10-4372-a18b-daf13e1b0891@github.com>

On Thu, 12 Jan 2023 10:18:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 294:
> 
>> 292:                   !(this.currentClass.sym.isSealed() && this.currentClass.permitting.isEmpty()) &&
>> 293:                   !(this.currentClass.sym.owner.kind == MTH) &&
>> 294:                   !this.privateOuter;
> 
> Here, note that is the owner of the current class symbol is a method, that covers anonymous classes too, which is a part of `privateOuter`. So the only think we need to check here is whether "currentClass" is private, which is a simple predicate. No need to carry `privateOuter` I believe

Unless you explicitly declare a nested class `private`, it won't have the `ACC_PRIVATE` flag, even though it is "implicitly private" because it has a `private` enclosing class.

Example:

$ cat PrivateOuter.java 
public class PrivateOuter {
    private static class Inner1 {
        static class Inner2 {
        }
    }
}
$ javap -v PrivateOuter$Inner1$Inner2
Classfile /Users/archie/proj/jdk/flex-test/classes/PrivateOuter$Inner1$Inner2.class
  Last modified Jan 12, 2023; size 408 bytes
  SHA-256 checksum 51ba6d39a5e66df2a078761d6424acbea7a8e32b8451f6ca7d2af49889673b2c
  Compiled from "PrivateOuter.java"
class PrivateOuter$Inner1$Inner2
  minor version: 0
  major version: 63
  flags: (0x0020) ACC_SUPER
  this_class: #7                          // PrivateOuter$Inner1$Inner2
  super_class: #2                         // java/lang/Object
  ...


So we have to keep track of this "implicit privateness" manually, which is what the `privateOuter` flag is for.

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

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


From duke at openjdk.org  Thu Jan 12 16:24:37 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 16:24:37 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>

On Thu, 12 Jan 2023 10:25:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 218:
> 
>> 216:         new TreeScanner() {
>> 217: 
>> 218:             private Lint lint = ThisEscapeAnalyzer.this.lint;
> 
> On a first look I'm not sure about the granularity of suppression here. I believe that suppressing at the class level, or at the constructor level is enough. Allowing to further annotate var declarations and non-constructor methods, while doable, might actually be counter productive - in the sense that the annotation does not occur in the constructor (where you'd want to see it) but in some other method. I think the fact that a constructor is escaping (willingly) should be a visible thing. Something to consider.

Two things...

We need to support annotations on field declarations because their initializers are effectively mini-constructors. But we don't need it on local variables, parameters, etc. - too confusing.

For annotations on methods, yes it's debatable. It can be handy if you have e.g. an `init()` method that all of your constructors invoke. However, I agree it's also confusing, so I will remove.

But we should keep the notion that if a constructor invokes `this()`, and the invoked constructor has annotations suppressed, then we skip over the constructor invocation.

I will make these updates.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 304:
> 
>> 302: 
>> 303:             // We are looking for analyzable constructors only
>> 304:             final Symbol sym = entry.getKey();
> 
> This seems unused. And, if so, perhaps we only need a `Set<MethodInfo>`, not a map.

Thanks, you're right, the map keys are not used here. I'll clean up the loop.

But we still need a map, not a set, because the map is used elsewhere.

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

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


From duke at openjdk.org  Thu Jan 12 16:31:21 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 16:31:21 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <ELxQd5w_bHMh8ktW6Ce_gtGB8oMhpxruvG8MffRhEp4=.de3c9800-c167-4c16-ac93-7267cb3619d0@github.com>

On Thu, 12 Jan 2023 10:32:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> If we have a class with a private constructor and public static factory invoking said constructor, and the constructor makes this escape, isn't that an issue we should detect?

A static factory method will not create a subclassed instance, so there's no 'this' escape problem.

But I admit I completely missed factory methods as a potential thing to worry about.

Is it possible for a leak to be missed due to the use of a factory method?

Hmm. I can't immediately think of how, but if you can come up with an example please share.

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

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


From mcimadamore at openjdk.org  Thu Jan 12 16:46:31 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 16:46:31 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
Message-ID: <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>

On Thu, 12 Jan 2023 16:20:12 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 218:
>> 
>>> 216:         new TreeScanner() {
>>> 217: 
>>> 218:             private Lint lint = ThisEscapeAnalyzer.this.lint;
>> 
>> On a first look I'm not sure about the granularity of suppression here. I believe that suppressing at the class level, or at the constructor level is enough. Allowing to further annotate var declarations and non-constructor methods, while doable, might actually be counter productive - in the sense that the annotation does not occur in the constructor (where you'd want to see it) but in some other method. I think the fact that a constructor is escaping (willingly) should be a visible thing. Something to consider.
>
> Two things...
> 
> We need to support annotations on field declarations because their initializers are effectively mini-constructors. But we don't need it on local variables, parameters, etc. - too confusing.
> 
> For annotations on methods, yes it's debatable. It can be handy if you have e.g. an `init()` method that all of your constructors invoke. However, I agree it's also confusing, so I will remove.
> 
> But we should keep the notion that if a constructor invokes `this()`, and the invoked constructor has annotations suppressed, then we skip over the constructor invocation.
> 
> I will make these updates.

Yep - I guess there's a general theme of "where do we want the warnings to be reported". My general feeling is that reporting a warning on the constructor might be enough - but I see that you try to generate a warning in the exact spot where the leakage happens - which I'm not sure if it's ok, or too clever.

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 270:
>> 
>>> 268:                     final boolean analyzable = this.currentClassIsExternallyExtendable() &&
>>> 269:                         TreeInfo.isConstructor(tree) &&
>>> 270:                         !tree.sym.isPrivate() &&
>> 
>> Why aren't private constructors analyzed? If we have a class with a private constructor and public static factory invoking said constructor, and the constructor makes `this` escape, isn't that an issue we should detect?
>
>> If we have a class with a private constructor and public static factory invoking said constructor, and the constructor makes this escape, isn't that an issue we should detect?
> 
> A static factory method will not create a subclassed instance, so there's no 'this' escape problem.
> 
> But I admit I completely missed factory methods as a potential thing to worry about.
> 
> Is it possible for a leak to be missed due to the use of a factory method?
> 
> Hmm. I can't immediately think of how, but if you can come up with an example please share.

I guess what I'm thinking about:

class Foo {
    private Foo() {
        m(this);
    }
    
    public void m() { ... } // overridable
    
    static Foo makeFoo() { return new Foo(); }
}

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 294:
>> 
>>> 292:                   !(this.currentClass.sym.isSealed() && this.currentClass.permitting.isEmpty()) &&
>>> 293:                   !(this.currentClass.sym.owner.kind == MTH) &&
>>> 294:                   !this.privateOuter;
>> 
>> Here, note that is the owner of the current class symbol is a method, that covers anonymous classes too, which is a part of `privateOuter`. So the only think we need to check here is whether "currentClass" is private, which is a simple predicate. No need to carry `privateOuter` I believe
>
> Unless you explicitly declare a nested class `private`, it won't have the `ACC_PRIVATE` flag, even though it is "implicitly private" because it has a `private` enclosing class.
> 
> Example:
> 
> $ cat PrivateOuter.java 
> public class PrivateOuter {
>     private static class Inner1 {
>         static class Inner2 {
>         }
>     }
> }
> $ javap -v PrivateOuter$Inner1$Inner2
> Classfile /Users/archie/proj/jdk/flex-test/classes/PrivateOuter$Inner1$Inner2.class
>   Last modified Jan 12, 2023; size 408 bytes
>   SHA-256 checksum 51ba6d39a5e66df2a078761d6424acbea7a8e32b8451f6ca7d2af49889673b2c
>   Compiled from "PrivateOuter.java"
> class PrivateOuter$Inner1$Inner2
>   minor version: 0
>   major version: 63
>   flags: (0x0020) ACC_SUPER
>   this_class: #7                          // PrivateOuter$Inner1$Inner2
>   super_class: #2                         // java/lang/Object
>   ...
> 
> 
> So we have to keep track of this "implicit privateness" manually, which is what the `privateOuter` flag is for.

D'oh - missed the `|=` - so this keeps updating...

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

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


From duke at openjdk.org  Thu Jan 12 16:55:39 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 16:55:39 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <mYo4j7HX3pMUvpNwVh0Ym-_ZCS39PYrnRP7iP68PmRo=.77ca8af4-38ed-424f-990e-52e3f6ed33f2@github.com>

On Thu, 12 Jan 2023 10:48:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 227:
> 
>> 225:                 final boolean privateOuterPrev = this.privateOuter;
>> 226:                 final Lint lintPrev = this.lint;
>> 227:                 this.lint = this.lint.augment(tree.sym);
> 
> general stylistic comment - I see here and everywhere in this class `this.xyz` - this is not the norm in the rest of the javac codebase, and it would be better to replace it with just `xyz`

OK. I will reluctantly remove...

`<PointlessRantDoNotRead>`
> Why on earth wouldn't you want to make it clear which one of N outer classes a field comes from, and that it's a field, and not a variable declared somewhere off screen??
> 
> IMHO omitting 'this' qualifiers is effectively accepting the grave offense of code obfuscation in exchange for a tiny smidgen of brevity.
>
> It's definitely made it harder for me to read and understand the compiler, with all the levels of nesting it has.
> 
`</PointlessRantDoNotRead>`

I readily admit I'm probably in the minority on this and anyway it's a bikeshed thing so there's no point in debating it.

I will go with the flow :) though I feel a little sorry for the next person who has to read this code.

> From a documentation perspective it might carry a bit of value

Yes, that's the purpose - the `final` is for the human viewer, not the compiler. Just trying to be helpful to the next person.

But you're right it's inconsistent so I'll remove.

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

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


From duke at openjdk.org  Thu Jan 12 17:16:34 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 17:16:34 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>

On Thu, 12 Jan 2023 10:56:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 411:
> 
>> 409:         final boolean referenceExpressionNode;
>> 410:         switch (tree.getTag()) {
>> 411:         case CASE:
> 
> surprised to see `CASE` here - as that's not an expression

I put it there because of switch expressions and `yeild`... ?

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

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


From vromero at openjdk.org  Thu Jan 12 17:43:26 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 12 Jan 2023 17:43:26 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
Message-ID: <JQTEa2D1hzzMeKiAytv_7Qf16MMo4lNHl8VrmbX_V4o=.2d76542b-9bc3-42ef-a466-0cf5e8533028@github.com>

On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use the more appropriate Type comparison method Types.isSameType().
>  - Add some more comments to clarify how the analysis works.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 200:

> 198: //
> 199: 
> 200:     public void analyzeTree(Env<AttrContext> env) {

nit: this method could be removed in favor of the overloaded version below

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 204:

> 202:     }
> 203: 
> 204:     public void analyzeTree(Env<AttrContext> env, JCTree tree) {

nit: `env` parameter doesn't seem to be used could be dropped I think

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

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


From mcimadamore at openjdk.org  Thu Jan 12 17:43:30 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 17:43:30 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>
Message-ID: <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>

On Thu, 12 Jan 2023 17:13:55 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 411:
>> 
>>> 409:         final boolean referenceExpressionNode;
>>> 410:         switch (tree.getTag()) {
>>> 411:         case CASE:
>> 
>> surprised to see `CASE` here - as that's not an expression
>
> I put it there because of switch expressions and `yeild`... ?

Well, yield can... yield a value - `case` doesn't. So I'm confused. Also because the variable is called `referenceExpressionNode` and `CASE` is not an expression. Can `CASE` leave anything on the stack? YIELD does, but CASE?

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 454:
>> 
>>> 452: 
>>> 453:             // If the expression type is incompatible with 'this', discard it
>>> 454:             if (type != null && !this.isSubtype(this.targetClass.sym.type, type))
>> 
>> Instead of adding the direct reference, and then having to check if the reference needs to be removed, would it be possible not to add the reference in the first place if the types mismatch?
>
> No because (for example) what if you cast?
> 
> The thing you're casting might be compatible, but after the cast it might become incompatible.

Uhm. Turns out I probably did not understand the filter correctly, and now I'm more dubious about what it actually does. Say you have this hierarchy:


interface A { }
class B {
     B() {
          A a = (A)this;
          ...
      }
 }
 class C extends B implements A { }
 ```

Pathological case, I know. But the filtering will end up dropping the expression Ref on the floor, right? (because B and A are unrelated).

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

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


From duke at openjdk.org  Thu Jan 12 17:43:36 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 17:43:36 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <B8My4cqEflONOlWc75umJqxNRJrd0uFM6jHCF090Ln4=.85355133-7fc5-4afa-b7c5-f41242aee038@github.com>

On Thu, 12 Jan 2023 11:09:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 444:
> 
>> 442:         if (referenceExpressionNode) {
>> 443: 
>> 444:             // We treat instance methods as having a "value" equal to their instance
> 
> The comment is slightly misleading - e.g. I'd suggest clarifying "having a "value" whose type is the same as that of the class in which the method is defined"

Agreed - will fix.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 454:
> 
>> 452: 
>> 453:             // If the expression type is incompatible with 'this', discard it
>> 454:             if (type != null && !this.isSubtype(this.targetClass.sym.type, type))
> 
> Instead of adding the direct reference, and then having to check if the reference needs to be removed, would it be possible not to add the reference in the first place if the types mismatch?

No because (for example) what if you cast?

The thing you're casting might be compatible, but after the cast it might become incompatible.

> This will then determine how to interpret this in the context of that method analysis - e.g. when we see a JCIdent for this, we create a direct/indirect ExprRef based on what the receiver kind was. Correct?

Yes, exactly.

When we "invoke" a method, we "preload" the set of current references that the method is going to have when it starts. That "preload" step includes any references from (a) the method receiver (non-static methods only) and (b) method parameters.

To the extent the method receiver has a direct/indirect reference, that turns into a direct/indirect `ThisRef` during method execution. You can see this happen in the very next lines after what you quoted. But of course the method invocation (the "apply") could have been applied to any arbitrary expression as the receiver.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 817:
> 
>> 815:         // Methods - the "value" of a non-static method is a reference to its instance
>> 816:         final Symbol sym = tree.sym;
>> 817:         if (sym.kind == MTH) {
> 
> This is perhaps where filtering based on the declaring class could make sense (to avoid having to filter later) ? Perhaps this could also be centralized - e.g. whenever you create an ExprRef you also pass the type for it, and if the type matches that for the current class you create it and add to the list, otherwise you skip it.

Yes but see previous comment regarding casting.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 875:
> 
>> 873:         // Reference to this?
>> 874:         if (tree.name == names._this || tree.name == names._super) {
>> 875:             if (this.refs.contains(ThisRef.direct()))
> 
> This idiom occurs quite a lot. If I'm correct, this basically amounts at asking as to whether the receiver of the method we're currently evaluating is direct or not (which is an invariant, given a method body - e.g. for a given method this "fact" should stay the same). If that's the case, perhaps capturing this in a flag could be better - then you could have just have a single method e.g. `XYZRef.create(boolean direct)`, and remove the branching (here and elsewhere).

The code you quoted has nothing specifically to do with method invocations. This code is simply handing the evaluation of the expressions `this` and `super`. For example, `this` could just be a parameter we're passing to another method.

When `this` or `super` expressions are evaluated, the thing left on top of the stack is a direct/indirect reference (i.e., an `ExprRef`) exactly when the there is a direct/indirect reference of type `ThisRef` in the current reference set.

In cases where `this` is then "invoked", e.g., `this()`, the `ExprRef` (top of Java stack) becomes the method receiver, and when the method is "invoked" it turns back into a `ThisRef` (see earlier question).

Regarding the optimization you mention, in light of the above I'm not sure it would still work.

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

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


From duke at openjdk.org  Thu Jan 12 17:53:25 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 17:53:25 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <HeXkWGu5fgyW6A9Jm2h3iylOary4wkYTPEcwEYaigzs=.3941421d-e1dc-489c-afef-a116faa5a592@github.com>

On Thu, 12 Jan 2023 12:15:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 175:
> 
>> 173:     private DiagnosticPosition[] pendingWarning;
>> 174: 
>> 175: // These fields are scoped to the CONSTRUCTOR OR INVOKED METHOD BEING ANALYZED
> 
> Watch out for "all caps"

Will fix.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 900:
> 
>> 898:             final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
>> 899:             final Type methodOwnerType = sym.owner.type;
>> 900:             if (this.isSubtype(currentClassType, methodOwnerType)) {
> 
> I believe what you need here is not subtyping but subclassing - see `Symbol.isSubclass`

Hmm, I tried using `Symbol.isSubclass()` but it caused test failures. Obviously I don't quite know what I'm doing and I'm loathe to break what is already working. Do you have a suggested patch?

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 909:
> 
>> 907: 
>> 908:             // Check for implicit outer 'this' reference
>> 909:             if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
> 
> Similarly here - look for `Symbol.isEnclosedBy`

Same comment as previous: I don't quite know what I'm doing and I'm loathe to break what is already working. Do you have a suggested patch?

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

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


From duke at openjdk.org  Thu Jan 12 18:00:36 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 18:00:36 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <fgNy_jMv_g-0_VgfhgCf2JVUJjfCoqum2cmC55cRwFQ=.d1dbfa25-3790-48e0-bbd0-e4a5af2d8ed8@github.com>

On Thu, 12 Jan 2023 12:17:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> There is a concept of push/popScope and then there's a separate concept of call stack (which is just a list of diagnostic position up to the point). I wonder if this could be better modeled by using a single class e.g. Scope/Frame which has a diagnostic position, plus other useful things.

I think that would be more confusing, because they're really two different animals.

Scopes only have meaning within a single method. They simply serve to bracket the lifetimes of `VarRef` references, following Java curly brace scope. When you "invoke" a method, you put aside the current stack of scopes and start over with an empty scope stack. They don't bridge between methods.

Call stacks are just a list of method+code position therein, and they exist outside of any single method. They have nothing to do with Java scopes defined by curly braces.

> Perhaps it might even be helpful to have a ref set on each scope, so that you don't have to attach a "depth" to each ref - the depth of the ref would be determined by the "scope" in which it appears.

That's another way to skin the same cat... in fact I had a design like that before but then realized it was a lot simpler to just carry around one `RefSet`.

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

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


From duke at openjdk.org  Thu Jan 12 18:09:27 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 18:09:27 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <tHD8s5avHxuK-kI1PNds3iq8b29x0QuOkQiz1Brxtq0=.6d21f5e2-8866-43fb-92eb-155d2f2ca58b@github.com>

On Thu, 12 Jan 2023 12:26:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Do we really need a set for this?

There are surely other ways to model things. But I got myself really confused trying to build more complicated models.

What I ended up with is this simple model that works:
* There is a set of `Ref` subclasses that model the various types of 'this' references possible: `OuterRef`, `ExprRef`, etc.
* There is a singleton `this.refs`, which just is a `Set<Ref>`, containing the 'this' references that are alive at the current moment
* As we "execute" code, all we need to do is update the `this.refs` based on what the current bit of code does

E.g....

When a variable is assigned a value that has a reference, we add a `VarRef` for that variable.

When we leave a scope, we remove any `Ref`'s that are no longer in scope.

Before executing a method, we add `Ref`'s for the method receiver and parameter.

When we return from a non-void method, we convert any `ReturnRef` into a `ExprRef`.

Etc.

THAT I can understand.

I don't see converting the above into a bitmap or whatever as worth the additional complexity. We're not programming in perl here.

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

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


From duke at openjdk.org  Thu Jan 12 18:16:25 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 18:16:25 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <JQTEa2D1hzzMeKiAytv_7Qf16MMo4lNHl8VrmbX_V4o=.2d76542b-9bc3-42ef-a466-0cf5e8533028@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <JQTEa2D1hzzMeKiAytv_7Qf16MMo4lNHl8VrmbX_V4o=.2d76542b-9bc3-42ef-a466-0cf5e8533028@github.com>
Message-ID: <1r69eKftXv6ZlGQP76mNrfgbldbDcMxhnyVOQ8oUV7U=.8facaf51-1f7e-486a-912e-a9a5912b7d88@github.com>

On Thu, 12 Jan 2023 17:39:05 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 200:
> 
>> 198: //
>> 199: 
>> 200:     public void analyzeTree(Env<AttrContext> env) {
> 
> nit: this method could be removed in favor of the overloaded version below

Thanks - will fix.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 204:
> 
>> 202:     }
>> 203: 
>> 204:     public void analyzeTree(Env<AttrContext> env, JCTree tree) {
> 
> nit: `env` parameter doesn't seem to be used could be dropped I think

Thanks - will fix.

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

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


From mcimadamore at openjdk.org  Thu Jan 12 18:16:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 18:16:27 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <HeXkWGu5fgyW6A9Jm2h3iylOary4wkYTPEcwEYaigzs=.3941421d-e1dc-489c-afef-a116faa5a592@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <HeXkWGu5fgyW6A9Jm2h3iylOary4wkYTPEcwEYaigzs=.3941421d-e1dc-489c-afef-a116faa5a592@github.com>
Message-ID: <OlSYF58dAKzpCOTvsW0Z3ABoFiMrzXbkxiVBPrO0Huo=.069bfdc8-e2d3-470f-b6bf-945e3a1e9e8f@github.com>

On Thu, 12 Jan 2023 17:48:37 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 909:
>> 
>>> 907: 
>>> 908:             // Check for implicit outer 'this' reference
>>> 909:             if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
>> 
>> Similarly here - look for `Symbol.isEnclosedBy`
>
> Same comment as previous: I don't quite know what I'm doing and I'm loathe to break what is already working. Do you have a suggested patch?

I can't seem to be able to run tests - I get failures in the build:


* For target support_test_micro_tools-classes__the.BUILD_INDIFY_batch:

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

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


From duke at openjdk.org  Thu Jan 12 18:16:31 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 18:16:31 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <DwYRtG4qsOtzZBk93m54shMuGu2slfVgQD_DTz-XHXk=.84e50496-fcc5-43f6-92fa-590d458a40cd@github.com>

On Thu, 12 Jan 2023 12:28:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This might also be related with the fact that we deal with return values in different ways than with e.g. values returned from a nested scope (where we just pop, and then copy all pending expression to the outer depth).

Yes, a method return value that represents a reference is an `ExprRef` just before the `return` is actually executed, but then it turns into a `ReturnRef`.

A `ReturnRef` is really just a yellow sticky note that reminds us "Hey whenever you finish 'executing' this method, remember that there is a reference in its return value".

> This might also be related with the fact that we deal with return values in different ways than with e.g. values returned from a nested scope (where we just pop, and then copy all pending expression to the outer depth).

Exactly.

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

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


From mcimadamore at openjdk.org  Thu Jan 12 18:21:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 18:21:22 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <OlSYF58dAKzpCOTvsW0Z3ABoFiMrzXbkxiVBPrO0Huo=.069bfdc8-e2d3-470f-b6bf-945e3a1e9e8f@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <HeXkWGu5fgyW6A9Jm2h3iylOary4wkYTPEcwEYaigzs=.3941421d-e1dc-489c-afef-a116faa5a592@github.com>
 <OlSYF58dAKzpCOTvsW0Z3ABoFiMrzXbkxiVBPrO0Huo=.069bfdc8-e2d3-470f-b6bf-945e3a1e9e8f@github.com>
Message-ID: <1vfnyE9dnZELUp1To60nQYEUIre7g5pcfXHKKHOug0I=.9af24b57-2627-45d8-a7cc-1b4235e99237@github.com>

On Thu, 12 Jan 2023 18:11:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Same comment as previous: I don't quite know what I'm doing and I'm loathe to break what is already working. Do you have a suggested patch?
>
> I can't seem to be able to run tests - I get failures in the build:
> 
> 
> * For target support_test_micro_tools-classes__the.BUILD_INDIFY_batch:

This patch:


diff --git a/make/test/BuildMicrobenchmark.gmk b/make/test/BuildMicrobenchmark.gmk
index 1c89328a388..7c3f0293edc 100644
--- a/make/test/BuildMicrobenchmark.gmk
+++ b/make/test/BuildMicrobenchmark.gmk
@@ -76,7 +76,7 @@ $(eval $(call SetupJavaCompilation, BUILD_INDIFY, \
     TARGET_RELEASE := $(TARGET_RELEASE_BOOTJDK), \
     SRC := $(TOPDIR)/test/jdk/java/lang/invoke, \
     INCLUDE_FILES := indify/Indify.java, \
-    DISABLED_WARNINGS := rawtypes serial options, \
+    DISABLED_WARNINGS := this-escape rawtypes serial options, \
     BIN := $(MICROBENCHMARK_TOOLS_CLASSES), \
     JAVAC_FLAGS := -XDstringConcat=inline -Xprefer:newer, \
 ))
@@ -91,7 +91,7 @@ $(eval $(call SetupJavaCompilation, BUILD_JDK_MICROBENCHMARK, \
     TARGET_RELEASE := $(TARGET_RELEASE_NEWJDK_UPGRADED), \
     SMALL_JAVA := false, \
     CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \
-    DISABLED_WARNINGS := processing rawtypes cast serial preview, \
+    DISABLED_WARNINGS := this-escape processing rawtypes cast serial preview, \
     SRC := $(MICROBENCHMARK_SRC), \
     BIN := $(MICROBENCHMARK_CLASSES), \
     JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
index 9d35c2fbc0a..4e2b1e558e7 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
@@ -897,6 +897,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
             // Check for implicit 'this' reference
             final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
             final Type methodOwnerType = sym.owner.type;
+            //if (currentClassType.tsym.isSubClass(sym.owner, types)) {
             if (this.isSubtype(currentClassType, methodOwnerType)) {
                 if (this.refs.contains(ThisRef.direct()))
                     this.refs.add(ExprRef.direct(this.depth));
@@ -906,6 +907,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
             }
 
             // Check for implicit outer 'this' reference
+            // if (currentClassType.tsym.isEnclosedBy((ClassSymbol)sym.owner)) {
             if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
                 if (this.refs.contains(OuterRef.direct()))
                     this.refs.add(ExprRef.direct(this.depth));


Fixes the build failure.

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

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


From duke at openjdk.org  Thu Jan 12 18:40:28 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 18:40:28 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
Message-ID: <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>

On Thu, 12 Jan 2023 16:40:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I guess what I'm thinking about:

No leak is possible in that example.
* `new Foo()` creates an instance of `Foo` (not a subclass of `Foo`) therefore `m()` is not overridden
* Any subclass of `Foo` that may exist in the outside world cannot use the `Foo()` constructor that leaks because it's private

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

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


From mcimadamore at openjdk.org  Thu Jan 12 18:43:21 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 18:43:21 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <1vfnyE9dnZELUp1To60nQYEUIre7g5pcfXHKKHOug0I=.9af24b57-2627-45d8-a7cc-1b4235e99237@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <HeXkWGu5fgyW6A9Jm2h3iylOary4wkYTPEcwEYaigzs=.3941421d-e1dc-489c-afef-a116faa5a592@github.com>
 <OlSYF58dAKzpCOTvsW0Z3ABoFiMrzXbkxiVBPrO0Huo=.069bfdc8-e2d3-470f-b6bf-945e3a1e9e8f@github.com>
 <1vfnyE9dnZELUp1To60nQYEUIre7g5pcfXHKKHOug0I=.9af24b57-2627-45d8-a7cc-1b4235e99237@github.com>
Message-ID: <H5V8WGugbzMju7YhCvJlbks3UYFt4968R2xBT2gDy2E=.4d938252-59a9-4424-ace2-d62d9ec58388@github.com>

On Thu, 12 Jan 2023 18:18:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I can't seem to be able to run tests - I get failures in the build:
>> 
>> 
>> * For target support_test_micro_tools-classes__the.BUILD_INDIFY_batch:
>
> This patch:
> 
> 
> diff --git a/make/test/BuildMicrobenchmark.gmk b/make/test/BuildMicrobenchmark.gmk
> index 1c89328a388..7c3f0293edc 100644
> --- a/make/test/BuildMicrobenchmark.gmk
> +++ b/make/test/BuildMicrobenchmark.gmk
> @@ -76,7 +76,7 @@ $(eval $(call SetupJavaCompilation, BUILD_INDIFY, \
>      TARGET_RELEASE := $(TARGET_RELEASE_BOOTJDK), \
>      SRC := $(TOPDIR)/test/jdk/java/lang/invoke, \
>      INCLUDE_FILES := indify/Indify.java, \
> -    DISABLED_WARNINGS := rawtypes serial options, \
> +    DISABLED_WARNINGS := this-escape rawtypes serial options, \
>      BIN := $(MICROBENCHMARK_TOOLS_CLASSES), \
>      JAVAC_FLAGS := -XDstringConcat=inline -Xprefer:newer, \
>  ))
> @@ -91,7 +91,7 @@ $(eval $(call SetupJavaCompilation, BUILD_JDK_MICROBENCHMARK, \
>      TARGET_RELEASE := $(TARGET_RELEASE_NEWJDK_UPGRADED), \
>      SMALL_JAVA := false, \
>      CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \
> -    DISABLED_WARNINGS := processing rawtypes cast serial preview, \
> +    DISABLED_WARNINGS := this-escape processing rawtypes cast serial preview, \
>      SRC := $(MICROBENCHMARK_SRC), \
>      BIN := $(MICROBENCHMARK_CLASSES), \
>      JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
> index 9d35c2fbc0a..4e2b1e558e7 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
> @@ -897,6 +897,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>              // Check for implicit 'this' reference
>              final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
>              final Type methodOwnerType = sym.owner.type;
> +            //if (currentClassType.tsym.isSubClass(sym.owner, types)) {
>              if (this.isSubtype(currentClassType, methodOwnerType)) {
>                  if (this.refs.contains(ThisRef.direct()))
>                      this.refs.add(ExprRef.direct(this.depth));
> @@ -906,6 +907,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>              }
>  
>              // Check for implicit outer 'this' reference
> +            // if (currentClassType.tsym.isEnclosedBy((ClassSymbol)sym.owner)) {
>              if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
>                  if (this.refs.contains(OuterRef.direct()))
>                      this.refs.add(ExprRef.direct(this.depth));
> 
> 
> Fixes the build failure.

This patch passes all tests:


diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
index 9d35c2fbc0a..e755c54d0c8 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
@@ -451,7 +451,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
             }
 
             // If the expression type is incompatible with 'this', discard it
-            if (type != null && !this.isSubtype(this.targetClass.sym.type, type))
+            if (type != null && !this.targetClass.sym.isSubClass(type.tsym, types))
                 this.refs.remove(ExprRef.direct(this.depth));
         }
     }
@@ -672,7 +672,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
         if (explicitOuterThis != null) {
             this.scan(explicitOuterThis);
             this.refs.removeExprs(this.depth, direct -> outerRefs.add(new OuterRef(direct)));
-        } else if (this.types.hasOuterClass(type, this.methodClass.type)) {
+        } else if (type.tsym.isEnclosedBy(this.methodClass.sym)) {
             if (this.refs.contains(ThisRef.direct()))
                 outerRefs.add(OuterRef.direct());
             if (this.refs.contains(ThisRef.indirect()))
@@ -801,9 +801,8 @@ class ThisEscapeAnalyzer extends TreeScanner {
         // Explicit outer 'this' reference?
         final Type selectedType = this.types.erasure(tree.selected.type);
         if (selectedType.hasTag(CLASS)) {
-            final Type.ClassType selectedClassType = (Type.ClassType)selectedType;
             if (tree.name == this.names._this &&
-                this.types.hasOuterClass(currentClassType, selectedClassType)) {
+                currentClassType.tsym.isEnclosedBy((ClassSymbol)selectedType.tsym)) {
                 if (this.refs.contains(OuterRef.direct()))
                     this.refs.add(ExprRef.direct(this.depth));
                 if (this.refs.contains(OuterRef.indirect()))
@@ -895,9 +894,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
             final MethodSymbol sym = (MethodSymbol)tree.sym;
 
             // Check for implicit 'this' reference
-            final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
-            final Type methodOwnerType = sym.owner.type;
-            if (this.isSubtype(currentClassType, methodOwnerType)) {
+            if (methodClass.sym.isSubClass(sym.owner, types)) {
                 if (this.refs.contains(ThisRef.direct()))
                     this.refs.add(ExprRef.direct(this.depth));
                 if (this.refs.contains(ThisRef.indirect()))
@@ -906,7 +903,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
             }
 
             // Check for implicit outer 'this' reference
-            if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
+            if (methodClass.sym.isEnclosedBy((ClassSymbol)sym.owner)) {
                 if (this.refs.contains(OuterRef.direct()))
                     this.refs.add(ExprRef.direct(this.depth));


Btw, I believe a similar trick can be used in TreeInfo.isExplicitThisReference. If I'm correct, `hasOuterClass` should probably be removed as it duplicates already existing functionality. 

Since I'm bringing this up, as TreeInfo.isExplicitThisReference is only used by the new analyzer, it would be cleaner if it was defined there, at least until it's clear it might be needed by some other client.

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

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


From mcimadamore at openjdk.org  Thu Jan 12 18:51:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 18:51:33 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
Message-ID: <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>

On Thu, 12 Jan 2023 18:37:06 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> I guess what I'm thinking about:
>> 
>> class Foo {
>>     private Foo() {
>>         m(this);
>>     }
>>     
>>     public void m() { ... } // overridable
>>     
>>     static Foo makeFoo() { return new Foo(); }
>> }
>
>> I guess what I'm thinking about:
> 
> No leak is possible in that example.
> * `new Foo()` creates an instance of `Foo` (not a subclass of `Foo`) therefore `m()` is not overridden
> * Any subclass of `Foo` that may exist in the outside world cannot use the `Foo()` constructor that leaks because it's private

but what if `m` is a static method in a separate compilation unit? Should it be able to observe a partially initialized Foo?

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

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


From duke at openjdk.org  Thu Jan 12 19:04:22 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 19:04:22 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>
 <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>
Message-ID: <mnzreiQ4ic41rCo5WRuC5WzyAVWb58ofih-n7PDjb3w=.9d9d8237-5b64-4e8a-9f3a-bc915d6504ea@github.com>

On Thu, 12 Jan 2023 17:29:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I put it there because of switch expressions and `yeild`... ?
>
> Well, yield can... yield a value - `case` doesn't. So I'm confused. Also because the variable is called `referenceExpressionNode` and `CASE` is not an expression. Can `CASE` leave anything on the stack? YIELD does, but CASE?

It's just an artifact of the way switch expressions are handled:

    @Override
    public void visitSwitchExpression(JCSwitchExpression tree) {
        visitScoped(tree, true, t -> {
            scan(t.selector);
            refs.discardExprs(depth);
            RefSet<ExprRef> combinedRefs = new RefSet<>();
            for (List<JCCase> cases = t.cases; cases.nonEmpty(); cases = cases.tail) {
                scan(cases.head);
                combinedRefs.addAll(refs.removeExprs(depth));
            }
            refs.addAll(combinedRefs);
        });
    }

    @Override
    public void visitCase(JCCase tree) {
        scan(tree.stats);          // no need to scan labels
    }

After scanning a switch expression case, the `yield`'ed value will be on the top of the stack.

Then `visitCase` does NOT remove it, so that it can be picked up and removed by `visitSwitchExpression()`.

But this can be cleaned up a little bit, by having `visitSwitchExpression()` not delegate to `visitCase()` but rather iterate through the case statements itself directly. Then we can remove the `CASE` as you suggest.

Also I realized we need to handle `yield`'ed values like `return` values, i.e., collect and remember them until the entire case is complete.

I'll fix.

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

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


From mcimadamore at openjdk.org  Thu Jan 12 19:04:25 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 19:04:25 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <B8My4cqEflONOlWc75umJqxNRJrd0uFM6jHCF090Ln4=.85355133-7fc5-4afa-b7c5-f41242aee038@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <B8My4cqEflONOlWc75umJqxNRJrd0uFM6jHCF090Ln4=.85355133-7fc5-4afa-b7c5-f41242aee038@github.com>
Message-ID: <Q9_WG6FXdZ8vKHvpaxQgB7bqSMmgr5B3K6ontsX2tYc=.98807ef6-c1a7-4cd8-8acf-4f79ed623ccb@github.com>

On Thu, 12 Jan 2023 17:33:48 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 875:
>> 
>>> 873:         // Reference to this?
>>> 874:         if (tree.name == names._this || tree.name == names._super) {
>>> 875:             if (this.refs.contains(ThisRef.direct()))
>> 
>> This idiom occurs quite a lot. If I'm correct, this basically amounts at asking as to whether the receiver of the method we're currently evaluating is direct or not (which is an invariant, given a method body - e.g. for a given method this "fact" should stay the same). If that's the case, perhaps capturing this in a flag could be better - then you could have just have a single method e.g. `XYZRef.create(boolean direct)`, and remove the branching (here and elsewhere).
>
> The code you quoted has nothing specifically to do with method invocations. This code is simply handing the evaluation of the expressions `this` and `super`. For example, `this` could just be a parameter we're passing to another method.
> 
> When `this` or `super` expressions are evaluated, the thing left on top of the stack is a direct/indirect reference (i.e., an `ExprRef`) exactly when the there is a direct/indirect reference of type `ThisRef` in the current reference set.
> 
> In cases where `this` is then "invoked", e.g., `this()`, the `ExprRef` (top of Java stack) becomes the method receiver, and when the method is "invoked" it turns back into a `ThisRef` (see earlier question).
> 
> Regarding the optimization you mention, in light of the above I'm not sure it would still work.

My point is about who puts ThisRef in the set to begin with. It seems to me that ThisRef is put there at the start of a method analysis. After which, there's several code points where we say "if there's a direct ThisRef in the set, do this, otherwise, if there's an indirect ThisRef in the set, do that". But the ThisRef (whether indirect or direct) seems set once and for all (when we start the analysis, and then inside visitApply). 

There is also this bit in `visitReference`:


case SUPER:
            if (this.refs.contains(ThisRef.direct()))
                receiverRefs.add(ThisRef.direct());
            if (this.refs.contains(ThisRef.indirect()))
                receiverRefs.add(ThisRef.indirect());
            break;


But this doesn't change what I'm saying - there seems to be a general property when we execute this analysis which says whether the current execution context has a direct `this` or not. This seems to me better captured with a boolean, which is then fed back to all the other various downstream ref creation.

The main observation, at least for me, is that the code unifies everything under refs, when in reality there are different aspects:

* the set of variables that can point to this, whether directly or indirectly (this is truly a set)
* whether the current context has a direct or indirect this (this seems more a flag to me)
* whether the expression on top of stack is direct/indirect this reference or not (again, 3 possible values here) - but granted, there `depth` here to take into account, so you probably end up with a set (given that we don't want to model a scope with its own set)

When reading the code, seeing set expression like containment checks or removals for things that doesn't seem to be truly sets (unless I'm missing something) was genuinely confusing me.

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

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


From duke at openjdk.org  Thu Jan 12 19:15:20 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 19:15:20 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>
 <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>
Message-ID: <db_e6O3GAPZPRU1kJGawP19tAb-DmiNduGa51LCD4VE=.1b70448a-7b9b-4d99-9828-e3186c13a73c@github.com>

On Thu, 12 Jan 2023 17:40:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> But the filtering will end up dropping the expression Ref on the floor, right? (because B and A are unrelated).

Ah, I see what you mean.

Here's a more complete example:

public class CastLeak {

    public CastLeak() {
        ((CastLeak)(Runnable)this).mightLeak();
    }

    public void mightLeak() {
    }
}

That would be a leak for any subclass that implements `Runnable`. Yet no warning is generated.

So the filtering by expression type is going to potentially create false negatives. But it also eliminates a bunch of false positives. And the false negatives are probably all somewhat pathological like the example above.

So I still think it's worth doing.

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

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


From duke at openjdk.org  Thu Jan 12 19:27:24 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 19:27:24 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <H5V8WGugbzMju7YhCvJlbks3UYFt4968R2xBT2gDy2E=.4d938252-59a9-4424-ace2-d62d9ec58388@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <HeXkWGu5fgyW6A9Jm2h3iylOary4wkYTPEcwEYaigzs=.3941421d-e1dc-489c-afef-a116faa5a592@github.com>
 <OlSYF58dAKzpCOTvsW0Z3ABoFiMrzXbkxiVBPrO0Huo=.069bfdc8-e2d3-470f-b6bf-945e3a1e9e8f@github.com>
 <1vfnyE9dnZELUp1To60nQYEUIre7g5pcfXHKKHOug0I=.9af24b57-2627-45d8-a7cc-1b4235e99237@github.com>
 <H5V8WGugbzMju7YhCvJlbks3UYFt4968R2xBT2gDy2E=.4d938252-59a9-4424-ace2-d62d9ec58388@github.com>
Message-ID: <cssouTFgoltPdZIh3eFqQvVsIji6eDVyCe6jSw_eFUQ=.726f3cb9-3d71-448c-8f41-5f122c72c272@github.com>

On Thu, 12 Jan 2023 18:40:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch:
>> 
>> 
>> diff --git a/make/test/BuildMicrobenchmark.gmk b/make/test/BuildMicrobenchmark.gmk
>> index 1c89328a388..7c3f0293edc 100644
>> --- a/make/test/BuildMicrobenchmark.gmk
>> +++ b/make/test/BuildMicrobenchmark.gmk
>> @@ -76,7 +76,7 @@ $(eval $(call SetupJavaCompilation, BUILD_INDIFY, \
>>      TARGET_RELEASE := $(TARGET_RELEASE_BOOTJDK), \
>>      SRC := $(TOPDIR)/test/jdk/java/lang/invoke, \
>>      INCLUDE_FILES := indify/Indify.java, \
>> -    DISABLED_WARNINGS := rawtypes serial options, \
>> +    DISABLED_WARNINGS := this-escape rawtypes serial options, \
>>      BIN := $(MICROBENCHMARK_TOOLS_CLASSES), \
>>      JAVAC_FLAGS := -XDstringConcat=inline -Xprefer:newer, \
>>  ))
>> @@ -91,7 +91,7 @@ $(eval $(call SetupJavaCompilation, BUILD_JDK_MICROBENCHMARK, \
>>      TARGET_RELEASE := $(TARGET_RELEASE_NEWJDK_UPGRADED), \
>>      SMALL_JAVA := false, \
>>      CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \
>> -    DISABLED_WARNINGS := processing rawtypes cast serial preview, \
>> +    DISABLED_WARNINGS := this-escape processing rawtypes cast serial preview, \
>>      SRC := $(MICROBENCHMARK_SRC), \
>>      BIN := $(MICROBENCHMARK_CLASSES), \
>>      JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
>> index 9d35c2fbc0a..4e2b1e558e7 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
>> @@ -897,6 +897,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>>              // Check for implicit 'this' reference
>>              final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
>>              final Type methodOwnerType = sym.owner.type;
>> +            //if (currentClassType.tsym.isSubClass(sym.owner, types)) {
>>              if (this.isSubtype(currentClassType, methodOwnerType)) {
>>                  if (this.refs.contains(ThisRef.direct()))
>>                      this.refs.add(ExprRef.direct(this.depth));
>> @@ -906,6 +907,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>>              }
>>  
>>              // Check for implicit outer 'this' reference
>> +            // if (currentClassType.tsym.isEnclosedBy((ClassSymbol)sym.owner)) {
>>              if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
>>                  if (this.refs.contains(OuterRef.direct()))
>>                      this.refs.add(ExprRef.direct(this.depth));
>> 
>> 
>> Fixes the build failure.
>
> This patch passes all tests:
> 
> 
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
> index 9d35c2fbc0a..e755c54d0c8 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
> @@ -451,7 +451,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>              }
>  
>              // If the expression type is incompatible with 'this', discard it
> -            if (type != null && !this.isSubtype(this.targetClass.sym.type, type))
> +            if (type != null && !this.targetClass.sym.isSubClass(type.tsym, types))
>                  this.refs.remove(ExprRef.direct(this.depth));
>          }
>      }
> @@ -672,7 +672,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>          if (explicitOuterThis != null) {
>              this.scan(explicitOuterThis);
>              this.refs.removeExprs(this.depth, direct -> outerRefs.add(new OuterRef(direct)));
> -        } else if (this.types.hasOuterClass(type, this.methodClass.type)) {
> +        } else if (type.tsym.isEnclosedBy(this.methodClass.sym)) {
>              if (this.refs.contains(ThisRef.direct()))
>                  outerRefs.add(OuterRef.direct());
>              if (this.refs.contains(ThisRef.indirect()))
> @@ -801,9 +801,8 @@ class ThisEscapeAnalyzer extends TreeScanner {
>          // Explicit outer 'this' reference?
>          final Type selectedType = this.types.erasure(tree.selected.type);
>          if (selectedType.hasTag(CLASS)) {
> -            final Type.ClassType selectedClassType = (Type.ClassType)selectedType;
>              if (tree.name == this.names._this &&
> -                this.types.hasOuterClass(currentClassType, selectedClassType)) {
> +                currentClassType.tsym.isEnclosedBy((ClassSymbol)selectedType.tsym)) {
>                  if (this.refs.contains(OuterRef.direct()))
>                      this.refs.add(ExprRef.direct(this.depth));
>                  if (this.refs.contains(OuterRef.indirect()))
> @@ -895,9 +894,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>              final MethodSymbol sym = (MethodSymbol)tree.sym;
>  
>              // Check for implicit 'this' reference
> -            final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
> -            final Type methodOwnerType = sym.owner.type;
> -            if (this.isSubtype(currentClassType, methodOwnerType)) {
> +            if (methodClass.sym.isSubClass(sym.owner, types)) {
>                  if (this.refs.contains(ThisRef.direct()))
>                      this.refs.add(ExprRef.direct(this.depth));
>                  if (this.refs.contains(ThisRef.indirect()))
> @@ -906,7 +903,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>              }
>  
>              // Check for implicit outer 'this' reference
> -            if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
> +            if (methodClass.sym.isEnclosedBy((ClassSymbol)sym.owner)) {
>                  if (this.refs.contains(OuterRef.direct()))
>                      this.refs.add(ExprRef.direct(this.depth));
> 
> 
> Btw, I believe a similar trick can be used in TreeInfo.isExplicitThisReference. If I'm correct, `hasOuterClass` should probably be removed as it duplicates already existing functionality. 
> 
> Since I'm bringing this up, as TreeInfo.isExplicitThisReference is only used by the new analyzer, it would be cleaner if it was defined there, at least until it's clear it might be needed by some other client.

Weird. I don't get that build failure.

Neither does github... I have been relying on the github build "Actions" succeeding to determine if "the build works" and according to that it is building.

I will add the `DISABLED_WARNINGS` in any case.

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

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


From duke at openjdk.org  Thu Jan 12 21:07:28 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 21:07:28 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
Message-ID: <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>

On Thu, 12 Jan 2023 18:48:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> I guess what I'm thinking about:
>> 
>> No leak is possible in that example.
>> * `new Foo()` creates an instance of `Foo` (not a subclass of `Foo`) therefore `m()` is not overridden
>> * Any subclass of `Foo` that may exist in the outside world cannot use the `Foo()` constructor that leaks because it's private
>
> but what if `m` is a static method in a separate compilation unit? Should it be able to observe a partially initialized Foo?

Caring about the proper initialization of any class in the _current_ compilation unit is an explicit non-goal.

We only care about bugs where a superclass and subclass are in separate compilation units.

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

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


From duke at openjdk.org  Thu Jan 12 21:07:30 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 21:07:30 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <cssouTFgoltPdZIh3eFqQvVsIji6eDVyCe6jSw_eFUQ=.726f3cb9-3d71-448c-8f41-5f122c72c272@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <HeXkWGu5fgyW6A9Jm2h3iylOary4wkYTPEcwEYaigzs=.3941421d-e1dc-489c-afef-a116faa5a592@github.com>
 <OlSYF58dAKzpCOTvsW0Z3ABoFiMrzXbkxiVBPrO0Huo=.069bfdc8-e2d3-470f-b6bf-945e3a1e9e8f@github.com>
 <1vfnyE9dnZELUp1To60nQYEUIre7g5pcfXHKKHOug0I=.9af24b57-2627-45d8-a7cc-1b4235e99237@github.com>
 <H5V8WGugbzMju7YhCvJlbks3UYFt4968R2xBT2gDy2E=.4d938252-59a9-4424-ace2-d62d9ec58388@github.com>
 <cssouTFgoltPdZIh3eFqQvVsIji6eDVyCe6jSw_eFUQ=.726f3cb9-3d71-448c-8f41-5f122c72c272@github.com>
Message-ID: <S64E1MdWn5ot_6NEsqBBIlT5X9Fqw7HjtRnpsfv9Hds=.38f15307-7535-4840-960d-1e9e3b225989@github.com>

On Thu, 12 Jan 2023 19:24:50 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This patch passes all tests:
>> 
>> 
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
>> index 9d35c2fbc0a..e755c54d0c8 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
>> @@ -451,7 +451,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>>              }
>>  
>>              // If the expression type is incompatible with 'this', discard it
>> -            if (type != null && !this.isSubtype(this.targetClass.sym.type, type))
>> +            if (type != null && !this.targetClass.sym.isSubClass(type.tsym, types))
>>                  this.refs.remove(ExprRef.direct(this.depth));
>>          }
>>      }
>> @@ -672,7 +672,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>>          if (explicitOuterThis != null) {
>>              this.scan(explicitOuterThis);
>>              this.refs.removeExprs(this.depth, direct -> outerRefs.add(new OuterRef(direct)));
>> -        } else if (this.types.hasOuterClass(type, this.methodClass.type)) {
>> +        } else if (type.tsym.isEnclosedBy(this.methodClass.sym)) {
>>              if (this.refs.contains(ThisRef.direct()))
>>                  outerRefs.add(OuterRef.direct());
>>              if (this.refs.contains(ThisRef.indirect()))
>> @@ -801,9 +801,8 @@ class ThisEscapeAnalyzer extends TreeScanner {
>>          // Explicit outer 'this' reference?
>>          final Type selectedType = this.types.erasure(tree.selected.type);
>>          if (selectedType.hasTag(CLASS)) {
>> -            final Type.ClassType selectedClassType = (Type.ClassType)selectedType;
>>              if (tree.name == this.names._this &&
>> -                this.types.hasOuterClass(currentClassType, selectedClassType)) {
>> +                currentClassType.tsym.isEnclosedBy((ClassSymbol)selectedType.tsym)) {
>>                  if (this.refs.contains(OuterRef.direct()))
>>                      this.refs.add(ExprRef.direct(this.depth));
>>                  if (this.refs.contains(OuterRef.indirect()))
>> @@ -895,9 +894,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>>              final MethodSymbol sym = (MethodSymbol)tree.sym;
>>  
>>              // Check for implicit 'this' reference
>> -            final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
>> -            final Type methodOwnerType = sym.owner.type;
>> -            if (this.isSubtype(currentClassType, methodOwnerType)) {
>> +            if (methodClass.sym.isSubClass(sym.owner, types)) {
>>                  if (this.refs.contains(ThisRef.direct()))
>>                      this.refs.add(ExprRef.direct(this.depth));
>>                  if (this.refs.contains(ThisRef.indirect()))
>> @@ -906,7 +903,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>>              }
>>  
>>              // Check for implicit outer 'this' reference
>> -            if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
>> +            if (methodClass.sym.isEnclosedBy((ClassSymbol)sym.owner)) {
>>                  if (this.refs.contains(OuterRef.direct()))
>>                      this.refs.add(ExprRef.direct(this.depth));
>> 
>> 
>> Btw, I believe a similar trick can be used in TreeInfo.isExplicitThisReference. If I'm correct, `hasOuterClass` should probably be removed as it duplicates already existing functionality. 
>> 
>> Since I'm bringing this up, as TreeInfo.isExplicitThisReference is only used by the new analyzer, it would be cleaner if it was defined there, at least until it's clear it might be needed by some other client.
>
> Weird. I don't get that build failure.
> 
> Neither does github... I have been relying on the github build "Actions" succeeding to determine if "the build works" and according to that it is building.
> 
> I will add the `DISABLED_WARNINGS` in any case.

Thanks for the patch!

The semantics of `hasOuterClass()` returns false if A and B are the same class, while `isEnclosedBy()` returns true if A and B are the same class.

However, I don't think it would actually matter in practice...

Regardless, I'll add the extra equality comparison and apply your patch and also the suggestions to integrate `isExplicitThisReference()` and eliminate `hasOuterClass()`.

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

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


From aivanov at openjdk.org  Thu Jan 12 21:15:14 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 12 Jan 2023 21:15:14 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v5]
In-Reply-To: <2k9HDwh7mMFiCfbsBZ1C092fL8DeBlsnx7D2z4041o4=.edce5b20-518b-4cf0-8550-6e37c01bcb83@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <9ybbK-vje2WkFfoDXlLU1jJJc3QKi5VTf57_KKVfQIk=.50851a17-ad46-476b-87eb-16734fdea50c@github.com>
 <PEXwLuJYsSJxMmbGYQEMDTY4A_ON_xkpG5ckMxj6Sjg=.efa1304d-f310-4431-853a-2c33e9cbd8bd@github.com>
 <BHx-0TiUqJWPfbeMM1MvgsHRqsWu0FhiHL7fMEphucM=.1238973f-7ac3-4786-8aaf-334ec2d96395@github.com>
 <2k9HDwh7mMFiCfbsBZ1C092fL8DeBlsnx7D2z4041o4=.edce5b20-518b-4cf0-8550-6e37c01bcb83@github.com>
Message-ID: <3RKUqBTYs_EWzDGXm6ofwmU-LXtneWOcv0DCBCDDjBY=.6fb09582-269b-4f93-b5f8-2b62f43af7ee@github.com>

On Thu, 12 Jan 2023 06:23:37 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Since in aqua the fallback text is handled already and in aqua there is a sub panel which handles the Approve button, I excluded it.
>
> Also, `getDefaultApproveButton()` returns null for Aqua L&F, to include Aqua in the test we can use `getApproveButtonText()`.

Here you are.

[JDK-8300084](https://bugs.openjdk.org/browse/JDK-8300084): AquaFileChooserUI.getDefaultButton returns null

Now you can fix this bug so that Aqua L&F doesn't return null and add that bugid to this test.

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

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


From aivanov at openjdk.org  Thu Jan 12 21:24:22 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 12 Jan 2023 21:24:22 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v6]
In-Reply-To: <RpUGKQWl-Gg_TWMmpzgIJMEYVkYW5Nvy1sIIiMbEdHQ=.3ca53ed6-a203-42ce-9423-3ac2623e5dd4@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <RpUGKQWl-Gg_TWMmpzgIJMEYVkYW5Nvy1sIIiMbEdHQ=.3ca53ed6-a203-42ce-9423-3ac2623e5dd4@github.com>
Message-ID: <MVtTdYh_pqIcqgNEbix5K9Nyenzoivdu50XU95ig3is=.72468379-af6f-4e66-8223-77cb47ba40a5@github.com>

On Thu, 12 Jan 2023 06:06:32 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 80:

> 78:             if (customApproveButton == null) {
> 79:                 fail("Cannot find Custom Approve Button in FileChooser!");
> 80:                 return;

Suggestion:

                throw new RuntimeException("Cannot find Approve button in FileChooser!");

It's just an Approve button.

Now that frame is disposed of separately, there's no need for `fail` method ? throw the exception.

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 83:

> 81:             }
> 82:             if (customApproveButton.getText() == null) {
> 83:                 fail("Custom Approve Button Text is null in FileChooser!");

Suggestion:

                fail("Approve button text is null in FileChooser!");

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 97:

> 95:     }
> 96: 
> 97:     private void setLookAndFeel(String laf) {

It can be `static` since it doesn't use any fields of the class.

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

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


From duke at openjdk.org  Thu Jan 12 21:31:25 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 21:31:25 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <Q9_WG6FXdZ8vKHvpaxQgB7bqSMmgr5B3K6ontsX2tYc=.98807ef6-c1a7-4cd8-8acf-4f79ed623ccb@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <B8My4cqEflONOlWc75umJqxNRJrd0uFM6jHCF090Ln4=.85355133-7fc5-4afa-b7c5-f41242aee038@github.com>
 <Q9_WG6FXdZ8vKHvpaxQgB7bqSMmgr5B3K6ontsX2tYc=.98807ef6-c1a7-4cd8-8acf-4f79ed623ccb@github.com>
Message-ID: <bQRip8YkoGXxKbaNcn026jlLR73JRl_-hX_UgGDSaBg=.73075c3e-1dbf-41d2-ae3b-275bf36b668f@github.com>

On Thu, 12 Jan 2023 19:01:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The code you quoted has nothing specifically to do with method invocations. This code is simply handing the evaluation of the expressions `this` and `super`. For example, `this` could just be a parameter we're passing to another method.
>> 
>> When `this` or `super` expressions are evaluated, the thing left on top of the stack is a direct/indirect reference (i.e., an `ExprRef`) exactly when the there is a direct/indirect reference of type `ThisRef` in the current reference set.
>> 
>> In cases where `this` is then "invoked", e.g., `this()`, the `ExprRef` (top of Java stack) becomes the method receiver, and when the method is "invoked" it turns back into a `ThisRef` (see earlier question).
>> 
>> Regarding the optimization you mention, in light of the above I'm not sure it would still work.
>
> My point is about who puts ThisRef in the set to begin with. It seems to me that ThisRef is put there at the start of a method analysis. After which, there's several code points where we say "if there's a direct ThisRef in the set, do this, otherwise, if there's an indirect ThisRef in the set, do that". But the ThisRef (whether indirect or direct) seems set once and for all (when we start the analysis, and then inside visitApply). 
> 
> There is also this bit in `visitReference`:
> 
> 
> case SUPER:
>             if (this.refs.contains(ThisRef.direct()))
>                 receiverRefs.add(ThisRef.direct());
>             if (this.refs.contains(ThisRef.indirect()))
>                 receiverRefs.add(ThisRef.indirect());
>             break;
> 
> 
> But this doesn't change what I'm saying - there seems to be a general property when we execute this analysis which says whether the current execution context has a direct `this` or not. This seems to me better captured with a boolean, which is then fed back to all the other various downstream ref creation.
> 
> The main observation, at least for me, is that the code unifies everything under refs, when in reality there are different aspects:
> 
> * the set of variables that can point to this, whether directly or indirectly (this is truly a set)
> * whether the current context has a direct or indirect this (this seems more a flag to me)
> * whether the expression on top of stack is direct/indirect this reference or not (again, 3 possible values here) - but granted, there `depth` here to take into account, so you probably end up with a set (given that we don't want to model a scope with its own set)
> 
> When reading the code, seeing set expression like containment checks or removals for things that doesn't seem to be truly sets (unless I'm missing something) was genuinely confusing me.

I get what you're saying - it seems silly to model what is essentially a fixed, boolean property with the membership of a singleton in a set field, rather than with a simple boolean field.

There is a conceptual trade-off though... a lot of the code relates to converting `Ref`'s from one type to another. For example, as pointed out above, a method invocation might convert a `ExprRef` to a `ThisRef`, then to a `ReturnRef`'s, etc. Having these things all be considered part of the same family helps conceptually. The fact that a direct `ThisRef` is a singleton is just a coincidence in this way of looking at things.

The benefit is the simplicity of being able to think of the data model as "just a set of references".

For example, methods like `RefSet.replaceExprs()` become less elegant (or basically impossible) if there have to be special cases for each type of reference, whereas currently we can do clean stuff like this:


    @Override
    public void visitReturn(JCReturn tree) {
        scan(tree.expr);
        refs.replaceExprs(depth, ReturnRef::new);
    }


But I'm also realizing now that several places can be cleaned up by taking this event further. E.g., we should replace this code:

            if (refs.contains(ThisRef.direct()))
                outerRefs.add(OuterRef.direct());
            if (refs.contains(ThisRef.indirect()))
                outerRefs.add(OuterRef.indirect());

with something like this:

            refs.mapInto(outerRefs, ThisRef.class, OuterRef::new);


I will go through and refactor to do that and clean things up a little more.

> When reading the code, seeing set expression like containment checks or removals for things that doesn't seem to be truly sets (unless I'm missing something) was genuinely confusing me.

Probably my fault for not providing better documentation of the overall "set of references" conceptual approach. FWIW I added a little bit more in f83a9cf0.

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

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


From aivanov at openjdk.org  Thu Jan 12 21:36:16 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 12 Jan 2023 21:36:16 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v2]
In-Reply-To: <q0nbGDroN8GsUeLspa4LhLx_bgfDV_-OpSXMjsnR_nk=.2859494d-d288-4cbf-a0c6-21c5c03c74bf@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <2ZHOyW1znkGexCRUDlPgJdLdKeIQeKwGSZIrWRNtW5s=.0fed5796-165b-45fe-89c7-14e211617835@github.com>
 <q0nbGDroN8GsUeLspa4LhLx_bgfDV_-OpSXMjsnR_nk=.2859494d-d288-4cbf-a0c6-21c5c03c74bf@github.com>
Message-ID: <eB7LOt2O_DyGXxicoBEQ8KDgbjsHubUEuZHFBCAt1w0=.d11abbe7-8760-4791-bfcd-ad1351ee92d3@github.com>

On Thu, 12 Jan 2023 10:41:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix
>
> src/java.desktop/share/classes/javax/swing/SwingWorker.java line 757:
> 
>> 755:                 do {
>> 756:                     try {
>> 757:                         Thread.sleep(100);
> 
> I did not look closely at the discussion in JBS about this change, but this "sleep(100)" looks broken. I do not think we can block EDT like this.

I agree it doesn't look good. If adding `sleep` is needed, there's something wrong.

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

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


From mcimadamore at openjdk.org  Thu Jan 12 21:47:24 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 21:47:24 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <bQRip8YkoGXxKbaNcn026jlLR73JRl_-hX_UgGDSaBg=.73075c3e-1dbf-41d2-ae3b-275bf36b668f@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <B8My4cqEflONOlWc75umJqxNRJrd0uFM6jHCF090Ln4=.85355133-7fc5-4afa-b7c5-f41242aee038@github.com>
 <Q9_WG6FXdZ8vKHvpaxQgB7bqSMmgr5B3K6ontsX2tYc=.98807ef6-c1a7-4cd8-8acf-4f79ed623ccb@github.com>
 <bQRip8YkoGXxKbaNcn026jlLR73JRl_-hX_UgGDSaBg=.73075c3e-1dbf-41d2-ae3b-275bf36b668f@github.com>
Message-ID: <gxDMb8M-9X-WeqGLdm-RDbtxmeE4TvAQdJ-AHDIwGGU=.9bf4bd87-8467-4d06-877f-55486fefccb9@github.com>

On Thu, 12 Jan 2023 21:28:12 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> My point is about who puts ThisRef in the set to begin with. It seems to me that ThisRef is put there at the start of a method analysis. After which, there's several code points where we say "if there's a direct ThisRef in the set, do this, otherwise, if there's an indirect ThisRef in the set, do that". But the ThisRef (whether indirect or direct) seems set once and for all (when we start the analysis, and then inside visitApply). 
>> 
>> There is also this bit in `visitReference`:
>> 
>> 
>> case SUPER:
>>             if (this.refs.contains(ThisRef.direct()))
>>                 receiverRefs.add(ThisRef.direct());
>>             if (this.refs.contains(ThisRef.indirect()))
>>                 receiverRefs.add(ThisRef.indirect());
>>             break;
>> 
>> 
>> But this doesn't change what I'm saying - there seems to be a general property when we execute this analysis which says whether the current execution context has a direct `this` or not. This seems to me better captured with a boolean, which is then fed back to all the other various downstream ref creation.
>> 
>> The main observation, at least for me, is that the code unifies everything under refs, when in reality there are different aspects:
>> 
>> * the set of variables that can point to this, whether directly or indirectly (this is truly a set)
>> * whether the current context has a direct or indirect this (this seems more a flag to me)
>> * whether the expression on top of stack is direct/indirect this reference or not (again, 3 possible values here) - but granted, there `depth` here to take into account, so you probably end up with a set (given that we don't want to model a scope with its own set)
>> 
>> When reading the code, seeing set expression like containment checks or removals for things that doesn't seem to be truly sets (unless I'm missing something) was genuinely confusing me.
>
> I get what you're saying - it seems silly to model what is essentially a fixed, boolean property with the membership of a singleton in a set field, rather than with a simple boolean field.
> 
> There is a conceptual trade-off though... a lot of the code relates to converting `Ref`'s from one type to another. For example, as pointed out above, a method invocation might convert a `ExprRef` to a `ThisRef`, then to a `ReturnRef`'s, etc. Having these things all be considered part of the same family helps conceptually. The fact that a direct `ThisRef` is a singleton is just a coincidence in this way of looking at things.
> 
> The benefit is the simplicity of being able to think of the data model as "just a set of references".
> 
> For example, methods like `RefSet.replaceExprs()` become less elegant (or basically impossible) if there have to be special cases for each type of reference, whereas currently we can do clean stuff like this:
> 
> 
>     @Override
>     public void visitReturn(JCReturn tree) {
>         scan(tree.expr);
>         refs.replaceExprs(depth, ReturnRef::new);
>     }
> 
> 
> But I'm also realizing now that several places can be cleaned up by taking this event further. E.g., we should replace this code:
> 
>             if (refs.contains(ThisRef.direct()))
>                 outerRefs.add(OuterRef.direct());
>             if (refs.contains(ThisRef.indirect()))
>                 outerRefs.add(OuterRef.indirect());
> 
> with something like this:
> 
>             refs.mapInto(outerRefs, ThisRef.class, OuterRef::new);
> 
> 
> I will go through and refactor to do that and clean things up a little more.
> 
>> When reading the code, seeing set expression like containment checks or removals for things that doesn't seem to be truly sets (unless I'm missing something) was genuinely confusing me.
> 
> Probably my fault for not providing better documentation of the overall "set of references" conceptual approach. FWIW I added a little bit more in f83a9cf0.

> ```java
> ```java
>  if (refs.contains(ThisRef.direct()))
>                 outerRefs.add(OuterRef.direct());
>             if (refs.contains(ThisRef.indirect()))
>                 outerRefs.add(OuterRef.indirect());
> ```
> 
> 
>     
>       
>     
> 
>       
>     
> 
>     
>   
> with something like this:
> ```java
>             refs.mapInto(outerRefs, ThisRef.class, OuterRef::new);
> ```
> ```

This sounds like a good idea, that idiom is quite widespread, so it should help avoiding repetition.

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

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


From psadhukhan at openjdk.org  Fri Jan 13 04:03:55 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 13 Jan 2023 04:03:55 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v3]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <kkN_fihRAOtPRTzHMmwe4NtWWzaDcZ4wnqCGBJB-r_o=.51f8dfb3-f108-48c0-ae0b-b32bda45ec4f@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

  Remove blocking thread sleep for EDT

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/70e4a8ce..4f59bfa4

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

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

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


From duke at openjdk.org  Fri Jan 13 04:04:36 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 04:04:36 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision:

 - Fix bug where all but the last yeild statement were being ignored.
 - Add method RefSet.mapInto() and use to refactor/clean up.
 - Fix possible assertion failure when handling if statements.
 - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff.
   
   Suggested-by:   mcimadamore
 - Add comment regarding limitations of expresison type filtering.
 - Add a few more DISABLED_WARNINGS to unbreak build.
 - Clean up handling of switch expressions a bit.
 - Remove unused method variant of analyzeTree().
 - Avoid all caps in comments.
 - Clarify confusing comment.
 - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/6e96a7d7..edf3c3f5

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

  Stats: 540 lines in 8 files changed: 120 ins; 92 del; 328 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

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


From mcimadamore at openjdk.org  Fri Jan 13 04:04:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Jan 2023 04:04:37 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <db_e6O3GAPZPRU1kJGawP19tAb-DmiNduGa51LCD4VE=.1b70448a-7b9b-4d99-9828-e3186c13a73c@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>
 <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>
 <db_e6O3GAPZPRU1kJGawP19tAb-DmiNduGa51LCD4VE=.1b70448a-7b9b-4d99-9828-e3186c13a73c@github.com>
Message-ID: <Piegj-aQWN-4MPZoB-zt1IW9Jp_OPCDfFvvpOVdGDkI=.74995898-e2c1-42c7-8362-408668a49561@github.com>

On Thu, 12 Jan 2023 19:12:27 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Uhm. Turns out I probably did not understand the filter correctly, and now I'm more dubious about what it actually does. Say you have this hierarchy:
>> 
>> 
>> interface A { }
>> class B {
>>      B() {
>>           A a = (A)this;
>>           ...
>>       }
>>  }
>>  class C extends B implements A { }
>>  ```
>> 
>> Pathological case, I know. But the filtering will end up dropping the expression Ref on the floor, right? (because B and A are unrelated).
>
>> But the filtering will end up dropping the expression Ref on the floor, right? (because B and A are unrelated).
> 
> Ah, I see what you mean.
> 
> Here's a more complete example:
> 
> public class CastLeak {
> 
>     public CastLeak() {
>         ((CastLeak)(Runnable)this).mightLeak();
>     }
> 
>     public void mightLeak() {
>     }
> }
> 
> That would be a leak for any subclass that implements `Runnable`. Yet no warning is generated.
> 
> So the filtering by expression type is going to potentially create false negatives. But it also eliminates a bunch of false positives. And the false negatives are probably all somewhat pathological like the example above.
> 
> So I still think it's worth doing.

Ok - I thought false negative was the thing to absolutely avoid - and that was the no. 1 concern. I think a possible approach to keep both the filtering and the code more or less similar to what you have, is to save the type of the expression in the ExprRef. Then, I believe that, at the end of scan() you can just get whatever type is there, and check that it's the correct one, if not drop it.

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

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


From duke at openjdk.org  Fri Jan 13 04:04:37 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 04:04:37 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <Piegj-aQWN-4MPZoB-zt1IW9Jp_OPCDfFvvpOVdGDkI=.74995898-e2c1-42c7-8362-408668a49561@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>
 <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>
 <db_e6O3GAPZPRU1kJGawP19tAb-DmiNduGa51LCD4VE=.1b70448a-7b9b-4d99-9828-e3186c13a73c@github.com>
 <Piegj-aQWN-4MPZoB-zt1IW9Jp_OPCDfFvvpOVdGDkI=.74995898-e2c1-42c7-8362-408668a49561@github.com>
Message-ID: <w3FeW11M6pr-DOmW1v_4Doa9t52s55Pedi5fnOOarbc=.aa10dd51-0ff0-40ad-977e-7091fea00d4e@github.com>

On Thu, 12 Jan 2023 21:47:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>  Ok - I thought false negative was the thing to absolutely avoid - and that was the no. 1 concern.

You're right. I think at the time I reasoned that it would be unusual enough for the type of an expression to start as an instanceof X, then change to not being an instanceof X, and then change back, that it was worth it to go ahead and filter these out. But admittedly that was based on intuition, not science.

> I think a possible approach to keep both the filtering and the code more or less similar to what you have, is to save the type of the expression in the ExprRef. Then, I believe that, at the end of scan() you can just get whatever type is there, and check that it's the correct one, if not drop it.

That's a nice idea... thanks. I'll play around with it some.

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

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


From psadhukhan at openjdk.org  Fri Jan 13 04:41:42 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 13 Jan 2023 04:41:42 GMT
Subject: RFR: 7169951: SwingSet2 throws NullPointerException with Nimbus L&F
Message-ID: <hU2Q5fjkF4qi35_Ai-qPNqxeZx1Xvu6dfKTPuHggbl0=.18f7a248-c577-4f93-9fab-e707289c8dc7@github.com>

It is observed that if SwingSet2 is run in Nimbus L&F and
we drag the icon tool bar (which is floatable) out of the GUI Window
and  Once the tool bar is detached, click on "Look & Feel" menu option to change to any L&F (say Java L&F)
it causes NPE due to font being null when getFontMetrics() is called

In other L&F, it uses the tabPane's [font ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L2177) whereas in Nimbus font is obtained from getStyle().getFont() which returns null when toolbar is detached from the main window.
The proposed fix is to get tabPane's font if the font passed is null alike other L&Fs. 

No regression test is made as it can be verified with SwingSet2..

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

Commit messages:
 - 7169951: SwingSet2 throws NullPointerException with Nimbus L&F

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

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


From tr at openjdk.org  Fri Jan 13 06:48:45 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 13 Jan 2023 06:48:45 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v7]
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <OtJHxOpP112_JSG5HmleDPMi-KvAJYqENCPLdmo0rpk=.38e14dd4-d9a7-4865-a9ad-0e48e6c58984@github.com>

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

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/11901/files
  - new: https://git.openjdk.org/jdk/pull/11901/files/14b358c1..6c86e59a

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

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

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


From tr at openjdk.org  Fri Jan 13 06:48:46 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 13 Jan 2023 06:48:46 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v6]
In-Reply-To: <MVtTdYh_pqIcqgNEbix5K9Nyenzoivdu50XU95ig3is=.72468379-af6f-4e66-8223-77cb47ba40a5@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <RpUGKQWl-Gg_TWMmpzgIJMEYVkYW5Nvy1sIIiMbEdHQ=.3ca53ed6-a203-42ce-9423-3ac2623e5dd4@github.com>
 <MVtTdYh_pqIcqgNEbix5K9Nyenzoivdu50XU95ig3is=.72468379-af6f-4e66-8223-77cb47ba40a5@github.com>
Message-ID: <ocoTVFKjUTgUHk0lKKyYW9nWtb0CtYT9gvF06K7_yhg=.e5e4bdc2-0cf7-438a-ae9a-1b703fd829da@github.com>

On Thu, 12 Jan 2023 21:17:07 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 based on review comments
>
> test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 80:
> 
>> 78:             if (customApproveButton == null) {
>> 79:                 fail("Cannot find Custom Approve Button in FileChooser!");
>> 80:                 return;
> 
> Suggestion:
> 
>                 throw new RuntimeException("Cannot find Approve button in FileChooser!");
> 
> It's just an Approve button.
> 
> Now that frame is disposed of separately, there's no need for `fail` method ? throw the exception.

Updated.

> test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 83:
> 
>> 81:             }
>> 82:             if (customApproveButton.getText() == null) {
>> 83:                 fail("Custom Approve Button Text is null in FileChooser!");
> 
> Suggestion:
> 
>                 fail("Approve button text is null in FileChooser!");

Updated.

> test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 97:
> 
>> 95:     }
>> 96: 
>> 97:     private void setLookAndFeel(String laf) {
> 
> It can be `static` since it doesn't use any fields of the class.

Updated.

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

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


From tr at openjdk.org  Fri Jan 13 06:56:12 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 13 Jan 2023 06:56:12 GMT
Subject: RFR: 8041447: Test javax/swing/dnd/7171812/bug7171812.java fails
 with java.lang.RuntimeException: Test failed,
 scroll on drag doesn't work [v2]
In-Reply-To: <5KV1a4L29hNCfjALWGJ8T0NQPE1XebPmwN3ntCLLWVo=.2542dc44-1a49-4beb-acde-e5246d21c48b@github.com>
References: <uOs8YGOmi-VhtYfqBhZ2sp63E6LC38r2SPo8OS_PBgM=.2567b104-b687-44d6-b3f0-69edbc9fefa3@github.com>
 <5KV1a4L29hNCfjALWGJ8T0NQPE1XebPmwN3ntCLLWVo=.2542dc44-1a49-4beb-acde-e5246d21c48b@github.com>
Message-ID: <oNFoPBQ0oYGP203qo1QC9IG2HlvVdnM1-BTMbgKYEfk=.7c3a13ce-6084-4f4c-a4c4-db6d1399ae29@github.com>

On Thu, 12 Jan 2023 11:43:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test probably was failing few years back due to samevm mode.
>> It's not failing now but made some robot safeguards.
>> Several iterations are passing in all CI platforms. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Access swing comp in EDT

Fix is fine and works as expected.

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

Marked as reviewed by tr (Committer).

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


From serb at openjdk.org  Fri Jan 13 08:25:11 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 13 Jan 2023 08:25:11 GMT
Subject: RFR: 7169951: SwingSet2 throws NullPointerException with Nimbus
 L&F
In-Reply-To: <hU2Q5fjkF4qi35_Ai-qPNqxeZx1Xvu6dfKTPuHggbl0=.18f7a248-c577-4f93-9fab-e707289c8dc7@github.com>
References: <hU2Q5fjkF4qi35_Ai-qPNqxeZx1Xvu6dfKTPuHggbl0=.18f7a248-c577-4f93-9fab-e707289c8dc7@github.com>
Message-ID: <WJJ7wiIPj_6-wYIceQ2SC6lr-mfwdqMPCJ0rkJIN7ME=.96b86173-dff1-4a61-b065-67af6979e474@github.com>

On Fri, 13 Jan 2023 04:25:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is observed that if SwingSet2 is run in Nimbus L&F and
> we drag the icon tool bar (which is floatable) out of the GUI Window
> and  Once the tool bar is detached, click on "Look & Feel" menu option to change to any L&F (say Java L&F)
> it causes NPE due to font being null when getFontMetrics() is called
> 
> In other L&F, it uses the tabPane's [font ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L2177) whereas in Nimbus font is obtained from getStyle().getFont() which returns null when toolbar is detached from the main window.
> The proposed fix is to get tabPane's font if the font passed is null alike other L&Fs. 
> 
> No regression test is made as it can be verified with SwingSet2..

It is unclear does the "getStyle().getFont()" always returns null for that component but we call it only for "floatable" toolbar. Or "getStyle().getFont()" starts to return null for the "floatable" toolbar. If it starts to return null then why does this happen? Are we sure that the "getStyle().getFont()" and "tabPane.getFont()" always returns the same font?

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

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


From serb at openjdk.org  Fri Jan 13 08:26:15 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 13 Jan 2023 08:26:15 GMT
Subject: RFR: 8041447: Test javax/swing/dnd/7171812/bug7171812.java fails
 with java.lang.RuntimeException: Test failed,
 scroll on drag doesn't work [v2]
In-Reply-To: <5KV1a4L29hNCfjALWGJ8T0NQPE1XebPmwN3ntCLLWVo=.2542dc44-1a49-4beb-acde-e5246d21c48b@github.com>
References: <uOs8YGOmi-VhtYfqBhZ2sp63E6LC38r2SPo8OS_PBgM=.2567b104-b687-44d6-b3f0-69edbc9fefa3@github.com>
 <5KV1a4L29hNCfjALWGJ8T0NQPE1XebPmwN3ntCLLWVo=.2542dc44-1a49-4beb-acde-e5246d21c48b@github.com>
Message-ID: <j7eBV6qzQoL-iFJqx8wMI9CmPT2GYGjSj3fg8wx92pY=.0a195002-de25-4539-aa4a-d86cd8da7cb7@github.com>

On Thu, 12 Jan 2023 11:43:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test probably was failing few years back due to samevm mode.
>> It's not failing now but made some robot safeguards.
>> Several iterations are passing in all CI platforms. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Access swing comp in EDT

I assume it was tested in mach5

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

Marked as reviewed by serb (Reviewer).

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


From psadhukhan at openjdk.org  Fri Jan 13 09:51:14 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 13 Jan 2023 09:51:14 GMT
Subject: RFR: 7169951: SwingSet2 throws NullPointerException with Nimbus
 L&F
In-Reply-To: <hU2Q5fjkF4qi35_Ai-qPNqxeZx1Xvu6dfKTPuHggbl0=.18f7a248-c577-4f93-9fab-e707289c8dc7@github.com>
References: <hU2Q5fjkF4qi35_Ai-qPNqxeZx1Xvu6dfKTPuHggbl0=.18f7a248-c577-4f93-9fab-e707289c8dc7@github.com>
Message-ID: <-Q-JVSsEYumtB6GUFs5SZ6GSWwiujuwNc5kf8XKxa0I=.4abd6cf6-d660-430e-9695-dad66d2da2ea@github.com>

On Fri, 13 Jan 2023 04:25:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is observed that if SwingSet2 is run in Nimbus L&F and
> we drag the icon tool bar (which is floatable) out of the GUI Window
> and  Once the tool bar is detached, click on "Look & Feel" menu option to change to any L&F (say Java L&F)
> it causes NPE due to font being null when getFontMetrics() is called
> 
> In other L&F, it uses the tabPane's [font ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L2177) whereas in Nimbus font is obtained from getStyle().getFont() which returns null when toolbar is detached from the main window.
> The proposed fix is to get tabPane's font if the font passed is null alike other L&Fs. 
> 
> No regression test is made as it can be verified with SwingSet2..

getStyle().getFont() returns null as "getFontForState(context)" returns null which is because synth state for floating toolbar is invalid which is 0x201
getStyle().getFont()" and "tabPane.getFont()" in normal valid case returns same font which is javax.swing.plaf.FontUIResource[family=SansSerif,name=sansserif,style=plain,size=12]

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

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


From mcimadamore at openjdk.org  Fri Jan 13 11:01:24 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Jan 2023 11:01:24 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
 <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
Message-ID: <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>

On Thu, 12 Jan 2023 21:04:09 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> but what if `m` is a static method in a separate compilation unit? Should it be able to observe a partially initialized Foo?
>
> Caring about the proper initialization of any class in the _current_ compilation unit is an explicit non-goal.
> 
> We only care about bugs where a superclass and subclass are in separate compilation units.

So, to clarify, in this case:


import java.util.*;

class B {
    final Object ref;

     private B(Object ref) {
          Foo.consume(this);
          this.ref = ref;
      }
 }


Even though `this` leaks to a method clearly before it is fully initialized, we do not care because there can be no subclass involved observing this. I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well - we're effectively leaking a class whose final field has not been initialized!

That said, if that was discussed, and it was decided for the warning not to deal with this case, that's ok.

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

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


From mcimadamore at openjdk.org  Fri Jan 13 11:11:31 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Jan 2023 11:11:31 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
 <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
 <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>
Message-ID: <w3dOEMwp8dm79cQzma_obHcEf9cs5wjAQASB_B94iwM=.caf9c686-425f-4426-bcee-c8216f17d382@github.com>

On Fri, 13 Jan 2023 10:58:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Caring about the proper initialization of any class in the _current_ compilation unit is an explicit non-goal.
>> 
>> We only care about bugs where a superclass and subclass are in separate compilation units.
>
> So, to clarify, in this case:
> 
> 
> import java.util.*;
> 
> class B {
>     final Object ref;
> 
>      private B(Object ref) {
>           Foo.consume(this);
>           this.ref = ref;
>       }
>  }
> 
> 
> Even though `this` leaks to a method clearly before it is fully initialized, we do not care because there can be no subclass involved observing this. I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well - we're effectively leaking a class whose final field has not been initialized!
> 
> That said, if that was discussed, and it was decided for the warning not to deal with this case, that's ok.

Perhaps my confusion might come from the name `this-escape` of the lint warning - which seems overpromising in this respect. But I looked at the description of the lint warning using `javac --help-lint` and I got this:


    this-escape          Warn when a constructor invokes a method that could be overriden in a subclass;


Which indeed aligns well with what this PR is doing. So that's ok.

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

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


From mcimadamore at openjdk.org  Fri Jan 13 11:11:31 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Jan 2023 11:11:31 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <w3dOEMwp8dm79cQzma_obHcEf9cs5wjAQASB_B94iwM=.caf9c686-425f-4426-bcee-c8216f17d382@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
 <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
 <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>
 <w3dOEMwp8dm79cQzma_obHcEf9cs5wjAQASB_B94iwM=.caf9c686-425f-4426-bcee-c8216f17d382@github.com>
Message-ID: <iymqtQuj4_LpboWmdGSD5GgmOeHEz-Mmv0rNFcWLrO0=.4cbd3fee-9f08-40be-b635-5636ac8efb4d@github.com>

On Fri, 13 Jan 2023 11:05:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> So, to clarify, in this case:
>> 
>> 
>> import java.util.*;
>> 
>> class B {
>>     final Object ref;
>> 
>>      private B(Object ref) {
>>           Foo.consume(this);
>>           this.ref = ref;
>>       }
>>  }
>> 
>> 
>> Even though `this` leaks to a method clearly before it is fully initialized, we do not care because there can be no subclass involved observing this. I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well - we're effectively leaking a class whose final field has not been initialized!
>> 
>> That said, if that was discussed, and it was decided for the warning not to deal with this case, that's ok.
>
> Perhaps my confusion might come from the name `this-escape` of the lint warning - which seems overpromising in this respect. But I looked at the description of the lint warning using `javac --help-lint` and I got this:
> 
> 
>     this-escape          Warn when a constructor invokes a method that could be overriden in a subclass;
> 
> 
> Which indeed aligns well with what this PR is doing. So that's ok.

Something seems to be up with the lint description for this-escape - compare this:


  serial               Warn about Serializable classes that do not have a serialVersionUID field. 
                         Also warn about other suspect declarations in Serializable and Externalizable classes and interfaces.

with this:


  this-escape          Warn when a constructor invokes a method that could be overriden in a subclass;
such a method would execute before the subclass constructor completes its initialization.


Indentation seems to be missing, which causes readability issues in the `--help-lint` output.

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

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


From aivanov at openjdk.org  Fri Jan 13 12:03:18 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 13 Jan 2023 12:03:18 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v6]
In-Reply-To: <ocoTVFKjUTgUHk0lKKyYW9nWtb0CtYT9gvF06K7_yhg=.e5e4bdc2-0cf7-438a-ae9a-1b703fd829da@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <RpUGKQWl-Gg_TWMmpzgIJMEYVkYW5Nvy1sIIiMbEdHQ=.3ca53ed6-a203-42ce-9423-3ac2623e5dd4@github.com>
 <MVtTdYh_pqIcqgNEbix5K9Nyenzoivdu50XU95ig3is=.72468379-af6f-4e66-8223-77cb47ba40a5@github.com>
 <ocoTVFKjUTgUHk0lKKyYW9nWtb0CtYT9gvF06K7_yhg=.e5e4bdc2-0cf7-438a-ae9a-1b703fd829da@github.com>
Message-ID: <73Eu6aC_n0J77mk4FToR9hTQCH7AOC4rUwxCKAqMHQI=.1770b4b0-bd89-4850-9330-8a3135789566@github.com>

On Fri, 13 Jan 2023 06:44:05 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 83:
>> 
>>> 81:             }
>>> 82:             if (customApproveButton.getText() == null) {
>>> 83:                 fail("Custom Approve Button Text is null in FileChooser!");
>> 
>> Suggestion:
>> 
>>                 fail("Approve button text is null in FileChooser!");
>
> Updated.

I wonder why do you like title-style capitalisation in exception messages.

?Approve Button Text? is appropriate if it's a title of something. Since it's a message, ?Approve button text? should be used instead.

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

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


From vromero at openjdk.org  Fri Jan 13 12:45:34 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 12:45:34 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
Message-ID: <UiXxkJII_OrkCKyMYxiZWUQ2iiLwjcrAByp_b4_vZv0=.a0fe5083-5e0c-444a-b1ee-703608294bff@github.com>

On Fri, 13 Jan 2023 04:04:36 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision:
> 
>  - Fix bug where all but the last yeild statement were being ignored.
>  - Add method RefSet.mapInto() and use to refactor/clean up.
>  - Fix possible assertion failure when handling if statements.
>  - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff.
>    
>    Suggested-by:   mcimadamore
>  - Add comment regarding limitations of expresison type filtering.
>  - Add a few more DISABLED_WARNINGS to unbreak build.
>  - Clean up handling of switch expressions a bit.
>  - Remove unused method variant of analyzeTree().
>  - Avoid all caps in comments.
>  - Clarify confusing comment.
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 516:

> 514:         Name name = TreeInfo.name(invoke.meth);
> 515:         if (name == names._super) {
> 516:             scanInitializers();

it seems like the code scan initializers every time it finds a super() invocation, I guess that this scanning could be done once per class

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

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


From tr at openjdk.org  Fri Jan 13 14:14:02 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 13 Jan 2023 14:14:02 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v8]
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <uJN0vNQHinmUX_Q-HuxYuyw5UPWcsuIdmSsjSzJ4bSk=.3c45262d-0760-4597-a097-b28316598cc0@github.com>

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

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/11901/files
  - new: https://git.openjdk.org/jdk/pull/11901/files/6c86e59a..20993b85

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

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

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


From tr at openjdk.org  Fri Jan 13 14:14:04 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 13 Jan 2023 14:14:04 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v6]
In-Reply-To: <73Eu6aC_n0J77mk4FToR9hTQCH7AOC4rUwxCKAqMHQI=.1770b4b0-bd89-4850-9330-8a3135789566@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <RpUGKQWl-Gg_TWMmpzgIJMEYVkYW5Nvy1sIIiMbEdHQ=.3ca53ed6-a203-42ce-9423-3ac2623e5dd4@github.com>
 <MVtTdYh_pqIcqgNEbix5K9Nyenzoivdu50XU95ig3is=.72468379-af6f-4e66-8223-77cb47ba40a5@github.com>
 <ocoTVFKjUTgUHk0lKKyYW9nWtb0CtYT9gvF06K7_yhg=.e5e4bdc2-0cf7-438a-ae9a-1b703fd829da@github.com>
 <73Eu6aC_n0J77mk4FToR9hTQCH7AOC4rUwxCKAqMHQI=.1770b4b0-bd89-4850-9330-8a3135789566@github.com>
Message-ID: <EiIES4Ffs3Ib-ZMG3YZ6ZDuhpo-vgAiZkFatZmDrED4=.3e24be96-4237-41fe-857d-46438c90a14a@github.com>

On Fri, 13 Jan 2023 11:59:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Updated.
>
> I wonder why do you like title-style capitalisation in exception messages.
> 
> ?Approve Button Text? is appropriate if it's a title of something. Since it's a message, ?Approve button text? should be used instead.

Updated.

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

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


From vromero at openjdk.org  Fri Jan 13 14:34:40 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 14:34:40 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
Message-ID: <RTLJlnoc5Po9tb0cF1F9mACGYYNWpE1GKfebO5GL1xU=.e7518803-becd-4864-9576-49836d9118dd@github.com>

On Fri, 13 Jan 2023 04:04:36 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision:
> 
>  - Fix bug where all but the last yeild statement were being ignored.
>  - Add method RefSet.mapInto() and use to refactor/clean up.
>  - Fix possible assertion failure when handling if statements.
>  - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff.
>    
>    Suggested-by:   mcimadamore
>  - Add comment regarding limitations of expresison type filtering.
>  - Add a few more DISABLED_WARNINGS to unbreak build.
>  - Clean up handling of switch expressions a bit.
>  - Remove unused method variant of analyzeTree().
>  - Avoid all caps in comments.
>  - Clarify confusing comment.
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 533:

> 531:         if (sym != null &&
> 532:             sym.owner.kind == TYP &&
> 533:             ((ClassSymbol)sym.owner).fullname == names.java_lang_Object &&

nit: in general we use another idiom for this in the compiler:

sym.owner.type.tsym == syms.objectType.tsym

where `syms` is an instance of: `com.sun.tools.javac.code.Symtab`

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

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


From duke at openjdk.org  Fri Jan 13 15:11:48 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 15:11:48 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <iymqtQuj4_LpboWmdGSD5GgmOeHEz-Mmv0rNFcWLrO0=.4cbd3fee-9f08-40be-b635-5636ac8efb4d@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
 <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
 <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>
 <w3dOEMwp8dm79cQzma_obHcEf9cs5wjAQASB_B94iwM=.caf9c686-425f-4426-bcee-c8216f17d382@github.com>
 <iymqtQuj4_LpboWmdGSD5GgmOeHEz-Mmv0r
 NFcWLrO0=.4cbd3fee-9f08-40be-b635-5636ac8efb4d@github.com>
Message-ID: <OPxQigxTl_ro8RswIJw4V5dcKAt_XQyA3LlmHEamz_k=.7470afce-9a31-4035-a4e2-dd455772581c@github.com>

On Fri, 13 Jan 2023 11:08:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Perhaps my confusion might come from the name `this-escape` of the lint warning - which seems overpromising in this respect. But I looked at the description of the lint warning using `javac --help-lint` and I got this:
>> 
>> 
>>     this-escape          Warn when a constructor invokes a method that could be overriden in a subclass;
>> 
>> 
>> Which indeed aligns well with what this PR is doing. So that's ok.
>
> Something seems to be up with the lint description for this-escape - compare this:
> 
> 
>   serial               Warn about Serializable classes that do not have a serialVersionUID field. 
>                          Also warn about other suspect declarations in Serializable and Externalizable classes and interfaces.
> 
> with this:
> 
> 
>   this-escape          Warn when a constructor invokes a method that could be overriden in a subclass;
> such a method would execute before the subclass constructor completes its initialization.
> 
> 
> Indentation seems to be missing, which causes readability issues in the `--help-lint` output.

> I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well...

Yes - and this very question did come up in the discussions around this warning (see amber-dev).

The decision was to go with drawing the "warning boundary" at the compilation unit. The reasoning is that (a) this aligns with the compiler's "knowledge boundary", i.e., we can know for sure from code inspection, and also (b) focuses the warning on the particularly pernicious aspect of these bugs, which is that they arise from the non-obvious interaction among two or more files - even when looking at any single one of those files, there doesn't seem to be any apparent problem. In other words, we decided "not to try to save any single source code from itself".

But I think it's still an interesting question. Maybe experience will provide more guidance over time.

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

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


From duke at openjdk.org  Fri Jan 13 15:11:49 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 15:11:49 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <OPxQigxTl_ro8RswIJw4V5dcKAt_XQyA3LlmHEamz_k=.7470afce-9a31-4035-a4e2-dd455772581c@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
 <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
 <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>
 <w3dOEMwp8dm79cQzma_obHcEf9cs5wjAQASB_B94iwM=.caf9c686-425f-4426-bcee-c8216f17d382@github.com>
 <iymqtQuj4_LpboWmdGSD5GgmOeHEz-Mmv0r
 NFcWLrO0=.4cbd3fee-9f08-40be-b635-5636ac8efb4d@github.com>
 <OPxQigxTl_ro8RswIJw4V5dcKAt_XQyA3LlmHEamz_k=.7470afce-9a31-4035-a4e2-dd455772581c@github.com>
Message-ID: <q7WClEuAxTknvj0OzHu2zSJJpE5I6F70Lq-lTqI5JgA=.172745fa-d90e-443d-9610-eed503083e96@github.com>

On Fri, 13 Jan 2023 15:08:43 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Something seems to be up with the lint description for this-escape - compare this:
>> 
>> 
>>   serial               Warn about Serializable classes that do not have a serialVersionUID field. 
>>                          Also warn about other suspect declarations in Serializable and Externalizable classes and interfaces.
>> 
>> with this:
>> 
>> 
>>   this-escape          Warn when a constructor invokes a method that could be overriden in a subclass;
>> such a method would execute before the subclass constructor completes its initialization.
>> 
>> 
>> Indentation seems to be missing, which causes readability issues in the `--help-lint` output.
>
>> I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well...
> 
> Yes - and this very question did come up in the discussions around this warning (see amber-dev).
> 
> The decision was to go with drawing the "warning boundary" at the compilation unit. The reasoning is that (a) this aligns with the compiler's "knowledge boundary", i.e., we can know for sure from code inspection, and also (b) focuses the warning on the particularly pernicious aspect of these bugs, which is that they arise from the non-obvious interaction among two or more files - even when looking at any single one of those files, there doesn't seem to be any apparent problem. In other words, we decided "not to try to save any single source code from itself".
> 
> But I think it's still an interesting question. Maybe experience will provide more guidance over time.

> Something seems to be up with the lint description for this-escape - compare this:

Oops, will fix - thanks.

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

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


From duke at openjdk.org  Fri Jan 13 15:16:59 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 15:16:59 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <UiXxkJII_OrkCKyMYxiZWUQ2iiLwjcrAByp_b4_vZv0=.a0fe5083-5e0c-444a-b1ee-703608294bff@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
 <UiXxkJII_OrkCKyMYxiZWUQ2iiLwjcrAByp_b4_vZv0=.a0fe5083-5e0c-444a-b1ee-703608294bff@github.com>
Message-ID: <RxcA0c13Q-Eh6cX1sjxDxaht8zI3Su8pIEkPSETbiTY=.cacec2de-8f7a-48d1-81f8-f6dca591e9ec@github.com>

On Fri, 13 Jan 2023 12:42:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision:
>> 
>>  - Fix bug where all but the last yeild statement were being ignored.
>>  - Add method RefSet.mapInto() and use to refactor/clean up.
>>  - Fix possible assertion failure when handling if statements.
>>  - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff.
>>    
>>    Suggested-by:   mcimadamore
>>  - Add comment regarding limitations of expresison type filtering.
>>  - Add a few more DISABLED_WARNINGS to unbreak build.
>>  - Clean up handling of switch expressions a bit.
>>  - Remove unused method variant of analyzeTree().
>>  - Avoid all caps in comments.
>>  - Clarify confusing comment.
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 516:
> 
>> 514:         Name name = TreeInfo.name(invoke.meth);
>> 515:         if (name == names._super) {
>> 516:             scanInitializers();
> 
> it seems like the code scan initializers every time it finds a super() invocation, I guess that this scanning could be done once per class

Yes... I did it that way is so that it doesn't require any adaptation if/when JDK-8194743 ever gets implemented. And it keeps the code a little simpler in exchange for a little redundancy.

I'm happy to fix this if you think it is necessary though.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 533:
> 
>> 531:         if (sym != null &&
>> 532:             sym.owner.kind == TYP &&
>> 533:             ((ClassSymbol)sym.owner).fullname == names.java_lang_Object &&
> 
> nit: in general we use another idiom for this in the compiler:
> 
> sym.owner.type.tsym == syms.objectType.tsym
> 
> where `syms` is an instance of: `com.sun.tools.javac.code.Symtab`

Thanks - will fix.

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

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


From mcimadamore at openjdk.org  Fri Jan 13 16:09:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Jan 2023 16:09:37 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <q7WClEuAxTknvj0OzHu2zSJJpE5I6F70Lq-lTqI5JgA=.172745fa-d90e-443d-9610-eed503083e96@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
 <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
 <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>
 <w3dOEMwp8dm79cQzma_obHcEf9cs5wjAQASB_B94iwM=.caf9c686-425f-4426-bcee-c8216f17d382@github.com>
 <iymqtQuj4_LpboWmdGSD5GgmOeHEz-Mmv0r
 NFcWLrO0=.4cbd3fee-9f08-40be-b635-5636ac8efb4d@github.com>
 <OPxQigxTl_ro8RswIJw4V5dcKAt_XQyA3LlmHEamz_k=.7470afce-9a31-4035-a4e2-dd455772581c@github.com>
 <q7WClEuAxTknvj0OzHu2zSJJpE5I6F70Lq-lTqI5JgA=.172745fa-d90e-443d-9610-eed503083e96@github.com>
Message-ID: <lpEkr6P1eaApuYtQ0CjthLuRbDx9E2BUAIXJMxY72M0=.c17e2502-ff07-4060-8522-a2a16319d36f@github.com>

On Fri, 13 Jan 2023 15:08:59 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>>> I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well...
>> 
>> Yes - and this very question did come up in the discussions around this warning (see amber-dev).
>> 
>> The decision was to go with drawing the "warning boundary" at the compilation unit. The reasoning is that (a) this aligns with the compiler's "knowledge boundary", i.e., we can know for sure from code inspection, and also (b) focuses the warning on the particularly pernicious aspect of these bugs, which is that they arise from the non-obvious interaction among two or more files - even when looking at any single one of those files, there doesn't seem to be any apparent problem. In other words, we decided "not to try to save any single source code from itself".
>> 
>> But I think it's still an interesting question. Maybe experience will provide more guidance over time.
>
>> Something seems to be up with the lint description for this-escape - compare this:
> 
> Oops, will fix - thanks.

> The decision was to go with drawing the "warning boundary" at the compilation unit. The reasoning is that (a) this aligns with the compiler's "knowledge boundary", i.e., we can know for sure from code inspection, and also (b) focuses the warning on the particularly pernicious aspect of these bugs, which is that they arise from the non-obvious interaction among two or more files

Sorry for being picky - you mention this "compilation unit" boundary before, but this is not really the reason here. Note that in my example B constructor calls out to a static method that is "outside" the boundary. The reason as to why my example is not flagged is simply that "escaping" is defined as "escaping into a subclass method", not just "escaping from the constructor (into some other compilation unit)".

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

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


From vromero at openjdk.org  Fri Jan 13 16:15:32 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 16:15:32 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <RxcA0c13Q-Eh6cX1sjxDxaht8zI3Su8pIEkPSETbiTY=.cacec2de-8f7a-48d1-81f8-f6dca591e9ec@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
 <UiXxkJII_OrkCKyMYxiZWUQ2iiLwjcrAByp_b4_vZv0=.a0fe5083-5e0c-444a-b1ee-703608294bff@github.com>
 <RxcA0c13Q-Eh6cX1sjxDxaht8zI3Su8pIEkPSETbiTY=.cacec2de-8f7a-48d1-81f8-f6dca591e9ec@github.com>
Message-ID: <77lMG_P3_ZGjTegQictMdNN1IKjWixuzLWy5-GbHYnI=.bdbfc529-2ac8-4bba-b3a6-d08f0977e372@github.com>

On Fri, 13 Jan 2023 15:14:05 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 516:
>> 
>>> 514:         Name name = TreeInfo.name(invoke.meth);
>>> 515:         if (name == names._super) {
>>> 516:             scanInitializers();
>> 
>> it seems like the code scan initializers every time it finds a super() invocation, I guess that this scanning could be done once per class
>
> Yes... I did it that way is so that it doesn't require any adaptation if/when JDK-8194743 ever gets implemented. And it keeps the code a little simpler in exchange for a little redundancy.
> 
> I'm happy to fix this if you think it is necessary though.

I'm OK either way we can revisit this later either as part of this PR or in a future one. I let it to your consideration

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

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


From duke at openjdk.org  Fri Jan 13 16:23:39 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 16:23:39 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <lpEkr6P1eaApuYtQ0CjthLuRbDx9E2BUAIXJMxY72M0=.c17e2502-ff07-4060-8522-a2a16319d36f@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
 <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
 <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>
 <w3dOEMwp8dm79cQzma_obHcEf9cs5wjAQASB_B94iwM=.caf9c686-425f-4426-bcee-c8216f17d382@github.com>
 <iymqtQuj4_LpboWmdGSD5GgmOeHEz-Mmv0r
 NFcWLrO0=.4cbd3fee-9f08-40be-b635-5636ac8efb4d@github.com>
 <OPxQigxTl_ro8RswIJw4V5dcKAt_XQyA3LlmHEamz_k=.7470afce-9a31-4035-a4e2-dd455772581c@github.com>
 <q7WClEuAxTknvj0OzHu2zSJJpE5I6F70Lq-lTqI5JgA=.172745fa-d90e-443d-9610-eed503083e96@github.com>
 <lpEkr6P1eaApuYtQ0CjthLuRbDx9E2BUAIXJMxY72M0=.c17e2502-ff07-4060-8522-a2a16319d36f@github.com>
Message-ID: <Akt3DizRh5iGdAOTS3OSZ-K_cRKSY8d9znHwl8A6-G4=.5bd7d83b-3b0e-434f-94d2-f852ec7595e3@github.com>

On Fri, 13 Jan 2023 16:06:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Something seems to be up with the lint description for this-escape - compare this:
>> 
>> Oops, will fix - thanks.
>
>> The decision was to go with drawing the "warning boundary" at the compilation unit. The reasoning is that (a) this aligns with the compiler's "knowledge boundary", i.e., we can know for sure from code inspection, and also (b) focuses the warning on the particularly pernicious aspect of these bugs, which is that they arise from the non-obvious interaction among two or more files
> 
> Sorry for being picky - you mention this "compilation unit" boundary before, but this is not really the reason here. Note that in my example B constructor calls out to a static method that is "outside" the boundary. The reason as to why my example is not flagged is simply that "escaping" is defined as "escaping into a subclass method", not just "escaping from the constructor (into some other compilation unit)".

Oops, you're right, I answered the wrong question so to speak.

The "must involve a subclass" requirement is another dimension on which a "boundary" was declared. This was also part of the original discussion.

So yes the requirement is: "requires involvement of a subclass" **AND** "that subclass lives in a separate compilation unit".

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

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


From duke at openjdk.org  Fri Jan 13 16:23:42 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 16:23:42 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <77lMG_P3_ZGjTegQictMdNN1IKjWixuzLWy5-GbHYnI=.bdbfc529-2ac8-4bba-b3a6-d08f0977e372@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
 <UiXxkJII_OrkCKyMYxiZWUQ2iiLwjcrAByp_b4_vZv0=.a0fe5083-5e0c-444a-b1ee-703608294bff@github.com>
 <RxcA0c13Q-Eh6cX1sjxDxaht8zI3Su8pIEkPSETbiTY=.cacec2de-8f7a-48d1-81f8-f6dca591e9ec@github.com>
 <77lMG_P3_ZGjTegQictMdNN1IKjWixuzLWy5-GbHYnI=.bdbfc529-2ac8-4bba-b3a6-d08f0977e372@github.com>
Message-ID: <ZrdBJxwqM9KOsvWVdX6dHDpHYcrvk8CPcc7qi5TJiPM=.b1881ed0-3613-45fb-af82-468e64040796@github.com>

On Fri, 13 Jan 2023 16:12:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Yes... I did it that way is so that it doesn't require any adaptation if/when JDK-8194743 ever gets implemented. And it keeps the code a little simpler in exchange for a little redundancy.
>> 
>> I'm happy to fix this if you think it is necessary though.
>
> I'm OK either way we can revisit this later either as part of this PR or in a future one. I let it to your consideration

Sounds good - thanks.

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

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


From vromero at openjdk.org  Fri Jan 13 17:38:27 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 17:38:27 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
Message-ID: <wxT3bVsXu8ROOdCWs6975IjcpTAKUB_5tPlycMAzBR0=.5230d005-2c21-44b5-84cb-f440b4837cc9@github.com>

On Fri, 13 Jan 2023 04:04:36 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision:
> 
>  - Fix bug where all but the last yeild statement were being ignored.
>  - Add method RefSet.mapInto() and use to refactor/clean up.
>  - Fix possible assertion failure when handling if statements.
>  - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff.
>    
>    Suggested-by:   mcimadamore
>  - Add comment regarding limitations of expresison type filtering.
>  - Add a few more DISABLED_WARNINGS to unbreak build.
>  - Clean up handling of switch expressions a bit.
>  - Remove unused method variant of analyzeTree().
>  - Avoid all caps in comments.
>  - Clarify confusing comment.
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 685:

> 683: 
> 684:     @Override
> 685:     public void visitDoLoop(JCDoWhileLoop tree) {

I was thinking, code can also loop using labels and `break` / `continue`, not something we need to cover as part of this prototype but could be a future TODO that we can document

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

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


From duke at openjdk.org  Fri Jan 13 17:52:31 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 17:52:31 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <wxT3bVsXu8ROOdCWs6975IjcpTAKUB_5tPlycMAzBR0=.5230d005-2c21-44b5-84cb-f440b4837cc9@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
 <wxT3bVsXu8ROOdCWs6975IjcpTAKUB_5tPlycMAzBR0=.5230d005-2c21-44b5-84cb-f440b4837cc9@github.com>
Message-ID: <ZXer0jyh2vZo7gyCQZUJX-I2zzF6MpPhUCFeFaVj75o=.d0971f3f-8fc5-40e2-8e07-3b476bb2c55c@github.com>

On Fri, 13 Jan 2023 17:35:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision:
>> 
>>  - Fix bug where all but the last yeild statement were being ignored.
>>  - Add method RefSet.mapInto() and use to refactor/clean up.
>>  - Fix possible assertion failure when handling if statements.
>>  - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff.
>>    
>>    Suggested-by:   mcimadamore
>>  - Add comment regarding limitations of expresison type filtering.
>>  - Add a few more DISABLED_WARNINGS to unbreak build.
>>  - Clean up handling of switch expressions a bit.
>>  - Remove unused method variant of analyzeTree().
>>  - Avoid all caps in comments.
>>  - Clarify confusing comment.
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 685:
> 
>> 683: 
>> 684:     @Override
>> 685:     public void visitDoLoop(JCDoWhileLoop tree) {
> 
> I was thinking, code can also loop using labels and `break` / `continue`, not something we need to cover as part of this prototype but could be a future TODO that we can document

Hah - I didn't think of that. But actually I don't think we would miss anything (see if you agree).

The code "executes" every loop, in a sort-of simulation, adding references until the set of references converges. Moreover, that reference set is "append only" while this is happening.

Therefore, during actual execution, a break or continue may cause less code to be executed than in our simulation, but never more code than our simulation. So during actual execution it might be that fewer actual 'this' references are created, but never more.

Therefore, this effect might cause false positives (which of course we already have with loops and code in general because we take all possible branches), but never false negatives.

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

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


From duke at openjdk.org  Fri Jan 13 19:09:54 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 19:09:54 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision:

 - Use more idiomatic test for java.lang.Object.
 - Revert 27cb30129; the error was actually fixed in edf3c3f51.
 - Fix formatting issue with the "this-escape" --help-lint description.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/edf3c3f5..ae37ff7c

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

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

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


From vromero at openjdk.org  Fri Jan 13 19:20:29 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 19:20:29 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <ZXer0jyh2vZo7gyCQZUJX-I2zzF6MpPhUCFeFaVj75o=.d0971f3f-8fc5-40e2-8e07-3b476bb2c55c@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
 <wxT3bVsXu8ROOdCWs6975IjcpTAKUB_5tPlycMAzBR0=.5230d005-2c21-44b5-84cb-f440b4837cc9@github.com>
 <ZXer0jyh2vZo7gyCQZUJX-I2zzF6MpPhUCFeFaVj75o=.d0971f3f-8fc5-40e2-8e07-3b476bb2c55c@github.com>
Message-ID: <9xqxePs8UvBJIyPMojy6Bjbl7h3VguJcIwjFhbPr_78=.5ed61dac-21e7-4214-8faf-85f5612f5b46@github.com>

On Fri, 13 Jan 2023 17:49:05 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 685:
>> 
>>> 683: 
>>> 684:     @Override
>>> 685:     public void visitDoLoop(JCDoWhileLoop tree) {
>> 
>> I was thinking, code can also loop using labels and `break` / `continue`, not something we need to cover as part of this prototype but could be a future TODO that we can document
>
> Hah - I didn't think of that. But actually I don't think we would miss anything (see if you agree).
> 
> The code "executes" every loop, in a sort-of simulation, adding references until the set of references converges. Moreover, that reference set is "append only" while this is happening.
> 
> Therefore, during actual execution, a break or continue may cause less code to be executed than in our simulation, but never more code than our simulation. So during actual execution it might be that fewer actual 'this' references are created, but never more.
> 
> Therefore, this effect might cause false positives (which of course we already have with loops and code in general because we take all possible branches), but never false negatives.

yep I agree

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

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


From kizune at openjdk.org  Fri Jan 13 19:32:17 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 13 Jan 2023 19:32:17 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v8]
In-Reply-To: <O3Az9Np5wHv6eR6gUX87qMZzXQIeNWVwlIisGhIHBTU=.1c645dc6-decc-4fdd-b8d0-92e98d0596fe@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
 <O3Az9Np5wHv6eR6gUX87qMZzXQIeNWVwlIisGhIHBTU=.1c645dc6-decc-4fdd-b8d0-92e98d0596fe@github.com>
Message-ID: <sb0rXRyE8FuxqcX8fegkqOHtTzXOV47_jzRk1r5-63Q=.8a4f201b-0e8e-46a3-9522-3fa0e7b96fa6@github.com>

On Tue, 10 Jan 2023 11:27:50 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> [OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   It is better to force the "ensureClassInitialized" as any other getters in this class. To make sure the field is up-to-date even if it was initialized on another thread.

Marked as reviewed by kizune (Reviewer).

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

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


From asemenov at openjdk.org  Fri Jan 13 19:43:22 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 13 Jan 2023 19:43:22 GMT
Subject: Integrated: 8298644 JNI call of getCurrentComponent on a wrong thread
In-Reply-To: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
Message-ID: <eL6M9h1_-2ci1cxhbDiN-Y4hklHCEBrySR5xWhPrJHs=.50597db5-884c-4156-aaf8-ecf2512cd73d@github.com>

On Wed, 14 Dec 2022 10:47:09 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> [OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

This pull request has now been integrated.

Changeset: 8cb25d3d
Author:    Artem Semenov <asemenov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8cb25d3de494c6d9357a1c199e1a9dbff9be9948
Stats:     82 lines in 4 files changed: 60 ins; 15 del; 7 mod

8298644: JNI call of getCurrentComponent on a wrong thread

Reviewed-by: avu, serb, kizune

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

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


From aivanov at openjdk.org  Fri Jan 13 19:57:26 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 13 Jan 2023 19:57:26 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v6]
In-Reply-To: <8au3Az8YmQ2nUEBoHLfFhGP1x12IisI0y_LnU07xhNE=.4933ff2e-2683-42a7-ae01-6b8da98b0d58@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <8au3Az8YmQ2nUEBoHLfFhGP1x12IisI0y_LnU07xhNE=.4933ff2e-2683-42a7-ae01-6b8da98b0d58@github.com>
Message-ID: <C8F4GtuT1RncIjOPjFVtrt2kL2H2b5WVd24XPtHaP1E=.0c7356f8-1cc4-4826-8287-54f6f4b52115@github.com>

On Wed, 11 Jan 2023 23:20:02 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as functional parameter to the method.  
>> 
>> Following are the usual steps for any border scaling -
>> 
>> - Resetting transform.
>> - Calculating new width, height, x & y-translations.
>> - Perform the required border rendering.
>> - And at the end restore the previous transform.
>> 
>> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
>> 
>> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
>> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
>> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
>> 
>> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.
>
> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - removed unused parameters, old stroke changes
>  - Merge branch 'master' into RefactorBorder_8294484
>  - moved strokeWidth logic to individual classes
>  - review changes
>  - Revert "test changes"
>    
>    This reverts commit abed51bd420941d8efa7b779b86257978f56810e.
>  - test changes
>  - minor changes
>  - Merge branch 'master' into RefactorBorder_8294484
>  - Merge branch 'master' into RefactorBorder_8294484
>  - review changes
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/43847c43...9caca6b2

Looks good to me.

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 173:

> 171: 
> 172:             // if m01 or m10 is non-zero, then there is a rotation or shear
> 173:             // or if scale=1, skip resetting the transform

Suggestion:

            // if m01 or m10 is non-zero, then there is a rotation or shear,
            // or if scale=1, skip resetting the transform in these cases

The added comma separates the two sentences. The added ?in these cases? clarifies that we don't reset in either of the two cases: m01 or m10 is non-zero or scale is 1.

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 161:

> 159:         if (g instanceof Graphics2D) {
> 160:             Graphics2D g2d = (Graphics2D) g;
> 161:             g2d.setStroke(new BasicStroke((float) stkWidth));

There's only one statement left inside the `if` block, shall get rid of another local variable?

            ((Graphics2D) g).setStroke(new BasicStroke((float) stkWidth));

src/java.desktop/share/classes/javax/swing/border/LineBorder.java line 153:

> 151:         if ((this.thickness > 0) && (g instanceof Graphics2D)) {
> 152:             Graphics2D g2d = (Graphics2D) g;
> 153:             int offs = this.thickness * (int) scaleFactor;

It looks good, however, I suggest re-arranging the code a bit:


            Graphics2D g2d = (Graphics2D) g;

            Color oldColor = g2d.getColor();
            g2d.setColor(this.lineColor);

            Shape outer;
            Shape inner;

            int offs = this.thickness * (int) scaleFactor;
            int size = offs + offs;
            if (this.roundedCorners) {
// following code


That is add a blank line after `g2d` declaration. Then save the old color; the next block is declaration for `outer` and `inner`; followed by the block with `offs` and `size` right before they're used.

src/java.desktop/share/classes/javax/swing/border/LineBorder.java line 173:

> 171:             path.append(inner, false);
> 172:             g2d.fill(path);
> 173:             g.setColor(oldColor);

Suggestion:


            g2d.setColor(oldColor);

Use `g2d` as it was originally and add a blank line to separate fill ? painting the border ? from the cleanup, restoring the color.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 294:

> 292:                     Graphics2D g2d = (Graphics2D) g;
> 293:                     g2d.setStroke(new BasicStroke((float) stkWidth));
> 294:                 }

Suggestion:

                if (g instanceof Graphics2D) {
                    ((Graphics2D) g).setStroke(new BasicStroke((float) stkWidth));
                }

?

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

Marked as reviewed by aivanov (Reviewer).

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


From honkar at openjdk.org  Fri Jan 13 20:13:23 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 13 Jan 2023 20:13:23 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v6]
In-Reply-To: <C8F4GtuT1RncIjOPjFVtrt2kL2H2b5WVd24XPtHaP1E=.0c7356f8-1cc4-4826-8287-54f6f4b52115@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <8au3Az8YmQ2nUEBoHLfFhGP1x12IisI0y_LnU07xhNE=.4933ff2e-2683-42a7-ae01-6b8da98b0d58@github.com>
 <C8F4GtuT1RncIjOPjFVtrt2kL2H2b5WVd24XPtHaP1E=.0c7356f8-1cc4-4826-8287-54f6f4b52115@github.com>
Message-ID: <2eJ6E_FnDrI0-ewmq6BgrEpRAC_VsQoxWfhoDiWgGI4=.228fb93a-2de8-4515-82a4-6e6e3676d992@github.com>

On Fri, 13 Jan 2023 19:35:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - removed unused parameters, old stroke changes
>>  - Merge branch 'master' into RefactorBorder_8294484
>>  - moved strokeWidth logic to individual classes
>>  - review changes
>>  - Revert "test changes"
>>    
>>    This reverts commit abed51bd420941d8efa7b779b86257978f56810e.
>>  - test changes
>>  - minor changes
>>  - Merge branch 'master' into RefactorBorder_8294484
>>  - Merge branch 'master' into RefactorBorder_8294484
>>  - review changes
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/43847c43...9caca6b2
>
> src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 161:
> 
>> 159:         if (g instanceof Graphics2D) {
>> 160:             Graphics2D g2d = (Graphics2D) g;
>> 161:             g2d.setStroke(new BasicStroke((float) stkWidth));
> 
> There's only one statement left inside the `if` block, shall get rid of another local variable?
> 
>             ((Graphics2D) g).setStroke(new BasicStroke((float) stkWidth));

@aivanov-jdk In case g isn't an instance of Graphic2d, a default value for strokeWidth is required outside of if block as it is used within `paintBorderShadow `& `paintBorderHighlight`.

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

PR: https://git.openjdk.org/jdk/pull/11571


From vromero at openjdk.org  Fri Jan 13 20:19:53 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 20:19:53 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
Message-ID: <CodWhrjrsXJw6ibUoeqFzUfN-D7ME9Czwq4NTCGPuW0=.5de7c798-3820-4266-abaf-7d614cbf1b25@github.com>

On Fri, 13 Jan 2023 19:09:54 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use more idiomatic test for java.lang.Object.
>  - Revert 27cb30129; the error was actually fixed in edf3c3f51.
>  - Fix formatting issue with the "this-escape" --help-lint description.

test/langtools/tools/javac/warnings/ThisEscape/ThisEscapeBasic.java line 8:

> 6:  */
> 7: 
> 8: public class ThisEscapeBasic {

I wonder if it could be better to just fold most of these tests in particular the small ones and create just one, or a few tests, with several subclasses, that will reduce the overhead if in the future we change the code and we need to change the golden files.

-------------

PR: https://git.openjdk.org/jdk/pull/11874


From vromero at openjdk.org  Fri Jan 13 20:24:46 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 20:24:46 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
Message-ID: <C1dC7U69q67lgSFzmm1ntOzHAm_BcqisYnlAhekzAeo=.60148dca-01d1-4cee-8687-d3bba5aabc24@github.com>

On Fri, 13 Jan 2023 19:09:54 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use more idiomatic test for java.lang.Object.
>  - Revert 27cb30129; the error was actually fixed in edf3c3f51.
>  - Fix formatting issue with the "this-escape" --help-lint description.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1088:

> 1086:     private <T extends JCTree> void visitLooped(T tree, Consumer<T> visitor) {
> 1087:         visitScoped(tree, false, t -> {
> 1088:             while (true) {

I have also been thinking if the loop analysis could go wild and execute a large, unbound number of times. But it seems from Archie's experiments that this probably won't occur in "normal" code and worst case scenario if that were to occur we can always limit the number of times we will process loops to a set number of times

-------------

PR: https://git.openjdk.org/jdk/pull/11874


From honkar at openjdk.org  Fri Jan 13 20:36:46 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 13 Jan 2023 20:36:46 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v7]
In-Reply-To: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
Message-ID: <YPgkv5fhlsqkJI7qvEr9guo6JbOMF8gn9DfEK_8kVCY=.c11980fc-9f33-4119-8181-ed712c76fb3d@github.com>

> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as functional parameter to the method.  
> 
> Following are the usual steps for any border scaling -
> 
> - Resetting transform.
> - Calculating new width, height, x & y-translations.
> - Perform the required border rendering.
> - And at the end restore the previous transform.
> 
> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
> 
> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
> 
> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.

Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision:

 - copyright year updated
 - formatting changes, docs added

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11571/files
  - new: https://git.openjdk.org/jdk/pull/11571/files/9caca6b2..ffb3dd17

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11571&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11571&range=05-06

  Stats: 45 lines in 4 files changed: 24 ins; 2 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/11571.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11571/head:pull/11571

PR: https://git.openjdk.org/jdk/pull/11571


From duke at openjdk.org  Fri Jan 13 21:01:54 2023
From: duke at openjdk.org (Rajat Mahajan)
Date: Fri, 13 Jan 2023 21:01:54 GMT
Subject: RFR: 8286581: Make Java process DPI Aware if sun.java2d.dpiaware
 property is set
Message-ID: <HnbTtI7Q0467OzM1jTs1_yGl4ZZTzIEuQLuyUyseXLY=.ce6942e5-82e6-430b-a094-544a7d0ff76f@github.com>

I tested by removing dpi-awareness settings from the manifest file, and then running my app with -Dsun.java2d.dpiaware=false. This showed java.exe as "Unaware" in task-manager, and with it set to true I saw "Per-Monitor (v2)" dpi awareness for java.exe.

-------------

Commit messages:
 - 8286581: Make Java process DPI Aware if sun.java2d.dpiaware property is set

Changes: https://git.openjdk.org/jdk/pull/11998/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11998&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286581
  Stats: 14 lines in 1 file changed: 3 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/11998.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11998/head:pull/11998

PR: https://git.openjdk.org/jdk/pull/11998


From duke at openjdk.org  Fri Jan 13 21:23:24 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 21:23:24 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <CodWhrjrsXJw6ibUoeqFzUfN-D7ME9Czwq4NTCGPuW0=.5de7c798-3820-4266-abaf-7d614cbf1b25@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
 <CodWhrjrsXJw6ibUoeqFzUfN-D7ME9Czwq4NTCGPuW0=.5de7c798-3820-4266-abaf-7d614cbf1b25@github.com>
Message-ID: <dQ-a4bBPdZfPNchKmqNSTVi_MwWV8XHC8toQ5Os8MR8=.fbfb559d-5ba6-4f14-8ec3-5eb1fab8215b@github.com>

On Fri, 13 Jan 2023 20:16:25 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Use more idiomatic test for java.lang.Object.
>>  - Revert 27cb30129; the error was actually fixed in edf3c3f51.
>>  - Fix formatting issue with the "this-escape" --help-lint description.
>
> test/langtools/tools/javac/warnings/ThisEscape/ThisEscapeBasic.java line 8:
> 
>> 6:  */
>> 7: 
>> 8: public class ThisEscapeBasic {
> 
> I wonder if it could be better to just fold most of these tests in particular the small ones and create just one, or a few tests, with several subclasses, that will reduce the overhead if in the future we change the code and we need to change the golden files.

I really don't have any informed opinion on this. I can see arguments both ways... putting all you eggs in one basket can be seen alternately as foolhardy or highly efficient :)

FWIW in the past I've had problems with trying to combine multiples tests that generate errors into one file. The compiler seems to like to bail out early when it sees errors. I guess that experience was working subconsciously.

Of course that doesn't apply here as these are all warnings. And a bunch of separate files make the test run slower.

So I agree with you - I'll consolidate them.

-------------

PR: https://git.openjdk.org/jdk/pull/11874


From duke at openjdk.org  Fri Jan 13 21:31:25 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 21:31:25 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <C1dC7U69q67lgSFzmm1ntOzHAm_BcqisYnlAhekzAeo=.60148dca-01d1-4cee-8687-d3bba5aabc24@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
 <C1dC7U69q67lgSFzmm1ntOzHAm_BcqisYnlAhekzAeo=.60148dca-01d1-4cee-8687-d3bba5aabc24@github.com>
Message-ID: <YeWkbLGMsOSWBdyO1UAWlq60X7TdWdH8UU2JU80dNGg=.eecfe4c1-cc7f-419f-a9d4-35861172ae68@github.com>

On Fri, 13 Jan 2023 20:21:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Use more idiomatic test for java.lang.Object.
>>  - Revert 27cb30129; the error was actually fixed in edf3c3f51.
>>  - Fix formatting issue with the "this-escape" --help-lint description.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1088:
> 
>> 1086:     private <T extends JCTree> void visitLooped(T tree, Consumer<T> visitor) {
>> 1087:         visitScoped(tree, false, t -> {
>> 1088:             while (true) {
> 
> I have also been thinking if the loop analysis could go wild and execute a large, unbound number of times. But it seems from Archie's experiments that this probably won't occur in "normal" code and worst case scenario if that were to occur we can always limit the number of times we will process loops to a set number of times

The number of times around any single loop is bounded by the number of new references that can possibly be created during the analysis of that loop.

That number is at most 2 * (1 + 1 + 1 + 1 + N) where N is the number of parameters and/or variables declared in that scope (the 2 is for direct or indirect, and the 1's are for each of the singleton reference types `ThisRef`, `OuterRef`, `ExprRef`, and `ReturnRef`).

If you have nested scopes A, B, C each with Na, Nb, and Nc variables declared therein (respectively), then the bound would be something like 2 * (1 + 1 + 1 + 1 + Na + (Na * Nb) + (Na * Nb * Nc)) worst case (waving hands here).

-------------

PR: https://git.openjdk.org/jdk/pull/11874


From duke at openjdk.org  Fri Jan 13 21:36:30 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 21:36:30 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <ZrdBJxwqM9KOsvWVdX6dHDpHYcrvk8CPcc7qi5TJiPM=.b1881ed0-3613-45fb-af82-468e64040796@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
 <UiXxkJII_OrkCKyMYxiZWUQ2iiLwjcrAByp_b4_vZv0=.a0fe5083-5e0c-444a-b1ee-703608294bff@github.com>
 <RxcA0c13Q-Eh6cX1sjxDxaht8zI3Su8pIEkPSETbiTY=.cacec2de-8f7a-48d1-81f8-f6dca591e9ec@github.com>
 <77lMG_P3_ZGjTegQictMdNN1IKjWixuzLWy5-GbHYnI=.bdbfc529-2ac8-4bba-b3a6-d08f0977e372@github.com>
 <ZrdBJxwqM9KOsvWVdX6dHDpHYcrvk8CPcc7qi5TJiPM=.b1881ed0-3613-45fb-af82-468e64040796@github.com>
Message-ID: <LsUhJCqzH-_ufn6NlYb8oplhN6Q2lv1mzCQfnUNqDMg=.d29ca327-2d18-447b-af4e-95dcc9d16236@github.com>

On Fri, 13 Jan 2023 16:20:41 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> I'm OK either way we can revisit this later either as part of this PR or in a future one. I let it to your consideration
>
> Sounds good - thanks.

Ah. I just realized that we need to do it your way because of the following bug:

Suppose you have a constructor and a field with initializer that both leak, but you have `@SuppressWarnings("this-escape")` on the constructor.

Then the leak for the field will never be reported because we never get to it.

I'll fix.

-------------

PR: https://git.openjdk.org/jdk/pull/11874


From aivanov at openjdk.org  Fri Jan 13 21:59:19 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 13 Jan 2023 21:59:19 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <3HxXiTzAl_so2TGaDPvdW-rL7hY2nMKNA3225gWPkQc=.17692405-3738-4139-97a7-8438182e4266@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
 <DD5uVC90-DPgmwfJXNEgnLj_wxHGTD7_uKMZBwNLHa8=.6a564a17-23d4-4da8-8381-c882b852aaaa@github.com>
 <c4Qx6gF9iiaJdMaOybsl_4cNgqu8KPNOQQH2zBDAOzU=.a72f2f21-5212-4337-b3f3-ccff0a39c728@github.com>
 <jH6H-chU7-m3gPJRb1v2StPHplL06eKXHvUIrxV-FYE=.f6f34982-26c3-43b9-9ac0-ddb1a4fd1c9a@github.com>
 <PumLFS7NJwkLt_U6b3CCraoRha0lG6oy_K8v-uFTtV4=.5467e88c-f34b-449c-a71b-eefbe72999ba@github.com>
 <A2gaQz19gcGEOYHSrUI1kpoGZAGXfSzIyUdGG7tnQgk=.9b95ef26-91b8-4ef4-9a6b-4aab6ef4aae5@github.com>
 <8NCbdLCtapYaDVZQrl2rLo6NlCO8JrFzXr4OYMe4AWU=.6f24a709-00ad-4413-be0c-4961cced1110@github.com>
 <3HxXiTzAl_so2TGaDPvdW-rL7hY2nMKNA3225gWPkQc=.17692405-3738-4139-97a7-8438182e4266@github.com>
Message-ID: <KIkSFjM_CcGDKxTNAVFYpoc6N3tL9vNVAA9IJpPAmso=.4be57cac-f5a8-4a0e-b7b9-8d8de9afc772@github.com>

On Thu, 12 Jan 2023 02:07:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> > Not only _Downloads_ folder returns null, as I was mentioning it was varying for multiple test runs.
>>> 
>>> I remember you were saying that only this one was affected. I may have missed that other folders were affected as well.
>>> 
>>> > Then submitting a new bug for ImageIcon failing to load Image in headless systems right?
>>> 
>>> Yes, for this particular problem: a folder icon cannot be fetched from Windows on a headless system.
>> 
>> Created - [JDK-8299893](https://bugs.openjdk.org/browse/JDK-8299893). Shall I integrate this PR by removing the test from problemList?
>
>> Created - [JDK-8299893](https://bugs.openjdk.org/browse/JDK-8299893). Shall I integrate this PR by removing the test from problemList?
> 
> Did we have a chance to reproduce it at least once other than accidentally in mach5? If not that not necessarily is a root cause, I doubt that the new bug will not be fixed any time soon.

@mrserb was absolutely right! Marking the test `@headful` will not resolve the problem, it will make us forget about the problem, and apparently it may manifest itself on headful systems too.

I added my own traces and I've found three issues with the code.

**`E_PENDING`**
https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1157-L1158

An icon handle could be negative: `hIcon = 0xffffffffa25400f7` is perfectly valid handle but it's rejected by our current code.

The same problem exists two lines below:
https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1161

**Result of `Extract`**
https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp#L997

The result of calling `Extract` isn't verified.

This second error led to returning an invalid handle to the *(default)* folder icon. I saw it only for 16?16 icons, in all these cases something that looks like handle is returned, that is `hIcon` isn't null. Yet when the icon bits are extracted, `fn_GetIconInfo` returns an error code 0x57a - _Invalid cursor handle_.

The two errors combined lead to quite a few *random* failures. No particular host reproduced the problem more often. Sometimes 5 of 10 tests failed, sometimes only 1 of 10. Yet none of the test runs I submitted succeeded before I resolved the above issues.

I'll re-assign the bug to myself and submit a new PR after I do additional tests.

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From vromero at openjdk.org  Fri Jan 13 22:04:03 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 22:04:03 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <LsUhJCqzH-_ufn6NlYb8oplhN6Q2lv1mzCQfnUNqDMg=.d29ca327-2d18-447b-af4e-95dcc9d16236@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
 <UiXxkJII_OrkCKyMYxiZWUQ2iiLwjcrAByp_b4_vZv0=.a0fe5083-5e0c-444a-b1ee-703608294bff@github.com>
 <RxcA0c13Q-Eh6cX1sjxDxaht8zI3Su8pIEkPSETbiTY=.cacec2de-8f7a-48d1-81f8-f6dca591e9ec@github.com>
 <77lMG_P3_ZGjTegQictMdNN1IKjWixuzLWy5-GbHYnI=.bdbfc529-2ac8-4bba-b3a6-d08f0977e372@github.com>
 <ZrdBJxwqM9KOsvWVdX6dHDpHYcrvk8CPcc7qi5TJiPM=.b1881ed0-3613-45fb-af82-468e64040796@github.com>
 <LsUhJCqzH-_ufn6NlYb8oplhN6Q2lv1mzCQfnUNqDMg=.d29ca327-2d18-447b-af4e-95dcc9d16236@github.com>
Message-ID: <1ylDnjbWJwdsJP-dVL1zthfhVHZbcOgnC3gxgNuKBZk=.6367e3b4-18ae-4232-b43a-c469e58f9a2d@github.com>

On Fri, 13 Jan 2023 21:33:02 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Sounds good - thanks.
>
> Ah. I just realized that we need to do it your way because of the following bug:
> 
> Suppose you have a constructor and a field with initializer that both leak, but you have `@SuppressWarnings("this-escape")` on the constructor.
> 
> Then the leak for the field will never be reported because we never get to it.
> 
> I'll fix.

yep, right in that case that leak wouldn't be reported

-------------

PR: https://git.openjdk.org/jdk/pull/11874


From duke at openjdk.org  Fri Jan 13 22:11:04 2023
From: duke at openjdk.org (Nikita Provotorov)
Date: Fri, 13 Jan 2023 22:11:04 GMT
Subject: RFR: 8282217: Key events (key char and key code) changed for Swiss
 keyboard
In-Reply-To: <N9XfS6cL8s1G98UAiEr7ZvgzQB-HX6qKGptKZe7d810=.1f5932c5-fd00-4fe8-9c0b-99f2fa71d880@github.com>
References: <N9XfS6cL8s1G98UAiEr7ZvgzQB-HX6qKGptKZe7d810=.1f5932c5-fd00-4fe8-9c0b-99f2fa71d880@github.com>
Message-ID: <P4mg2NKf8AvqIJjo1aSKxWF4aJXjLJRTlcj90zarh7Q=.8ca57273-02d0-46db-9fa1-b0b4a98960d3@github.com>

On Fri, 6 Jan 2023 22:07:33 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removed check for MapVirtualKeyEx return value causing some keys to become undefined

Hello, guys! I've just checked behavior of the fix and it actually breaks the case described in the [JDK-8139189](https://bugs.openjdk.org/browse/JDK-8139189) (to install `Programmer Dvorak` layout -> Press the key between LShift and Z on QWERTY keyboards -> Press the key C twice (which is the `I` key on the default US QWERTY layout)

Generated events before the patch (the single `?` is typed):

java.awt.event.KeyEvent[KEY_PRESSED,keyCode=65312,keyText=Compose,keyChar=Undefined keyChar,keyLocation=KEY_LOCATION_STANDARD,rawCode=226,primaryLevelUnicode=4,scancode=86,extendedKeyCode=0xff20]

java.awt.event.KeyEvent[KEY_RELEASED,keyCode=65312,keyText=Compose,keyChar=Undefined keyChar,keyLocation=KEY_LOCATION_STANDARD,rawCode=226,primaryLevelUnicode=4,scancode=86,extendedKeyCode=0xff20]

java.awt.event.KeyEvent[KEY_PRESSED,keyCode=67,keyText=C,keyChar='c',keyLocation=KEY_LOCATION_STANDARD,rawCode=67,primaryLevelUnicode=99,scancode=23,extendedKeyCode=0x43]

java.awt.event.KeyEvent[KEY_RELEASED,keyCode=67,keyText=C,keyChar='c',keyLocation=KEY_LOCATION_STANDARD,rawCode=67,primaryLevelUnicode=99,scancode=23,extendedKeyCode=0x43]

java.awt.event.KeyEvent[KEY_PRESSED,keyCode=67,keyText=C,keyChar='c',keyLocation=KEY_LOCATION_STANDARD,rawCode=67,primaryLevelUnicode=99,scancode=23,extendedKeyCode=0x43]

java.awt.event.KeyEvent[KEY_TYPED,keyCode=0,keyText=Unknown keyCode: 0x0,keyChar='?',keyLocation=KEY_LOCATION_UNKNOWN,rawCode=0,primaryLevelUnicode=0,scancode=0,extendedKeyCode=0x0]

java.awt.event.KeyEvent[KEY_RELEASED,keyCode=67,keyText=C,keyChar='c',keyLocation=KEY_LOCATION_STANDARD,rawCode=67,primaryLevelUnicode=99,scancode=23,extendedKeyCode=0x43]



Including the patch (`cc` are typed):

java.awt.event.KeyEvent[KEY_PRESSED,keyCode=65312,keyText=Compose,keyChar=' ',keyLocation=KEY_LOCATION_STANDARD,rawCode=226,primaryLevelUnicode=4,scancode=86,extendedKeyCode=0xff20]

java.awt.event.KeyEvent[KEY_RELEASED,keyCode=65312,keyText=Compose,keyChar=' ',keyLocation=KEY_LOCATION_STANDARD,rawCode=226,primaryLevelUnicode=4,scancode=86,extendedKeyCode=0xff20]

java.awt.event.KeyEvent[KEY_PRESSED,keyCode=67,keyText=C,keyChar='c',keyLocation=KEY_LOCATION_STANDARD,rawCode=67,primaryLevelUnicode=99,scancode=23,extendedKeyCode=0x43]

java.awt.event.KeyEvent[KEY_TYPED,keyCode=0,keyText=Unknown keyCode: 0x0,keyChar='c',keyLocation=KEY_LOCATION_UNKNOWN,rawCode=0,primaryLevelUnicode=0,scancode=0,extendedKeyCode=0x0]

java.awt.event.KeyEvent[KEY_RELEASED,keyCode=67,keyText=C,keyChar='c',keyLocation=KEY_LOCATION_STANDARD,rawCode=67,primaryLevelUnicode=99,scancode=23,extendedKeyCode=0x43]

java.awt.event.KeyEvent[KEY_PRESSED,keyCode=67,keyText=C,keyChar='c',keyLocation=KEY_LOCATION_STANDARD,rawCode=67,primaryLevelUnicode=99,scancode=23,extendedKeyCode=0x43]

java.awt.event.KeyEvent[KEY_TYPED,keyCode=0,keyText=Unknown keyCode: 0x0,keyChar='c',keyLocation=KEY_LOCATION_UNKNOWN,rawCode=0,primaryLevelUnicode=0,scancode=0,extendedKeyCode=0x0]

java.awt.event.KeyEvent[KEY_RELEASED,keyCode=67,keyText=C,keyChar='c',keyLocation=KEY_LOCATION_STANDARD,rawCode=67,primaryLevelUnicode=99,scancode=23,extendedKeyCode=0x43]

-------------

PR: https://git.openjdk.org/jdk/pull/11887


From aivanov at openjdk.org  Fri Jan 13 22:12:04 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 13 Jan 2023 22:12:04 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
Message-ID: <t8BAsWUcbnbMYF08Z8Dckr2reyW_5TtCsx55Tm4AJ2Y=.8ed02967-ba68-462c-ad03-4307f1941acb@github.com>

On Thu, 22 Dec 2022 05:13:34 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Review is revoked as per my recent comment.

-------------

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11104


From duke at openjdk.org  Fri Jan 13 22:48:59 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 22:48:59 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v10]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <bDUtLc3rL8E_h_r1dKHG3L5FMm90Hn-ujFxiVREnaG8=.4b15343c-2501-4c48-9f9c-901a4407662b@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Fix bug where field initializer warnings could be incorrectly suppressed.
 - Consolidate all the unit tests that generate warnings into one.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/ae37ff7c..0b06dc32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=08-09

  Stats: 1454 lines in 35 files changed: 658 ins; 762 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

PR: https://git.openjdk.org/jdk/pull/11874


From duke at openjdk.org  Sat Jan 14 01:57:32 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 14 Jan 2023 01:57:32 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <w3FeW11M6pr-DOmW1v_4Doa9t52s55Pedi5fnOOarbc=.aa10dd51-0ff0-40ad-977e-7091fea00d4e@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>
 <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>
 <db_e6O3GAPZPRU1kJGawP19tAb-DmiNduGa51LCD4VE=.1b70448a-7b9b-4d99-9828-e3186c13a73c@github.com>
 <Piegj-aQWN-4MPZoB-zt1IW9Jp_OPCDfFvvpOVdGDkI=.74995898-e2c1-42c7-8362-408668a49561@github.com>
 <w3FeW11M6pr-DOmW1v_4Doa9t52s55Pedi5fnOOarbc=.aa10dd51-0ff0-40ad-977e-7091fea00d4e@github.com>
Message-ID: <xUWBWB697H5u_kP4Wc3YFEVltggLUgqef3nf6qksjzM=.eb97c793-0249-453a-bfa8-b660b2176cbf@github.com>

On Fri, 13 Jan 2023 00:57:14 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Ok - I thought false negative was the thing to absolutely avoid - and that was the no. 1 concern. I think a possible approach to keep both the filtering and the code more or less similar to what you have, is to save the type of the expression in the ExprRef. Then, I believe that, at the end of scan() you can just get whatever type is there, and check that it's the correct one, if not drop it.
>
>>  Ok - I thought false negative was the thing to absolutely avoid - and that was the no. 1 concern.
> 
> You're right. I think at the time I reasoned that it would be unusual enough for the type of an expression to start as an instanceof X, then change to not being an instanceof X, and then change back, that it was worth it to go ahead and filter these out. But admittedly that was based on intuition, not science.
> 
>> I think a possible approach to keep both the filtering and the code more or less similar to what you have, is to save the type of the expression in the ExprRef. Then, I believe that, at the end of scan() you can just get whatever type is there, and check that it's the correct one, if not drop it.
> 
> That's a nice idea... thanks. I'll play around with it some.

I was curious how much of a difference this type filtering makes, so I built the JDK with and without it.

The results were identical except for one case:

package java.lang.invoke;
...
public abstract sealed class CallSite permits ConstantCallSite, MutableCallSite, VolatileCallSite {
...
    CallSite(MethodType targetType, MethodHandle createTargetHook) throws Throwable {
        this(targetType); // need to initialize target to make CallSite.type() work in createTargetHook
        ConstantCallSite selfCCS = (ConstantCallSite) this;
        MethodHandle boundTarget = (MethodHandle) createTargetHook.invokeWithArguments(selfCCS);
        setTargetNormal(boundTarget); // ConstantCallSite doesn't publish CallSite.target
        UNSAFE.storeStoreFence(); // barrier between target and isFrozen updates
    }

When we do type filtering, `(ConstantCallSite) this` causes the 'this' reference to be discarded so no leak is reported on the next line for `invokeWithArguments(selfCCS)`. Just a side note, there is also a leak on the next line because final method `setTargetNormal()` invokes `MethodHandleNatives.setCallSiteTargetNormal(this, newTarget)`, so a leak does get reported anyway even with type filtering.

When type filtering is disabled, we report a leak at `invokeWithArguments(selfCCS)` - which is accurate.

So what did we learn?

First it looks like type filtering has very minimal effect. I think this is because it requires some version of two casts in a row in and out of type compatibility, and this is probably very rare.

But looking at the one data point we do have, the type filtering did in fact cause a false negative.

And when building the entire JDK, it causes zero net new false positives.

So to me this is evidence that we should just remove the type filtering altogether...

@vicente-romero-oracle your thoughts?

-------------

PR: https://git.openjdk.org/jdk/pull/11874


From duke at openjdk.org  Sat Jan 14 07:26:52 2023
From: duke at openjdk.org (SWinxy)
Date: Sat, 14 Jan 2023 07:26:52 GMT
Subject: RFR: 8300166: Unused array allocation in ProcessPath.doProcessPath
In-Reply-To: <_UJnizZOuCPw1KX0NA1zhrjfQp0nL73NOXlSkNz-VxQ=.4d89f2c5-87b0-46dd-9aeb-1c19e1636a29@github.com>
References: <_UJnizZOuCPw1KX0NA1zhrjfQp0nL73NOXlSkNz-VxQ=.4d89f2c5-87b0-46dd-9aeb-1c19e1636a29@github.com>
Message-ID: <pBlnBFsXqTFbJ3UB-ale3lZBcnd6036izyb87p-TEOA=.b2035d70-e022-4c86-a7ac-88e3ab43f58b@github.com>

On Sat, 7 Jan 2023 19:29:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> I don't see this array in `src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c` too. Seems leftovers from refactoring?

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/11894


From aturbanov at openjdk.org  Sat Jan 14 07:26:51 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 14 Jan 2023 07:26:51 GMT
Subject: RFR: 8300166: Unused array allocation in ProcessPath.doProcessPath
Message-ID: <_UJnizZOuCPw1KX0NA1zhrjfQp0nL73NOXlSkNz-VxQ=.4d89f2c5-87b0-46dd-9aeb-1c19e1636a29@github.com>

I don't see this array in `src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c` too. Seems leftovers from refactoring?

-------------

Commit messages:
 - [PATCH] Unused array allocation in ProcessPath.doProcessPath

Changes: https://git.openjdk.org/jdk/pull/11894/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11894&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300166
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11894.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11894/head:pull/11894

PR: https://git.openjdk.org/jdk/pull/11894


From jiefu at openjdk.org  Sat Jan 14 14:35:00 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Sat, 14 Jan 2023 14:35:00 GMT
Subject: RFR: 8300169: Build failure with clang-15
Message-ID: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>

Hi all,

Please review the fix for the build failure with clang-15.

1. -Wbitwise-instead-of-logical

   1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
   2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
   3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings


2. -Wdeprecated-non-prototype (all the warnings are disabled)

   1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
      It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.

   2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings

   3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings


3. -Wdeprecated-builtins

   Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings

   Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202

4. -Wgnu-folding-constant

   Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings


Thanks.
Best regards,
Jie

-------------

Commit messages:
 - 8300169: Build failure with clang-15

Changes: https://git.openjdk.org/jdk/pull/12005/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12005&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300169
  Stats: 15 lines in 6 files changed: 5 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12005.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12005/head:pull/12005

PR: https://git.openjdk.org/jdk/pull/12005


From kcr at openjdk.org  Sat Jan 14 15:06:09 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 14 Jan 2023 15:06:09 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <KNSxgTc0PTTJMrnnClBbw3aWl-OiDixgplMRl-F38nc=.fc1273ad-2bce-44e7-ae1f-ddca61a37119@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the fix for the build failure with clang-15.
> 
> 1. -Wbitwise-instead-of-logical
> 
>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
> 
> 
> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
> 
>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
> 
>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
> 
>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
> 
> 
> 3. -Wdeprecated-builtins
> 
>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
> 
>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
> 
> 4. -Wgnu-folding-constant
> 
>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
> 
> 
> Thanks.
> Best regards,
> Jie

src/java.desktop/share/native/libharfbuzz/hb-meta.hh line 191:

> 189: #define hb_int_max(T) hb_int_max<T>::value
> 190: 
> 191: #if defined(__GNUC__) && __GNUC__ < 5 && !defined(__clang__)

Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm.

-------------

PR: https://git.openjdk.org/jdk/pull/12005


From jiefu at openjdk.org  Sun Jan 15 01:59:11 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Sun, 15 Jan 2023 01:59:11 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <KNSxgTc0PTTJMrnnClBbw3aWl-OiDixgplMRl-F38nc=.fc1273ad-2bce-44e7-ae1f-ddca61a37119@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <KNSxgTc0PTTJMrnnClBbw3aWl-OiDixgplMRl-F38nc=.fc1273ad-2bce-44e7-ae1f-ddca61a37119@github.com>
Message-ID: <0hacUHSSaPqiYtv3EsaC4UVe_da0hydgcTrpUpn9w6s=.ae39b693-7f04-40ab-94c0-a90f95c6c260@github.com>

On Sat, 14 Jan 2023 15:03:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm.

Thanks @kevinrushforth for your review.

Yes, it had been fixed in the upstream and I just follow it.
Please see https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 .

Or did you mean we had to sync the whole harfbuzz with the upstream?
If so, I would suggest doing it in a separate PR.
What do you think?
Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/12005


From duke at openjdk.org  Sun Jan 15 04:02:10 2023
From: duke at openjdk.org (SWinxy)
Date: Sun, 15 Jan 2023 04:02:10 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <mNZ-1gX-Q7lQ9jE5CyMcLXPkonw23E21s-Z2NNi1_lo=.bbe0fc1c-b048-4302-b240-0d020a78268f@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
 <mNZ-1gX-Q7lQ9jE5CyMcLXPkonw23E21s-Z2NNi1_lo=.bbe0fc1c-b048-4302-b240-0d020a78268f@github.com>
Message-ID: <gYyNb6_n88O1M4_rnd1_DLhT5xafgPCLS-IzOMfF_3Q=.34b0c82b-9824-4b2d-ab00-12928c54f815@github.com>

On Wed, 11 Jan 2023 07:52:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Is it possible to change the current UI style based on the context from the separate component?

Looks like it. It _could_ be addressed by passing the `list` object into `SynthListUI#updateStyle` instead. Or by making these classes not implement listeners.

-------------

PR: https://git.openjdk.org/jdk/pull/11875


From duke at openjdk.org  Sun Jan 15 04:05:12 2023
From: duke at openjdk.org (SWinxy)
Date: Sun, 15 Jan 2023 04:05:12 GMT
Subject: RFR: 8293478: [java.desktop/macOS] Condense SDRenderType usages in
 QuartzRenderer.m [v3]
In-Reply-To: <laZac6ZfK1Jgj9i16ei1eWnSiE175V-5VAW1-ty8_FI=.2a474adc-3565-466e-a376-5fe2be3165e0@github.com>
References: <levplAHOHGYRedb1qypkWNb4hcv6W0rO6vF2wbfbf7M=.79250f01-b07e-41e6-b1d3-166ffde6bd76@github.com>
 <laZac6ZfK1Jgj9i16ei1eWnSiE175V-5VAW1-ty8_FI=.2a474adc-3565-466e-a376-5fe2be3165e0@github.com>
Message-ID: <3qdeZ6cgGEmFVFHY9z5YWphMctKG5bWuhku2EYh5e6g=.9f5b0ff9-b3ae-4134-9752-1b07958ef339@github.com>

On Sun, 25 Sep 2022 18:00:39 GMT, SWinxy <duke at openjdk.org> wrote:

>> The `SDRenderType` enum is often returned using a variable declared at the start of functions. These can be inlined in the `return` itself. Using a ternary operator condenses what may be 12 lines into one, in the most extreme cases. `doRectUsingCG` and `doPolyUsingCG` were both modified more than the rest, but are still basically the same.
>> 
>> Example change:
>> 
>> SDRenderType renderType = SD_Nothing;
>> 
>> if (fill == YES)
>> {
>>     renderType = SD_Fill;
>> }
>> else
>> {
>>     renderType = SD_Stroke;
>> }
>> 
>> // draw logic
>> 
>> return renderType;
>> 
>> 
>> 
>> // draw logic
>> 
>> return fill ? SD_Fill : SD_Stroke;
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Bumping for the bot.

-------------

PR: https://git.openjdk.org/jdk/pull/10174


From psadhukhan at openjdk.org  Mon Jan 16 05:35:11 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 16 Jan 2023 05:35:11 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
Message-ID: <pHTdqf0pQnv8VQCNpisrXxpJv4aMhxQWDq_hnt2p7Hg=.146b5118-09c0-47c4-b128-245801f4144e@github.com>

On Fri, 6 Jan 2023 04:42:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems Synth has two cases of updateStyle() where its argument is not passed to the getContext() call. It seems to be an oversight as in other Synth classes, the component argument passed to updateStyle is being passed to getContext().
> 
> CI tests are ok with this change and there is no new regeression with CI tests run in NimbusL&F by default..

`list` and `c` points to same object 
_javax.swing.JList[,0,0,0x0,invalid,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.synth.SynthBorder at fc8b518,flags=3355472
8,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=DerivedColor(col
or=57,105,138 parent=nimbusSelectionBackground offsets=0.0,0.0,0.0,0 pColor=57,105,138,selectionForeground=DerivedColor(color=255,255,255 parent=
nimbusLightBackground offsets=0.0,0.0,0.0,0 pColor=255,255,255,visibleRowCount=22,layoutOrientation=0]_
so there's nothing different in it between them..
I also do not seem to understand how property listener getting "separate" component can be tested from application?

-------------

PR: https://git.openjdk.org/jdk/pull/11875


From serb at openjdk.org  Mon Jan 16 08:10:51 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 16 Jan 2023 08:10:51 GMT
Subject: RFR: 8300167: Add validation of the raster's layout before using in
 native
Message-ID: <Erhi6Eslm9ab-0wUF4cDUTNWrE6m2ep91biO-PSPrlU=.84976aff-b0c6-478f-aa1d-32a0e6e1e715@github.com>

Currently, we always validate image layouts passed from java to native, except for some types of rasters. One of the reasons why the rasters are skipped is that they are not public and have their own validation during construction. But it is unclear how it works in the multithreaded case. All these objects are not thread-safe - is could be possible that we can get the raster which is not completely constructed/validated?

FYI I have started to look into this method because when I did an accidental typo in pixel format in it and got the same symptoms/crash as described [here](https://bugs.openjdk.org/browse/JDK-8278101). It might be unrelated but it is safer to fix.

-------------

Commit messages:
 - 8300167: Add validation of the raster's layout before using in native

Changes: https://git.openjdk.org/jdk/pull/12004/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12004&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300167
  Stats: 9 lines in 1 file changed: 5 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12004.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12004/head:pull/12004

PR: https://git.openjdk.org/jdk/pull/12004


From alanb at openjdk.org  Mon Jan 16 08:24:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Jan 2023 08:24:10 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <G43X3_TR0Wnisg2ugSVG--mPKEDluk5iE4hjg7PS2_8=.0c4f45af-ec1e-476e-aee9-133956cd6f35@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.

Is there a list of the issues building libjli? I don't see the in the PR or the JBS issue. For the libzip issues, are these in the native methods or when compiling the zlib code, just wondering if there are bug reports for upstream there too.

-------------

PR: https://git.openjdk.org/jdk/pull/12005


From jiefu at openjdk.org  Mon Jan 16 08:54:10 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Mon, 16 Jan 2023 08:54:10 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <G43X3_TR0Wnisg2ugSVG--mPKEDluk5iE4hjg7PS2_8=.0c4f45af-ec1e-476e-aee9-133956cd6f35@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <G43X3_TR0Wnisg2ugSVG--mPKEDluk5iE4hjg7PS2_8=.0c4f45af-ec1e-476e-aee9-133956cd6f35@github.com>
Message-ID: <qkITP57tQNke6tqHjnc3qX8zjl1nj32U02cO1Nrl1FU=.3e49f5c5-fe22-4bfc-9575-faf3f72cb8a1@github.com>

On Mon, 16 Jan 2023 08:21:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Is there a list of the issues building libjli? I don't see the in the PR or the JBS issue. For the libzip issues, are these in the native methods or when compiling the zlib code, just wondering if there are bug reports for upstream there too.

Thanks @AlanBateman for the review.

Here is the bug report while building libjli (target support_native_java.base_libjli_zadler32.o).

1 error generated.
* For target support_native_java.base_libjli_zadler32.o:

-------------

PR: https://git.openjdk.org/jdk/pull/12005


From jiefu at openjdk.org  Mon Jan 16 08:59:10 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Mon, 16 Jan 2023 08:59:10 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <qkITP57tQNke6tqHjnc3qX8zjl1nj32U02cO1Nrl1FU=.3e49f5c5-fe22-4bfc-9575-faf3f72cb8a1@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <G43X3_TR0Wnisg2ugSVG--mPKEDluk5iE4hjg7PS2_8=.0c4f45af-ec1e-476e-aee9-133956cd6f35@github.com>
 <qkITP57tQNke6tqHjnc3qX8zjl1nj32U02cO1Nrl1FU=.3e49f5c5-fe22-4bfc-9575-faf3f72cb8a1@github.com>
Message-ID: <6Mm3-SXiwwATYs4GgS9dCU-bPbj1C2zLMJffm7vgTYk=.ac455538-e0e0-4af7-ae87-af7c778d23e9@github.com>

On Mon, 16 Jan 2023 08:51:34 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> For the libzip issues, are these in the native methods or when compiling the zlib code, just wondering if there are bug reports for upstream there too.

Mainly caused by files under `src/java.base/share/native/libzip/zlib/`.
I'm not sure if there is already a bug report to the upstream.

-------------

PR: https://git.openjdk.org/jdk/pull/12005


From alanb at openjdk.org  Mon Jan 16 09:06:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Jan 2023 09:06:10 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <6Mm3-SXiwwATYs4GgS9dCU-bPbj1C2zLMJffm7vgTYk=.ac455538-e0e0-4af7-ae87-af7c778d23e9@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <G43X3_TR0Wnisg2ugSVG--mPKEDluk5iE4hjg7PS2_8=.0c4f45af-ec1e-476e-aee9-133956cd6f35@github.com>
 <qkITP57tQNke6tqHjnc3qX8zjl1nj32U02cO1Nrl1FU=.3e49f5c5-fe22-4bfc-9575-faf3f72cb8a1@github.com>
 <6Mm3-SXiwwATYs4GgS9dCU-bPbj1C2zLMJffm7vgTYk=.ac455538-e0e0-4af7-ae87-af7c778d23e9@github.com>
Message-ID: <DOy_TtzJBod7_igu0htfT89lm-EPZANaEluI2wgGBBY=.9ba04372-2915-4795-884b-0144e17f05d0@github.com>

On Mon, 16 Jan 2023 08:56:13 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Mainly caused by files under `src/java.base/share/native/libzip/zlib/`. I'm not sure if there is already a bug report to the upstream.

Maybe this one:
https://github.com/madler/zlib/issues/633

-------------

PR: https://git.openjdk.org/jdk/pull/12005


From lbourges at openjdk.org  Mon Jan 16 09:11:11 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 16 Jan 2023 09:11:11 GMT
Subject: RFR: 8300167: Add validation of the raster's layout before using
 in native
In-Reply-To: <Erhi6Eslm9ab-0wUF4cDUTNWrE6m2ep91biO-PSPrlU=.84976aff-b0c6-478f-aa1d-32a0e6e1e715@github.com>
References: <Erhi6Eslm9ab-0wUF4cDUTNWrE6m2ep91biO-PSPrlU=.84976aff-b0c6-478f-aa1d-32a0e6e1e715@github.com>
Message-ID: <aBHupjKPkvhucc0gRW7j2SxB41Flr5hS7NO0p0otj4w=.c53951d1-a628-426a-825d-4094cf5ef5b1@github.com>

On Sat, 14 Jan 2023 07:23:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Currently, we always validate image layouts passed from java to native, except for some types of rasters. One of the reasons why the rasters are skipped is that they are not public and have their own validation during construction. But it is unclear how it works in the multithreaded case. All these objects are not thread-safe - is could be possible that we can get the raster which is not completely constructed/validated?
> 
> FYI I have started to look into this method because when I did an accidental typo in pixel format in it and got the same symptoms/crash as described [here](https://bugs.openjdk.org/browse/JDK-8278101). It might be unrelated but it is safer to fix.

It seems a good idea according to me

-------------

PR: https://git.openjdk.org/jdk/pull/12004


From psadhukhan at openjdk.org  Mon Jan 16 10:34:18 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 16 Jan 2023 10:34:18 GMT
Subject: Withdrawn: 7175396: The text on label is not painted red for Nimbus
 LaF.
In-Reply-To: <iYA9P9YljBfvinZEbBIF8tWJXtZLXgBxdcBmgLKb7CU=.79a7273a-cb2e-4a80-8c29-18347a9de767@github.com>
References: <iYA9P9YljBfvinZEbBIF8tWJXtZLXgBxdcBmgLKb7CU=.79a7273a-cb2e-4a80-8c29-18347a9de767@github.com>
Message-ID: <su-lcwGX4lUfxob729-l_Qez55NDvzBxPeWH-TuIYoA=.eaba8ea4-d6fb-4198-90c5-876744c82eff@github.com>

On Wed, 14 Dec 2022 04:59:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Label.foreground UIProperty is not honored by Nimbus L&F. It needs to be Label[Enabled].textForeground which is the corresponding Synth property
> Added support for setting JLabel foreground color for Nimbus L&F

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11660


From tr at openjdk.org  Mon Jan 16 11:25:57 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 16 Jan 2023 11:25:57 GMT
Subject: RFR: 8300084: AquaFileChooserUI.getDefaultButton returns null
Message-ID: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>

In Aqua look and feel, `getDefaultButton()` of `JFileChooser` returns null. The fix overrides the method from `FileChooserUI` to return the `ApproveButton` of `FileChooser` which is similar to other L&F. 
The test is run for multiple iterations in CI machine.

-------------

Commit messages:
 - fix + test

Changes: https://git.openjdk.org/jdk/pull/12008/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12008&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300084
  Stats: 58 lines in 2 files changed: 58 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12008.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12008/head:pull/12008

PR: https://git.openjdk.org/jdk/pull/12008


From aivanov at openjdk.org  Mon Jan 16 11:43:21 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 16 Jan 2023 11:43:21 GMT
Subject: RFR: 8300084: AquaFileChooserUI.getDefaultButton returns null
In-Reply-To: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
References: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
Message-ID: <PguMVh3YROT5D4-NWy9mQ4B-UebzCXYktLbIYdwWaSY=.ca29ef8f-9188-4cd7-862d-f4aab41d7b3a@github.com>

On Mon, 16 Jan 2023 11:17:10 GMT, Tejesh R <tr at openjdk.org> wrote:

> In Aqua look and feel, `getDefaultButton()` of `JFileChooser` returns null. The fix overrides the method from `FileChooserUI` to return the `ApproveButton` of `FileChooser` which is similar to other L&F. 
> The test is run for multiple iterations in CI machine.

Looks good to me.

I doubt a separate test for this issue is worth it. This case is entirely covered by the test in #11901 for [JDK-8299522](https://bugs.openjdk.org/browse/JDK-8299522), which also ensures the button text isn't empty.

Adding 8300084 to the `@bug` tag in that test is enough. It was my [original suggestion](https://github.com/openjdk/jdk/pull/11901#discussion_r1068659255):

> Now you can fix this bug so that Aqua L&F doesn't return null and add that bugid to this test.

test/jdk/javax/swing/JFileChooser/AquaDefaultButtonTest.java line 48:

> 46:                 if (defaultApproveButton == null) {
> 47:                     throw new RuntimeException("getDefaultButton() method returns null for Aqua L&F!");
> 48:                 }

If you choose shorter names for variables, the line would fit into 80-column limit. Now the two lines are nearly 100 characters long, though not a big issue.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12008


From mcimadamore at openjdk.org  Mon Jan 16 11:56:24 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Jan 2023 11:56:24 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v10]
In-Reply-To: <bDUtLc3rL8E_h_r1dKHG3L5FMm90Hn-ujFxiVREnaG8=.4b15343c-2501-4c48-9f9c-901a4407662b@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bDUtLc3rL8E_h_r1dKHG3L5FMm90Hn-ujFxiVREnaG8=.4b15343c-2501-4c48-9f9c-901a4407662b@github.com>
Message-ID: <Rj0irdJkEal-iRo_X8kMZ7M9s4MC8JcPFDkEbw0s8Q8=.19719a5f-9964-4a3e-88b9-e755bc4eed93@github.com>

On Fri, 13 Jan 2023 22:48:59 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix bug where field initializer warnings could be incorrectly suppressed.
>  - Consolidate all the unit tests that generate warnings into one.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1096:

> 1094: 
> 1095:     // Perform the given action within a new scope
> 1096:     private <T> void visitScoped(boolean promote, Runnable action) {

type-variable unused here?

-------------

PR: https://git.openjdk.org/jdk/pull/11874


From aivanov at openjdk.org  Mon Jan 16 12:21:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 16 Jan 2023 12:21:10 GMT
Subject: RFR: 8300084: AquaFileChooserUI.getDefaultButton returns null
In-Reply-To: <PguMVh3YROT5D4-NWy9mQ4B-UebzCXYktLbIYdwWaSY=.ca29ef8f-9188-4cd7-862d-f4aab41d7b3a@github.com>
References: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
 <PguMVh3YROT5D4-NWy9mQ4B-UebzCXYktLbIYdwWaSY=.ca29ef8f-9188-4cd7-862d-f4aab41d7b3a@github.com>
Message-ID: <20HtHlgPIRfWYXl6qxX8fTar6oR2qdX4zREQvCIjeWo=.a3c9e4f3-ccf7-4579-9db4-0e984739116b@github.com>

On Mon, 16 Jan 2023 11:33:39 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> In Aqua look and feel, `getDefaultButton()` of `JFileChooser` returns null. The fix overrides the method from `FileChooserUI` to return the `ApproveButton` of `FileChooser` which is similar to other L&F. 
>> The test is run for multiple iterations in CI machine.
>
> test/jdk/javax/swing/JFileChooser/AquaDefaultButtonTest.java line 48:
> 
>> 46:                 if (defaultApproveButton == null) {
>> 47:                     throw new RuntimeException("getDefaultButton() method returns null for Aqua L&F!");
>> 48:                 }
> 
> If you choose shorter names for variables, the line would fit into 80-column limit. Now the two lines are nearly 100 characters long, though not a big issue.

Could you please the copyright year in `AquaFileChooserUI.java`?

-------------

PR: https://git.openjdk.org/jdk/pull/12008


From mvs at openjdk.org  Mon Jan 16 12:22:20 2023
From: mvs at openjdk.org (Manukumar V S)
Date: Mon, 16 Jan 2023 12:22:20 GMT
Subject: Integrated: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
Message-ID: <7C-sWxWVqoNL-6_eNyuVXGik9Xh8hv_-W_h1cyw-Xig=.58040e8b-dc93-462c-8253-908b7b711792@github.com>

On Tue, 11 Oct 2022 14:17:42 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
> 
> Fix:
> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
> Also updated the screen capture code, made frame undecorated, added some prints for better debugging.

This pull request has now been integrated.

Changeset: a2f67660
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a2f67660f088559ce49f73da7401801fb826028b
Stats:     60 lines in 1 file changed: 36 ins; 3 del; 21 mod

8288415: java/awt/PopupMenu/PopupMenuLocation.java is unstable in MacOS machines

Reviewed-by: dnguyen, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/10655


From mcimadamore at openjdk.org  Mon Jan 16 12:54:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Jan 2023 12:54:22 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <YeWkbLGMsOSWBdyO1UAWlq60X7TdWdH8UU2JU80dNGg=.eecfe4c1-cc7f-419f-a9d4-35861172ae68@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
 <C1dC7U69q67lgSFzmm1ntOzHAm_BcqisYnlAhekzAeo=.60148dca-01d1-4cee-8687-d3bba5aabc24@github.com>
 <YeWkbLGMsOSWBdyO1UAWlq60X7TdWdH8UU2JU80dNGg=.eecfe4c1-cc7f-419f-a9d4-35861172ae68@github.com>
Message-ID: <tWT-QFU_CwEgdWme_qL8JF20FdgFaQpJWpP958IOLWM=.a4cf149e-b791-4403-abe5-332e166b07ce@github.com>

On Fri, 13 Jan 2023 21:28:51 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1088:
>> 
>>> 1086:     private <T extends JCTree> void visitLooped(T tree, Consumer<T> visitor) {
>>> 1087:         visitScoped(tree, false, t -> {
>>> 1088:             while (true) {
>> 
>> I have also been thinking if the loop analysis could go wild and execute a large, unbound number of times. But it seems from Archie's experiments that this probably won't occur in "normal" code and worst case scenario if that were to occur we can always limit the number of times we will process loops to a set number of times
>
> The number of times around any single loop is bounded by the number of new references that can possibly be created during the analysis of that loop.
> 
> That number is at most 2 * (1 + 1 + 1 + 1 + N) where N is the number of parameters and/or variables declared in that scope (the 2 is for direct or indirect, and the 1's are for each of the singleton reference types `ThisRef`, `OuterRef`, `ExprRef`, and `ReturnRef`).
> 
> If you have nested scopes A, B, C each with Na, Nb, and Nc variables declared therein (respectively), then the bound would be something like 2 * (1 + 1 + 1 + 1 + Na + (Na * Nb) + (Na * Nb * Nc)) worst case (waving hands here).

I have played a bit with the patch, trying to disable certain features. The main reason to deal with loops and recursive calls the way the patch does is to eliminate false positives. If we see a loop, and we can't perform the analysis multiple times (as the PR does), then we'd have to conclude that the loop can be potentially escaping (as we might have missed an local var update). Same goes for recursive calls (e.g. a recursive call would be treated as escaping). Same goes for analyzing invoked methods that fall in the same compilation unit. If we don't do that, more methods might look as "escaping".

So, here's what I found:

* compiling the JDK with the current patch produces 2376 warnings
* disabling support for recursive calls produces 2427 warnings
* treating all method calls inside a loop to be escaping produces 2464 warnings
* disabling scanning of methods in same compilation unit produces  4317 warnings

(Note: the patches I used to do this analysis are a bit blunt, and perhaps can be made a bit less conservative, which might result in less false positives added - I just went for the simplest possible approach, just to test the contribute of each analysis).

This seems to suggest that even a blunt approach to deal with recursion and loop does not result in a significant increase of false positives (~2% more). That said, disabling scanning of methods in the same compilation unit results in a big impact in terms of false positive (~100% increase).

So, I'm pretty confident that, should performance problems arise, we could probably dial back the analysis not to do loops (or to do them in a bounded way, as Vicente suggest, which is much better of what I tried here) - and that will probably give us the same results we have today (or a very very minor increase of false positives). But scanning of dependent methods in same compilation unit seems to be more or less a must-have.

-------------

PR: https://git.openjdk.org/jdk/pull/11874


From tr at openjdk.org  Mon Jan 16 12:56:10 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 16 Jan 2023 12:56:10 GMT
Subject: RFR: 8300084: AquaFileChooserUI.getDefaultButton returns null
In-Reply-To: <PguMVh3YROT5D4-NWy9mQ4B-UebzCXYktLbIYdwWaSY=.ca29ef8f-9188-4cd7-862d-f4aab41d7b3a@github.com>
References: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
 <PguMVh3YROT5D4-NWy9mQ4B-UebzCXYktLbIYdwWaSY=.ca29ef8f-9188-4cd7-862d-f4aab41d7b3a@github.com>
Message-ID: <Rcy7LihorKC9DZyyR_ev7WZEMvkQql1V5uEYuG-Z6bM=.055c745f-891d-4d63-b288-046009dfe20e@github.com>

On Mon, 16 Jan 2023 11:40:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> 



> Looks good to me.
> 
> I doubt a separate test for this issue is worth it. This case is entirely covered by the test in #11901 for [JDK-8299522](https://bugs.openjdk.org/browse/JDK-8299522), which also ensures the button text isn't empty.
> 
> Adding 8300084 to the `@bug` tag in that test is enough. It was my [original suggestion](https://github.com/openjdk/jdk/pull/11901#discussion_r1068659255):
> 
> > Now you can fix this bug so that Aqua L&F doesn't return null and add that bugid to this test.

Yeah, but since https://github.com/openjdk/jdk/pull/11901 handles only Approve button size except for Aqua L&F and this fix is only for Aqua L&F I thought it would be better to not to maintain any dependency between the test/bug (Though this bug was initiated as part of https://github.com/openjdk/jdk/pull/11901 fix). I hope maintaining simple test case for two bug would be fine.

-------------

PR: https://git.openjdk.org/jdk/pull/12008


From tr at openjdk.org  Mon Jan 16 13:04:27 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 16 Jan 2023 13:04:27 GMT
Subject: RFR: 8300084: AquaFileChooserUI.getDefaultButton returns null [v2]
In-Reply-To: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
References: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
Message-ID: <a8dio5ghZVk6rWiRqaZ-POJRFbYNNYdnF6xVnhIAJQg=.b62a87df-9336-4071-8d04-69190fe8a4ab@github.com>

> In Aqua look and feel, `getDefaultButton()` of `JFileChooser` returns null. The fix overrides the method from `FileChooserUI` to return the `ApproveButton` of `FileChooser` which is similar to other L&F. 
> The test is run for multiple iterations in CI machine.

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/12008/files
  - new: https://git.openjdk.org/jdk/pull/12008/files/59a79632..81d2cda2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12008&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12008&range=00-01

  Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12008.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12008/head:pull/12008

PR: https://git.openjdk.org/jdk/pull/12008


From tr at openjdk.org  Mon Jan 16 13:04:28 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 16 Jan 2023 13:04:28 GMT
Subject: RFR: 8300084: AquaFileChooserUI.getDefaultButton returns null [v2]
In-Reply-To: <20HtHlgPIRfWYXl6qxX8fTar6oR2qdX4zREQvCIjeWo=.a3c9e4f3-ccf7-4579-9db4-0e984739116b@github.com>
References: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
 <PguMVh3YROT5D4-NWy9mQ4B-UebzCXYktLbIYdwWaSY=.ca29ef8f-9188-4cd7-862d-f4aab41d7b3a@github.com>
 <20HtHlgPIRfWYXl6qxX8fTar6oR2qdX4zREQvCIjeWo=.a3c9e4f3-ccf7-4579-9db4-0e984739116b@github.com>
Message-ID: <jbd_RkWmfpHjwuhncP3yppTUCg0sAc8NsXlD2rfF34E=.8f89770d-a473-4a42-bb26-6341e60d3f1b@github.com>

On Mon, 16 Jan 2023 12:18:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/AquaDefaultButtonTest.java line 48:
>> 
>>> 46:                 if (defaultApproveButton == null) {
>>> 47:                     throw new RuntimeException("getDefaultButton() method returns null for Aqua L&F!");
>>> 48:                 }
>> 
>> If you choose shorter names for variables, the line would fit into 80-column limit. Now the two lines are nearly 100 characters long, though not a big issue.
>
> Could you please the copyright year in `AquaFileChooserUI.java`?

Updated.

-------------

PR: https://git.openjdk.org/jdk/pull/12008


From aivanov at openjdk.org  Mon Jan 16 13:38:12 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 16 Jan 2023 13:38:12 GMT
Subject: RFR: 8300084: AquaFileChooserUI.getDefaultButton returns null [v2]
In-Reply-To: <a8dio5ghZVk6rWiRqaZ-POJRFbYNNYdnF6xVnhIAJQg=.b62a87df-9336-4071-8d04-69190fe8a4ab@github.com>
References: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
 <a8dio5ghZVk6rWiRqaZ-POJRFbYNNYdnF6xVnhIAJQg=.b62a87df-9336-4071-8d04-69190fe8a4ab@github.com>
Message-ID: <lxmjzrFj0TBqY93_TyuMiTbInE3ck3KTiDwEblTBUtg=.8f8bf84a-5eab-40cc-a9df-b0b49914cd8d@github.com>

On Mon, 16 Jan 2023 13:04:27 GMT, Tejesh R <tr at openjdk.org> wrote:

>> In Aqua look and feel, `getDefaultButton()` of `JFileChooser` returns null. The fix overrides the method from `FileChooserUI` to return the `ApproveButton` of `FileChooser` which is similar to other L&F. 
>> The test is run for multiple iterations in CI machine.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

> > This case is entirely covered by the test in #11901 for [JDK-8299522](https://bugs.openjdk.org/browse/JDK-8299522), which also ensures the button text isn't empty.
> > Adding 8300084 to the `@bug` tag in that test is enough. It was my [original suggestion](https://github.com/openjdk/jdk/pull/11901#discussion_r1068659255):
> > > Now you can fix this bug so that Aqua L&F doesn't return null and add that bugid to this test.
> 
> Yeah, but since #11901 handles only Approve button size except for Aqua L&F and this fix is only for Aqua L&F I thought it would be better to not to maintain any dependency between the test/bug (Though this bug was initiated as part of #11901 fix). I hope maintaining simple test case for two bug would be fine.

It's exactly the point: **include Aqua L&F in #11901**. The Aqua L&F is excluded only because `getDefaultButton` returns null, isn't it? This fix makes it return non-null, therefore Aqua L&F can be included in testing.

This fix should be integrated before [JDK-8299522](https://bugs.openjdk.org/browse/JDK-8299522). I will not approve #11901 until Aqua L&F is part of the `CustomApproveButtonTest.java` test.

-------------

PR: https://git.openjdk.org/jdk/pull/12008


From tr at openjdk.org  Mon Jan 16 13:49:23 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 16 Jan 2023 13:49:23 GMT
Subject: RFR: 8300084: AquaFileChooserUI.getDefaultButton returns null [v3]
In-Reply-To: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
References: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
Message-ID: <QgyjxR3GLvvUYUu6ucUQXJ-Whzd4s61lN97t7MptihE=.229a6158-2f0b-44df-a0af-6a4c2208845b@github.com>

> In Aqua look and feel, `getDefaultButton()` of `JFileChooser` returns null. The fix overrides the method from `FileChooserUI` to return the `ApproveButton` of `FileChooser` which is similar to other L&F. 
> The test is run for multiple iterations in CI machine.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Removed the test - Updating #11901 test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12008/files
  - new: https://git.openjdk.org/jdk/pull/12008/files/81d2cda2..603fd66a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12008&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12008&range=01-02

  Stats: 54 lines in 1 file changed: 0 ins; 54 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12008.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12008/head:pull/12008

PR: https://git.openjdk.org/jdk/pull/12008


From aivanov at openjdk.org  Mon Jan 16 13:49:25 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 16 Jan 2023 13:49:25 GMT
Subject: RFR: 8300084: AquaFileChooserUI.getDefaultButton returns null [v2]
In-Reply-To: <a8dio5ghZVk6rWiRqaZ-POJRFbYNNYdnF6xVnhIAJQg=.b62a87df-9336-4071-8d04-69190fe8a4ab@github.com>
References: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
 <a8dio5ghZVk6rWiRqaZ-POJRFbYNNYdnF6xVnhIAJQg=.b62a87df-9336-4071-8d04-69190fe8a4ab@github.com>
Message-ID: <mkaZB_j4v0kOaDd3oODpycqURMpJrGGmIpoi5fBvBo8=.285cae0b-48b9-48b3-a64e-05659cf6db57@github.com>

On Mon, 16 Jan 2023 13:04:27 GMT, Tejesh R <tr at openjdk.org> wrote:

>> In Aqua look and feel, `getDefaultButton()` of `JFileChooser` returns null. The fix overrides the method from `FileChooserUI` to return the `ApproveButton` of `FileChooser` which is similar to other L&F. 
>> The test is run for multiple iterations in CI machine.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JFileChooser/AquaDefaultButtonTest.java line 46:

> 44:                 JFileChooser fc = new JFileChooser();
> 45:                 JButton defApproveBtn = fc.getUI().getDefaultButton(fc);
> 46:                 if (defApproveBtn == null) {

Suggestion:

                JButton approve = fc.getUI().getDefaultButton(fc);
                if (approve == null) {

On the scope of two lines, its type ? `JButton` ? as well as method name makes it obvious it's a _button_.

`approveButton` would also be good.

Yet I am for removing this test completely because it's functionality is entirely covered by the `CustomApproveButtonTest.java` in #11901.

-------------

PR: https://git.openjdk.org/jdk/pull/12008


From tr at openjdk.org  Mon Jan 16 13:49:26 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 16 Jan 2023 13:49:26 GMT
Subject: RFR: 8300084: AquaFileChooserUI.getDefaultButton returns null [v2]
In-Reply-To: <lxmjzrFj0TBqY93_TyuMiTbInE3ck3KTiDwEblTBUtg=.8f8bf84a-5eab-40cc-a9df-b0b49914cd8d@github.com>
References: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
 <a8dio5ghZVk6rWiRqaZ-POJRFbYNNYdnF6xVnhIAJQg=.b62a87df-9336-4071-8d04-69190fe8a4ab@github.com>
 <lxmjzrFj0TBqY93_TyuMiTbInE3ck3KTiDwEblTBUtg=.8f8bf84a-5eab-40cc-a9df-b0b49914cd8d@github.com>
Message-ID: <mG3JJrQjoeSh8WI02sojbyB8saC1ukAFlu0aqyRE8rA=.4b5973e2-023e-4f51-b444-8e27e2457b28@github.com>

On Mon, 16 Jan 2023 13:33:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > This case is entirely covered by the test in #11901 for [JDK-8299522](https://bugs.openjdk.org/browse/JDK-8299522), which also ensures the button text isn't empty.
> > > Adding 8300084 to the `@bug` tag in that test is enough. It was my [original suggestion](https://github.com/openjdk/jdk/pull/11901#discussion_r1068659255):
> > > > Now you can fix this bug so that Aqua L&F doesn't return null and add that bugid to this test.
> > 
> > 
> > Yeah, but since #11901 handles only Approve button size except for Aqua L&F and this fix is only for Aqua L&F I thought it would be better to not to maintain any dependency between the test/bug (Though this bug was initiated as part of #11901 fix). I hope maintaining simple test case for two bug would be fine.
> 
> It's exactly the point: **include Aqua L&F in #11901**. The Aqua L&F is excluded only because `getDefaultButton` returns null, isn't it? This fix makes it return non-null, therefore Aqua L&F can be included in testing.
> 
> This fix should be integrated before [JDK-8299522](https://bugs.openjdk.org/browse/JDK-8299522). I will not approve #11901 until Aqua L&F is part of the `CustomApproveButtonTest.java` test.
The Aqua L&F is excluded not only because `getDefaultButton` returns null, but it is also excluded because the fix doesn't apply to Aqua L&F. Still if u insist to use the same test then can do that, as u said first this fix will go in and then #11901.

> test/jdk/javax/swing/JFileChooser/AquaDefaultButtonTest.java line 46:
> 
>> 44:                 JFileChooser fc = new JFileChooser();
>> 45:                 JButton defApproveBtn = fc.getUI().getDefaultButton(fc);
>> 46:                 if (defApproveBtn == null) {
> 
> Suggestion:
> 
>                 JButton approve = fc.getUI().getDefaultButton(fc);
>                 if (approve == null) {
> 
> On the scope of two lines, its type ? `JButton` ? as well as method name makes it obvious it's a _button_.
> 
> `approveButton` would also be good.
> 
> Yet I am for removing this test completely because it's functionality is entirely covered by the `CustomApproveButtonTest.java` in #11901.

Ok, then I'll remove this test and update https://github.com/openjdk/jdk/pull/11901.

-------------

PR: https://git.openjdk.org/jdk/pull/12008


From aivanov at openjdk.org  Mon Jan 16 13:49:27 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 16 Jan 2023 13:49:27 GMT
Subject: RFR: 8300084: AquaFileChooserUI.getDefaultButton returns null [v2]
In-Reply-To: <mG3JJrQjoeSh8WI02sojbyB8saC1ukAFlu0aqyRE8rA=.4b5973e2-023e-4f51-b444-8e27e2457b28@github.com>
References: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
 <a8dio5ghZVk6rWiRqaZ-POJRFbYNNYdnF6xVnhIAJQg=.b62a87df-9336-4071-8d04-69190fe8a4ab@github.com>
 <lxmjzrFj0TBqY93_TyuMiTbInE3ck3KTiDwEblTBUtg=.8f8bf84a-5eab-40cc-a9df-b0b49914cd8d@github.com>
 <mG3JJrQjoeSh8WI02sojbyB8saC1ukAFlu0aqyRE8rA=.4b5973e2-023e-4f51-b444-8e27e2457b28@github.com>
Message-ID: <FDYIUJFijfmVpe3iUkYmJelWHGI3VAm3_N-l09oLR50=.18e8fd9a-5943-4721-a1c2-8130f04e65b7@github.com>

On Mon, 16 Jan 2023 13:38:32 GMT, Tejesh R <tr at openjdk.org> wrote:

> > It's exactly the point: **include Aqua L&F in #11901**. The Aqua L&F is excluded only because `getDefaultButton` returns null, isn't it? This fix makes it return non-null, therefore Aqua L&F can be included in testing.
> >
> > This fix should be integrated before [JDK-8299522](https://bugs.openjdk.org/browse/JDK-8299522). I will not approve #11901 until Aqua L&F is part of the `CustomApproveButtonTest.java` test.
>
> The Aqua L&F is excluded not only because `getDefaultButton` returns null, but it is also excluded because the fix doesn't apply to Aqua L&F. Still if u insist to use the same test then can do that, as u said first this fix will go in and then #11901.

I do insist.

The fix does not apply to Aqua L&F only because this situation has already be taken care of in Aqua L&F. Now all L&Fs are expected to return non-null text for the Approve button, I see no reason why Aqua L&F is skipped in testing: it is still expected that the Approve button in Aqua L&F is not null.

-------------

PR: https://git.openjdk.org/jdk/pull/12008


From tr at openjdk.org  Mon Jan 16 14:20:30 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 16 Jan 2023 14:20:30 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v9]
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <pNBPBxe1Zg8PXkf8UOZJnFjYAPUV2-VTKCKOciDYzNw=.a075af8a-21da-44f7-b7c8-096b524f8ed3@github.com>

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Added Aqua L&F -  linked to #12008 fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11901/files
  - new: https://git.openjdk.org/jdk/pull/11901/files/20993b85..6ed23ab1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11901&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11901&range=07-08

  Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11901.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11901/head:pull/11901

PR: https://git.openjdk.org/jdk/pull/11901


From aivanov at openjdk.org  Mon Jan 16 14:26:14 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 16 Jan 2023 14:26:14 GMT
Subject: RFR: 8300084: AquaFileChooserUI.getDefaultButton returns null [v3]
In-Reply-To: <QgyjxR3GLvvUYUu6ucUQXJ-Whzd4s61lN97t7MptihE=.229a6158-2f0b-44df-a0af-6a4c2208845b@github.com>
References: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
 <QgyjxR3GLvvUYUu6ucUQXJ-Whzd4s61lN97t7MptihE=.229a6158-2f0b-44df-a0af-6a4c2208845b@github.com>
Message-ID: <F7_EUt2CnvWZK4tU0nZWi51QEdx_icgRsVkVDr-mbZk=.51feb1c3-57ec-4346-9d78-853ba2a3511e@github.com>

On Mon, 16 Jan 2023 13:49:23 GMT, Tejesh R <tr at openjdk.org> wrote:

>> In Aqua look and feel, `getDefaultButton()` of `JFileChooser` returns null. The fix overrides the method from `FileChooserUI` to return the `ApproveButton` of `FileChooser` which is similar to other L&F. 
>> The test is run for multiple iterations in CI machine.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the test - Updating #11901 test

Looks good to me.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12008


From aivanov at openjdk.org  Mon Jan 16 14:30:50 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 16 Jan 2023 14:30:50 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java failed
 with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)"
 because "retVal" is null'
Message-ID: <lKLFw4FVKMO_0woqf516ebwHnavZjjO2tvCAfD1Xm6w=.202160e7-e82f-49c4-8b78-58dbe3476b2d@github.com>

This is somewhat a continuation of #11104 where the issue was discussed and where I found [the root cause](https://github.com/openjdk/jdk/pull/11104#issuecomment-1382435784).

**Root Cause**

The icon extraction code compares the returned handle to zero: 
https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1157-L1158

On 64-bit systems, a valid handle can be negative. For example:


getIcon : Desktop 16(16)
GetIconLocation(uFlags=0x22, flags=0x4, index=-110) SUCCESS - szBuf=C:\Windows\system32\imageres.dll
Extract - hres: 0, hIcon=0000000019B200F9, hIconSmall=FFFFFFFFF98C00EB, size=16(0x100020)
SUCCEEDED
!!! hIcon(0xfffffffff98c00eb) <= 0 : Desktop 16(16)


Here in `size=16(0x100020)`, 16 is the requested icon size, the value in parenthesis is value of `iconSize` passed to the [`Extract`](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-iextracticonw-extract) method that contains the size for small icon in high word and that for large icon in low word. `Desktop 16(16)` means the icon of size 16?16 is requested, and we're extracting 16?16 icon.

The icon was extracted _successfully_ but its handle was interpreted as an error.

The same problem exists in the fallback code:
https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1161

Then when the fallback code is executed, another problem occurs:


GetIconLocation(uFlags=0x40, flags=0x1a3, index=-675088752) SUCCESS - szBuf=
Extract - hres: 80004005, hIcon=0000000000000000, hIconSmall=000001A3D7C2F83A, size=16(100020)
NOT SUCCEEDED
hIcon = 0x1a3d7c2f83a : Desktop 16(16)


The error code 0x80004005 is `E_FAIL`. Yet the return value is not verified in the code:
https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp#L997-L1003

Since the icon handle is *seemingly* valid, it continues to extracting the icon bits:


native getIconBits - fn_GetIconInfo returned false
Error code: 0x57a - Invalid cursor handle.
makeIcon: iconBits = null


It's not a surprise. After all, the `Extract` method returned an error, which means neither icon handle is valid.

In the end, the `MultiResolutionIcon` contains `null`:

????16 -> null
????32 -> [BufferedImage at 59e735d](mailto:BufferedImage at 59e735d)
????24 -> [BufferedImage at 60b2faf0](mailto:BufferedImage at 60b2faf0)


This problem has existed for since [JDK-8182043](https://bugs.openjdk.org/browse/JDK-8182043), yet it went unnoticed because `getResolutionVariant` just returned a null. However, after [JDK-8282526](https://bugs.openjdk.org/browse/JDK-8282526) was integrated, the result is used, which leads to `NullPointerException`.


**The Fix**

Handle the errors as `hIcon == E_PENDING || hIcon == 0` and `hIcon == 0`. In the fallback code where a default icon is requested, [`E_PENDING` cannot be returned](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-iextracticonw-geticonlocation#remarks), it's valid only if `GIL_ASYNC` flag is used.

Add `assert` statements to `MultiResolutionIconImage` for null-checks which will help us to catch a similar situation if it occurs.

**Testing**

The two errors combined lead to random failures. No particular host reproduced the problem more often.

While I was testing with the additional traces, sometimes 5 of 10 tests failed, other times only 1 of 10. There were a couple of test runs where no failures occurred.

With the fix applied, no failures occurred.

-------------

Commit messages:
 - 8293862: javax/swing/JFileChooser/8046391/bug8046391.java failed with 'Cannot invoke "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is null'

Changes: https://git.openjdk.org/jdk/pull/12010/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12010&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293862
  Stats: 29 lines in 4 files changed: 17 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12010.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12010/head:pull/12010

PR: https://git.openjdk.org/jdk/pull/12010


From aivanov at openjdk.org  Mon Jan 16 14:32:13 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 16 Jan 2023 14:32:13 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v9]
In-Reply-To: <pNBPBxe1Zg8PXkf8UOZJnFjYAPUV2-VTKCKOciDYzNw=.a075af8a-21da-44f7-b7c8-096b524f8ed3@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <pNBPBxe1Zg8PXkf8UOZJnFjYAPUV2-VTKCKOciDYzNw=.a075af8a-21da-44f7-b7c8-096b524f8ed3@github.com>
Message-ID: <oaa7o-IIPTqE3GVRpXhI1xkHHTNsOHYfC-CUzIC0Oqs=.0bc37dc4-a7db-4dba-ab94-6840cb67645c@github.com>

On Mon, 16 Jan 2023 14:20:30 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added Aqua L&F -  linked to #12008 fix

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 38:

> 36:  * @key headful
> 37:  * @summary JFileChooser Test to check for FileChooser's Approve Button Text
> 38:  *          when CUSTOM_DIALOG type is set and check getDefaultButton() (AquaL&F)

Suggestion:

 * @summary Verifies JFileChooser's Approve button text is non-null
 *          when CUSTOM_DIALOG type is set

I'd remove reference to Aqua L&F, it's an unimportant detail in my opinion.

-------------

PR: https://git.openjdk.org/jdk/pull/11901


From tr at openjdk.org  Mon Jan 16 14:57:33 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 16 Jan 2023 14:57:33 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v10]
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <fUE1LDTOwcDd-G9sYUlGP-gyQ_hCC5aWzXooTWQvjmo=.7aa155f8-b364-4f37-8c1e-39c052504ede@github.com>

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated JTREG summary

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11901/files
  - new: https://git.openjdk.org/jdk/pull/11901/files/6ed23ab1..4ec6b60e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11901&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11901&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11901.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11901/head:pull/11901

PR: https://git.openjdk.org/jdk/pull/11901


From mbaesken at openjdk.org  Mon Jan 16 15:26:57 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Jan 2023 15:26:57 GMT
Subject: RFR: JDK-8300205: Swing test bug8078268 make latch timeout
 configurable
Message-ID: <yIdk4ayM8O8m36fa2MokAoaqBmY6GI3TosTVXZjWzyw=.b9236a8c-9045-4207-b64a-8a382664c32f@github.com>

The test javax/swing/text/html/parser/Parser/8078268/bug8078268.java has a latch timeout that is currently fix but should better be configurable to better deal with slow test infrastructures.

-------------

Commit messages:
 - JDK-8300205

Changes: https://git.openjdk.org/jdk/pull/12011/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12011&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300205
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12011.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12011/head:pull/12011

PR: https://git.openjdk.org/jdk/pull/12011


From duke at openjdk.org  Mon Jan 16 15:49:28 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 16 Jan 2023 15:49:28 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v10]
In-Reply-To: <Rj0irdJkEal-iRo_X8kMZ7M9s4MC8JcPFDkEbw0s8Q8=.19719a5f-9964-4a3e-88b9-e755bc4eed93@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bDUtLc3rL8E_h_r1dKHG3L5FMm90Hn-ujFxiVREnaG8=.4b15343c-2501-4c48-9f9c-901a4407662b@github.com>
 <Rj0irdJkEal-iRo_X8kMZ7M9s4MC8JcPFDkEbw0s8Q8=.19719a5f-9964-4a3e-88b9-e755bc4eed93@github.com>
Message-ID: <eig0bd85iBDM3fvvNZVAHmsoiHDj0VI3oSJRlNpn_64=.c78bc7b1-a6b8-4504-96f4-4149fb7836b9@github.com>

On Mon, 16 Jan 2023 11:53:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix bug where field initializer warnings could be incorrectly suppressed.
>>  - Consolidate all the unit tests that generate warnings into one.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1096:
> 
>> 1094: 
>> 1095:     // Perform the given action within a new scope
>> 1096:     private <T> void visitScoped(boolean promote, Runnable action) {
> 
> type-variable unused here?

Thanks - will fix.

-------------

PR: https://git.openjdk.org/jdk/pull/11874


From aivanov at openjdk.org  Mon Jan 16 15:51:14 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 16 Jan 2023 15:51:14 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v10]
In-Reply-To: <fUE1LDTOwcDd-G9sYUlGP-gyQ_hCC5aWzXooTWQvjmo=.7aa155f8-b364-4f37-8c1e-39c052504ede@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <fUE1LDTOwcDd-G9sYUlGP-gyQ_hCC5aWzXooTWQvjmo=.7aa155f8-b364-4f37-8c1e-39c052504ede@github.com>
Message-ID: <qn1CYycOERcKBT14xf3IZS9kDylwmf4qGIjRWRZ-gTo=.97bcab93-285d-48f6-916f-d9fd7cef4d12@github.com>

On Mon, 16 Jan 2023 14:57:33 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated JTREG summary

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11901


From duke at openjdk.org  Mon Jan 16 16:32:25 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 16 Jan 2023 16:32:25 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <tWT-QFU_CwEgdWme_qL8JF20FdgFaQpJWpP958IOLWM=.a4cf149e-b791-4403-abe5-332e166b07ce@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
 <C1dC7U69q67lgSFzmm1ntOzHAm_BcqisYnlAhekzAeo=.60148dca-01d1-4cee-8687-d3bba5aabc24@github.com>
 <YeWkbLGMsOSWBdyO1UAWlq60X7TdWdH8UU2JU80dNGg=.eecfe4c1-cc7f-419f-a9d4-35861172ae68@github.com>
 <tWT-QFU_CwEgdWme_qL8JF20FdgFaQpJWpP958IOLWM=.a4cf149e-b791-4403-abe5-332e166b07ce@github.com>
Message-ID: <-vggQR3X6BuroIsmEmI6yohrVGF3MyE-ap7tokjc-7M=.077053ee-fcf9-43db-be53-a9c89ab38a15@github.com>

On Mon, 16 Jan 2023 12:51:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The number of times around any single loop is bounded by the number of new references that can possibly be created during the analysis of that loop.
>> 
>> That number is at most 2 * (1 + 1 + 1 + 1 + N) where N is the number of parameters and/or variables declared in that scope (the 2 is for direct or indirect, and the 1's are for each of the singleton reference types `ThisRef`, `OuterRef`, `ExprRef`, and `ReturnRef`).
>> 
>> If you have nested scopes A, B, C each with Na, Nb, and Nc variables declared therein (respectively), then the bound would be something like 2 * (1 + 1 + 1 + 1 + Na + (Na * Nb) + (Na * Nb * Nc)) worst case (waving hands here).
>
> I have played a bit with the patch, trying to disable certain features. The main reason to deal with loops and recursive calls the way the patch does is to eliminate false positives. If we see a loop, and we can't perform the analysis multiple times (as the PR does), then we'd have to conclude that the loop can be potentially escaping (as we might have missed an local var update). Same goes for recursive calls (e.g. a recursive call would be treated as escaping). Same goes for analyzing invoked methods that fall in the same compilation unit. If we don't do that, more methods might look as "escaping".
> 
> So, here's what I found:
> 
> * compiling the JDK with the current patch produces 2376 warnings
> * disabling support for recursive calls produces 2427 warnings
> * treating all method calls inside a loop to be escaping produces 2464 warnings
> * disabling scanning of methods in same compilation unit produces  4317 warnings
> 
> (Note: the patches I used to do this analysis are a bit blunt, and perhaps can be made a bit less conservative, which might result in less false positives added - I just went for the simplest possible approach, just to test the contribute of each analysis).
> 
> This seems to suggest that even a blunt approach to deal with recursion and loop does not result in a significant increase of false positives (~2% more). That said, disabling scanning of methods in the same compilation unit results in a big impact in terms of false positive (~100% increase).
> 
> So, I'm pretty confident that, should performance problems arise, we could probably dial back the analysis not to do loops (or to do them in a bounded way, as Vicente suggest, which is much better of what I tried here) - and that will probably give us the same results we have today (or a very very minor increase of false positives). But scanning of dependent methods in same compilation unit seems to be more or less a must-have.

Thanks for doing that analysis - very interesting.

It looks like you might be counting the "here via invocation" lines as separate warnings. These are really part of the previous `possible 'this' escape` line, e.g.:

.../java/awt/Frame.java:429: Note: possible 'this' escape before subclass is fully initialized
        init(title, null);
            ^
.../java/awt/Frame.java:460: Note: previous possible 'this' escape happens here via invocation
        SunToolkit.checkAndSetPolicy(this);
                                     ^


Semi-related... I was also curious what would happen if we changed the semantics of the warning from "subclass must be in a separate compilation unit" to "subclass must be in a separate package".

I'm not proposing we change this definition, and obviously there are trade-offs in where you draw this boundary, but was curious anywan (at one point I thought it might be worth having an option for this, e.g., with variants like `-Xlint:this-escape` vs. `-Xlint:this-escape:package`, or even `-Xlint:this-escape:module`, etc.).

In any case, here are the results:

* Warnings for subclass in separate compilation unit: 2093
* Warnings for subclass in separate package: 1334

So a 36% reduction - not too surprising since the JDK includes a bunch of non-public implementation classes.

FWIW this is the patch I used:

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
index e81df22b017..f309a4742aa 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
@@ -216,24 +217,24 @@ class ThisEscapeAnalyzer extends TreeScanner {
 
             private Lint lint = ThisEscapeAnalyzer.this.lint;
             private JCClassDecl currentClass;
-            private boolean privateOuter;
+            private boolean nonPublicOuter;
 
             @Override
             public void visitClassDef(JCClassDecl tree) {
                 JCClassDecl currentClassPrev = currentClass;
-                boolean privateOuterPrev = privateOuter;
+                boolean nonPublicOuterPrev = nonPublicOuter;
                 Lint lintPrev = lint;
                 lint = lint.augment(tree.sym);
                 try {
                     currentClass = tree;
-                    privateOuter |= tree.sym.isAnonymous();
-                    privateOuter |= (tree.mods.flags & Flags.PRIVATE) != 0;
+                    nonPublicOuter |= tree.sym.isAnonymous();
+                    nonPublicOuter |= (tree.mods.flags & Flags.PUBLIC) == 0;
 
                     // Recurse
                     super.visitClassDef(tree);
                 } finally {
                     currentClass = currentClassPrev;
-                    privateOuter = privateOuterPrev;
+                    nonPublicOuter = nonPublicOuterPrev;
                     lint = lintPrev;
                 }
             }
@@ -268,10 +269,10 @@ class ThisEscapeAnalyzer extends TreeScanner {
                     // Determine if this is a constructor we should analyze
                     boolean analyzable = currentClassIsExternallyExtendable() &&
                         TreeInfo.isConstructor(tree) &&
-                        !tree.sym.isPrivate() &&
+                        (tree.sym.isPublic() || (tree.sym.flags() & Flags.PROTECTED) != 0) &&
                         !suppressed.contains(tree.sym);
 
-                    // Determine if this method is "invokable" in an analysis (can't be overridden)
+                    // Determine if this method is "invokable" in an analysis (can't be overridden outside package)
                     boolean invokable = !currentClassIsExternallyExtendable() ||
                         TreeInfo.isConstructor(tree) ||
                         (tree.mods.flags & (Flags.STATIC | Flags.PRIVATE | Flags.FINAL)) != 0;
@@ -286,12 +287,13 @@ class ThisEscapeAnalyzer extends TreeScanner {
                 }
             }
 
-            // Determines if the current class could be extended in some external compilation unit
+            // Determines if the current class could be extended in some other package
             private boolean currentClassIsExternallyExtendable() {
                 return !currentClass.sym.isFinal() &&
+                  currentClass.sym.isPublic() &&
                   !(currentClass.sym.isSealed() && currentClass.permitting.isEmpty()) &&
                   !(currentClass.sym.owner.kind == MTH) &&
-                  !privateOuter;
+                  !nonPublicOuter;
             }
         }.scan(env.tree);

-------------

PR: https://git.openjdk.org/jdk/pull/11874


From ihse at openjdk.org  Mon Jan 16 16:50:06 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 16 Jan 2023 16:50:06 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
Message-ID: <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>

> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
> 
> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
> 
> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
> 
> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
> 
> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into properties-eol-clean-safe
 - 8298047: Remove all non-significant trailing whitespace from properties files

-------------

Changes: https://git.openjdk.org/jdk/pull/11491/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11491&range=01
  Stats: 693 lines in 264 files changed: 0 ins; 0 del; 693 mod
  Patch: https://git.openjdk.org/jdk/pull/11491.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11491/head:pull/11491

PR: https://git.openjdk.org/jdk/pull/11491


From ihse at openjdk.org  Mon Jan 16 16:52:12 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 16 Jan 2023 16:52:12 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files
In-Reply-To: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
Message-ID: <_jLR_ky5hw9zllvt1MZyi3KWmGOefoRazd7sjzoUivo=.e0bc2d7a-05ad-4417-bc34-369c67c3bf5a@github.com>

On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
> 
> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
> 
> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
> 
> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
> 
> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

I know this is boring stuff, but please can I get some more reviews on this? Sergey has reviewed the client parts. It's just removing trailing whitespaces. You should be able to just quickly scroll through this and confirm that this is indeed the case. If someone can take pity on me and just quickly check the non-client parts, I'd be very grateful.

-------------

PR: https://git.openjdk.org/jdk/pull/11491


From mcimadamore at openjdk.org  Mon Jan 16 17:16:26 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Jan 2023 17:16:26 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <-vggQR3X6BuroIsmEmI6yohrVGF3MyE-ap7tokjc-7M=.077053ee-fcf9-43db-be53-a9c89ab38a15@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
 <C1dC7U69q67lgSFzmm1ntOzHAm_BcqisYnlAhekzAeo=.60148dca-01d1-4cee-8687-d3bba5aabc24@github.com>
 <YeWkbLGMsOSWBdyO1UAWlq60X7TdWdH8UU2JU80dNGg=.eecfe4c1-cc7f-419f-a9d4-35861172ae68@github.com>
 <tWT-QFU_CwEgdWme_qL8JF20FdgFaQpJWpP958IOLWM=.a4cf149e-b791-4403-abe5-332e166b07ce@github.com>
 <-vggQR3X6BuroIsmEmI6yohrVGF3MyE-ap7tokjc-7M=.077053ee-fcf9-43db-be53-a9c89ab38a15@github.com>
Message-ID: <fyeJ5SBQY5LsQePrlC2y9aADocSpEoYpNrTHCV9SRiQ=.47c49123-5acd-4482-9ce1-93a984fb3f51@github.com>

On Mon, 16 Jan 2023 16:29:31 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> It looks like you might be counting the "here via invocation" lines as separate warnings. These are really part of the previous `possible 'this' escape` line, e.g.:

yes, I really did the simplest possible thing (e.g. just counting the number of escape-this warnings, regardless of their kinds). Perhaps some of my measurements might be skewed as a result - but I think that magnitude-wise they are still telling.
> 
> ```
> .../java/awt/Frame.java:429: Note: possible 'this' escape before subclass is fully initialized
>         init(title, null);
>             ^
> .../java/awt/Frame.java:460: Note: previous possible 'this' escape happens here via invocation
>         SunToolkit.checkAndSetPolicy(this);
>                                      ^
> ```
> 
> Semi-related... I was also curious what would happen if we changed the semantics of the warning from "subclass must be in a separate compilation unit" to "subclass must be in a separate package".

To be fair, this is what my brain was reading when you talked about "compilation unit" - but then saw that the code was doing it differently. You see, for "sealed" classes we have a notion of "maintenance domain". E.g. the classes in a `permits` clause of a `sealed` declaration must belong to the same module (if available) or same package (if no module is available). That's how you get the exhaustiveness analysis and all the goodies, by essentially making a close-world assumption on the classes that are passed to javac for a given compilation task. I think it would make a lot of sense to apply these very same boundaries to the escape-this analysis (and, in fact, when looking at warnings coming out of the JDK, I often found false positives that were caused by this).
> 
> I'm not proposing we change this definition, and obviously there are trade-offs in where you draw this boundary, but was curious anywan (at one point I thought it might be worth having an option for this, e.g., with variants like `-Xlint:this-escape` vs. `-Xlint:this-escape:package`, or even `-Xlint:this-escape:module`, etc.).

Perhaps - but, as said above, `sealed` already does this by default - so there's a (strong) precedent, I believe, should we want to bend the analysis that way.
> 
> In any case, here are the results:
> 
>     * Warnings for subclass in separate compilation unit: 2093
> 
>     * Warnings for subclass in separate package: 1334
> 
> 
> So a 36% reduction - not too surprising since the JDK includes a bunch of non-public implementation classes.

That corresponds to what I've sampled (unscientifically).

-------------

PR: https://git.openjdk.org/jdk/pull/11874


From rriggs at openjdk.org  Mon Jan 16 17:25:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 16 Jan 2023 17:25:12 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
Message-ID: <RL9o7v8nYmartQrhygV7sw42MUZ8vaS1qoqy0TzH_6s=.71f4b88f-3517-41f2-8e2f-d059eb3f4969@github.com>

On Mon, 16 Jan 2023 16:50:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
>> 
>> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
>> 
>> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
>> 
>> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
>> 
>> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into properties-eol-clean-safe
>  - 8298047: Remove all non-significant trailing whitespace from properties files

The non-client parts look fine.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11491


From serb at openjdk.org  Mon Jan 16 18:05:10 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 16 Jan 2023 18:05:10 GMT
Subject: RFR: 8300084: AquaFileChooserUI.getDefaultButton returns null [v3]
In-Reply-To: <QgyjxR3GLvvUYUu6ucUQXJ-Whzd4s61lN97t7MptihE=.229a6158-2f0b-44df-a0af-6a4c2208845b@github.com>
References: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
 <QgyjxR3GLvvUYUu6ucUQXJ-Whzd4s61lN97t7MptihE=.229a6158-2f0b-44df-a0af-6a4c2208845b@github.com>
Message-ID: <4WfcVt9IBrqL__xlVjfcPLhLyYE_sk3wfXAC8HZk6L8=.a709cc35-ebd6-453a-8cb3-8a4f2bfe5ca7@github.com>

On Mon, 16 Jan 2023 13:49:23 GMT, Tejesh R <tr at openjdk.org> wrote:

>> In Aqua look and feel, `getDefaultButton()` of `JFileChooser` returns null. The fix overrides the method from `FileChooserUI` to return the `ApproveButton` of `FileChooser` which is similar to other L&F. 
>> The test is run for multiple iterations in CI machine.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the test - Updating #11901 test

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12008


From serb at openjdk.org  Mon Jan 16 18:14:12 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 16 Jan 2023 18:14:12 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v10]
In-Reply-To: <fUE1LDTOwcDd-G9sYUlGP-gyQ_hCC5aWzXooTWQvjmo=.7aa155f8-b364-4f37-8c1e-39c052504ede@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <fUE1LDTOwcDd-G9sYUlGP-gyQ_hCC5aWzXooTWQvjmo=.7aa155f8-b364-4f37-8c1e-39c052504ede@github.com>
Message-ID: <I-DwskytFxE0FdHcLtDr7OX5wf4AbN6xh4jJtcnv48U=.e9b79329-4fa1-4f96-916c-29ba28a73d70@github.com>

On Mon, 16 Jan 2023 14:57:33 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated JTREG summary

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 71:

> 69:             frame.setVisible(true);
> 70: 
> 71:             JButton customApproveButton = fileChooser.getUI().getDefaultButton(fileChooser);

we should check the changes in getApproveButtonToolTipText and getApproveButtonMnemonic as well.

-------------

PR: https://git.openjdk.org/jdk/pull/11901


From ihse at openjdk.org  Mon Jan 16 18:57:21 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 16 Jan 2023 18:57:21 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <RL9o7v8nYmartQrhygV7sw42MUZ8vaS1qoqy0TzH_6s=.71f4b88f-3517-41f2-8e2f-d059eb3f4969@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
 <RL9o7v8nYmartQrhygV7sw42MUZ8vaS1qoqy0TzH_6s=.71f4b88f-3517-41f2-8e2f-d059eb3f4969@github.com>
Message-ID: <aifLgLpgJS_gMzyzRP6INOO4R7bE50ruKJ6R5pQS-lk=.66345dcc-48ae-43d9-b205-8d2f8f1e7ebf@github.com>

On Mon, 16 Jan 2023 17:22:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into properties-eol-clean-safe
>>  - 8298047: Remove all non-significant trailing whitespace from properties files
>
> The non-client parts look fine.

@RogerRiggs Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/11491


From ihse at openjdk.org  Mon Jan 16 18:57:22 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 16 Jan 2023 18:57:22 GMT
Subject: Integrated: 8298047: Remove all non-significant trailing whitespace
 from properties files
In-Reply-To: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
Message-ID: <fTgnorzgmXthXmq26skxN42TKuvrV5cVOtaxjIVUu84=.75d2e856-d8c4-4630-8fb8-a35112a68b05@github.com>

On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
> 
> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
> 
> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
> 
> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
> 
> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

This pull request has now been integrated.

Changeset: 4073b685
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4073b68565f9d5283be96ee6b75bab686f076bea
Stats:     693 lines in 264 files changed: 0 ins; 0 del; 693 mod

8298047: Remove all non-significant trailing whitespace from properties files

Reviewed-by: serb, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/11491


From aivanov at openjdk.org  Mon Jan 16 19:04:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 16 Jan 2023 19:04:10 GMT
Subject: RFR: JDK-8300205: Swing test bug8078268 make latch timeout
 configurable
In-Reply-To: <yIdk4ayM8O8m36fa2MokAoaqBmY6GI3TosTVXZjWzyw=.b9236a8c-9045-4207-b64a-8a382664c32f@github.com>
References: <yIdk4ayM8O8m36fa2MokAoaqBmY6GI3TosTVXZjWzyw=.b9236a8c-9045-4207-b64a-8a382664c32f@github.com>
Message-ID: <o49Vb9UEXa-v3AQWO5llpWtnRTF6ZyTAT2AHYwB8aiY=.29e7cc93-14eb-4dcf-9648-a75f788afb66@github.com>

On Mon, 16 Jan 2023 15:09:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test javax/swing/text/html/parser/Parser/8078268/bug8078268.java has a latch timeout that is currently fix but should better be configurable to better deal with slow test infrastructures.

Looks fine.

I'd appreciate if you update the copyright year too.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12011


From duke at openjdk.org  Mon Jan 16 19:31:09 2023
From: duke at openjdk.org (SWinxy)
Date: Mon, 16 Jan 2023 19:31:09 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
Message-ID: <ml5KnXSuRa1uWxhC6_U3YcK8SlkCOlVIx18M6bVpnOQ=.ff55dd4d-66ef-4731-9d85-2f6677db84d2@github.com>

On Fri, 6 Jan 2023 04:42:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems Synth has two cases of updateStyle() where its argument is not passed to the getContext() call. It seems to be an oversight as in other Synth classes, the component argument passed to updateStyle is being passed to getContext().
> 
> CI tests are ok with this change and there is no new regeression with CI tests run in NimbusL&F by default..

As they ought to. All UI classes assume that the source for the property listener is the component it is the delegate for, which is why we see some classes passing `e.getSource()` and others passing the protected field. It's not something we can test, because the issues will arise when *other* people invoke the listener, and the JDK code doesn't (seem to) directly call it. I'll plug #11892 because it would close the possibility for outsiders to poison the listener.

-------------

PR: https://git.openjdk.org/jdk/pull/11875


From serb at openjdk.org  Mon Jan 16 19:46:08 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 16 Jan 2023 19:46:08 GMT
Subject: RFR: JDK-8300205: Swing test bug8078268 make latch timeout
 configurable
In-Reply-To: <yIdk4ayM8O8m36fa2MokAoaqBmY6GI3TosTVXZjWzyw=.b9236a8c-9045-4207-b64a-8a382664c32f@github.com>
References: <yIdk4ayM8O8m36fa2MokAoaqBmY6GI3TosTVXZjWzyw=.b9236a8c-9045-4207-b64a-8a382664c32f@github.com>
Message-ID: <FHeyR-eVxTHT-CfRy8OZEZXzB4txF1HvgICUpnPSj48=.5e60a343-7db5-44a3-98bb-ee40d6251559@github.com>

On Mon, 16 Jan 2023 15:09:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test javax/swing/text/html/parser/Parser/8078268/bug8078268.java has a latch timeout that is currently fix but should better be configurable to better deal with slow test infrastructures.

I remember that match 5 uses timeout=4, so I wonder if timeout will be changed to 40 seconds will it be possible to verify old bug or not.

-------------

PR: https://git.openjdk.org/jdk/pull/12011


From duke at openjdk.org  Mon Jan 16 20:15:02 2023
From: duke at openjdk.org (SWinxy)
Date: Mon, 16 Jan 2023 20:15:02 GMT
Subject: RFR: 8267582: BasicLookAndFeel should not call getComponentPopupMenu
 twice to get a popup menu
Message-ID: <rVW2gyOA88cdon5y0Mjiv8DlIMzX9khi3u2k1Nm2m5Y=.622ae3fb-8a75-4d93-8ebe-9e1403b856e1@github.com>

Please review this small change to cache a component's popup menu in BLAF.

-------------

Commit messages:
 - 8267582: BasicLookAndFeel should not call getComponentPopupMenu twice to get a popup menu

Changes: https://git.openjdk.org/jdk/pull/12017/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12017&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8267582
  Stats: 58 lines in 1 file changed: 10 ins; 38 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12017/head:pull/12017

PR: https://git.openjdk.org/jdk/pull/12017


From aivanov at openjdk.org  Mon Jan 16 20:30:09 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 16 Jan 2023 20:30:09 GMT
Subject: RFR: JDK-8300205: Swing test bug8078268 make latch timeout
 configurable
In-Reply-To: <FHeyR-eVxTHT-CfRy8OZEZXzB4txF1HvgICUpnPSj48=.5e60a343-7db5-44a3-98bb-ee40d6251559@github.com>
References: <yIdk4ayM8O8m36fa2MokAoaqBmY6GI3TosTVXZjWzyw=.b9236a8c-9045-4207-b64a-8a382664c32f@github.com>
 <FHeyR-eVxTHT-CfRy8OZEZXzB4txF1HvgICUpnPSj48=.5e60a343-7db5-44a3-98bb-ee40d6251559@github.com>
Message-ID: <ekRFhNJ4tbne7B-312mtkoSNwTT0C7B8hE1B4E8eRbk=.f1cd3c40-8c11-449a-9036-4744548d10e3@github.com>

On Mon, 16 Jan 2023 19:43:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I remember that match 5 uses timeout=4, so I wonder if timeout will be changed to 40 seconds will it be possible to verify old bug or not.

The test still fails:

./jdk-9-b123/bin/java -Dtest.timeout.factor=5 bug8078268
Exception in thread "main" java.lang.RuntimeException: Parsing takes too long. Current timeout is 50000
        at bug8078268.main(bug8078268.java:65)


It passes on jdk-9-b123 where [JDK-8078268](https://bugs.openjdk.org/browse/JDK-8078268) is fixed.

-------------

PR: https://git.openjdk.org/jdk/pull/12011


From aivanov at openjdk.org  Mon Jan 16 20:44:09 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 16 Jan 2023 20:44:09 GMT
Subject: RFR: 8286581: Make Java process DPI Aware if sun.java2d.dpiaware
 property is set
In-Reply-To: <HnbTtI7Q0467OzM1jTs1_yGl4ZZTzIEuQLuyUyseXLY=.ce6942e5-82e6-430b-a094-544a7d0ff76f@github.com>
References: <HnbTtI7Q0467OzM1jTs1_yGl4ZZTzIEuQLuyUyseXLY=.ce6942e5-82e6-430b-a094-544a7d0ff76f@github.com>
Message-ID: <NiOD3t6uhoCEPO1PMgQLL4E6OKe2XfUlcsFEWZLKSVs=.4f89d706-bfca-4ecf-95a4-3b05c5b7afb7@github.com>

On Fri, 13 Jan 2023 20:53:31 GMT, Rajat Mahajan <duke at openjdk.org> wrote:

> I tested by removing dpi-awareness settings from the manifest file, and then running my app with -Dsun.java2d.dpiaware=false. This showed java.exe as "Unaware" in task-manager, and with it set to true I saw "Per-Monitor (v2)" dpi awareness for java.exe.

Looks good to me.

Please update the copyright year.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11998


From aivanov at openjdk.org  Mon Jan 16 20:50:14 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 16 Jan 2023 20:50:14 GMT
Subject: RFR: JDK-8300205: Swing test bug8078268 make latch timeout
 configurable
In-Reply-To: <yIdk4ayM8O8m36fa2MokAoaqBmY6GI3TosTVXZjWzyw=.b9236a8c-9045-4207-b64a-8a382664c32f@github.com>
References: <yIdk4ayM8O8m36fa2MokAoaqBmY6GI3TosTVXZjWzyw=.b9236a8c-9045-4207-b64a-8a382664c32f@github.com>
Message-ID: <IhqKbfU_iUsk7xBgzpY7771-TAM1z0golyNWGO8m8HQ=.936e14e9-6272-4a7b-8076-c46ecaf09b35@github.com>

On Mon, 16 Jan 2023 15:09:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test javax/swing/text/html/parser/Parser/8078268/bug8078268.java has a latch timeout that is currently fix but should better be configurable to better deal with slow test infrastructures.

test/jdk/javax/swing/text/html/parser/Parser/8078268/bug8078268.java line 41:

> 39: */
> 40: public class bug8078268 {
> 41:     private static final float timeoutFactor = Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));

Suggestion:

    private static final float timeoutFactor =
            Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));

The line is 115 chars long, I suggest wrapping it. Using static import for `parseFloat` will also reduce the length; `getProperty` could also be statically imported.

-------------

PR: https://git.openjdk.org/jdk/pull/12011


From serb at openjdk.org  Mon Jan 16 22:44:07 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 16 Jan 2023 22:44:07 GMT
Subject: RFR: JDK-8300205: Swing test bug8078268 make latch timeout
 configurable
In-Reply-To: <yIdk4ayM8O8m36fa2MokAoaqBmY6GI3TosTVXZjWzyw=.b9236a8c-9045-4207-b64a-8a382664c32f@github.com>
References: <yIdk4ayM8O8m36fa2MokAoaqBmY6GI3TosTVXZjWzyw=.b9236a8c-9045-4207-b64a-8a382664c32f@github.com>
Message-ID: <wcDL0YPcMMPzNpA7kwouclsPROw3f7fidI-6OUJMLSg=.f50db7ec-7d16-437c-9c2b-64a6b523e077@github.com>

On Mon, 16 Jan 2023 15:09:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test javax/swing/text/html/parser/Parser/8078268/bug8078268.java has a latch timeout that is currently fix but should better be configurable to better deal with slow test infrastructures.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12011


From duke at openjdk.org  Mon Jan 16 23:22:00 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 16 Jan 2023 23:22:00 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v11]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <S5AVjGo0WvhVFDj7fxOscuRhQisB7bkXZbQXuMpjouU=.646605ae-74d8-4878-9278-71bedfcaf3ac@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision:

 - Remove unused type variable on method visitScoped().
 - Remove expression type filtering; it doesn't seem to be needed.
 - Clean up unused import.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/0b06dc32..a0b4310d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=09-10

  Stats: 21 lines in 2 files changed: 0 ins; 20 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

PR: https://git.openjdk.org/jdk/pull/11874


From duke at openjdk.org  Tue Jan 17 02:00:10 2023
From: duke at openjdk.org (SWinxy)
Date: Tue, 17 Jan 2023 02:00:10 GMT
Subject: RFR: 8283203: Fix typo in SystemTray.getTrayIconSize javadoc
Message-ID: <jyFfacQPd-RpuTaqXuL7omzSVJ8SVtPUdHD384tIGGk=.b6462801-7074-4183-934f-c6bfbfabcf9d@github.com>

Please review this itty-bitty typo fix.

-------------

Commit messages:
 - 8283203: Fix typo in SystemTray.getTrayIconSize javadoc

Changes: https://git.openjdk.org/jdk/pull/12020/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12020&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8283203
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12020.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12020/head:pull/12020

PR: https://git.openjdk.org/jdk/pull/12020


From dholmes at openjdk.org  Tue Jan 17 04:32:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jan 2023 04:32:08 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <OFfuAHdidKLnoukO-HBMeNeSSmAFI5_mb4mGx6f-EFI=.0192744e-3e2a-4fcb-aa45-87f0e3ba83a5@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the fix for the build failure with clang-15.
> 
> 1. -Wbitwise-instead-of-logical
> 
>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
> 
> 
> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
> 
>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
> 
>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
> 
>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
> 
> 
> 3. -Wdeprecated-builtins
> 
>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
> 
>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
> 
> 4. -Wgnu-folding-constant
> 
>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
> 
> 
> Thanks.
> Best regards,
> Jie

Hotspot changes are good.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12005


From tr at openjdk.org  Tue Jan 17 04:48:16 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 17 Jan 2023 04:48:16 GMT
Subject: Integrated: 8300084: AquaFileChooserUI.getDefaultButton returns null
In-Reply-To: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
References: <JStKtmHDaTI_D8xCEkoSzrgit27UkZw-SONWoEQl-5A=.3a694887-73a2-49ad-b914-b79a78e4654e@github.com>
Message-ID: <iU0jTB_69B82II7S8G2Yz5fBJp7Luij8021Prk20JPk=.d4499f5e-097d-46a3-88d9-2ea4037cafad@github.com>

On Mon, 16 Jan 2023 11:17:10 GMT, Tejesh R <tr at openjdk.org> wrote:

> In Aqua look and feel, `getDefaultButton()` of `JFileChooser` returns null. The fix overrides the method from `FileChooserUI` to return the `ApproveButton` of `FileChooser` which is similar to other L&F. 
> The test is run for multiple iterations in CI machine.

This pull request has now been integrated.

Changeset: 8365c677
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8365c6775cb3d2e15c4849f0ba69dc49bad2cf6a
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8300084: AquaFileChooserUI.getDefaultButton returns null

Reviewed-by: aivanov, serb

-------------

PR: https://git.openjdk.org/jdk/pull/12008


From tr at openjdk.org  Tue Jan 17 05:07:42 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 17 Jan 2023 05:07:42 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v11]
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <hyDYrgPkx980esjScy13J0_2NBhybCc1ZB_xKwZjTo4=.82362343-9f2a-4340-a74d-5cdecccff85f@github.com>

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Tooltip and Mnemonic checks added to test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11901/files
  - new: https://git.openjdk.org/jdk/pull/11901/files/4ec6b60e..9438e8df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11901&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11901&range=09-10

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11901.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11901/head:pull/11901

PR: https://git.openjdk.org/jdk/pull/11901


From tr at openjdk.org  Tue Jan 17 05:07:42 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 17 Jan 2023 05:07:42 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v10]
In-Reply-To: <I-DwskytFxE0FdHcLtDr7OX5wf4AbN6xh4jJtcnv48U=.e9b79329-4fa1-4f96-916c-29ba28a73d70@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <fUE1LDTOwcDd-G9sYUlGP-gyQ_hCC5aWzXooTWQvjmo=.7aa155f8-b364-4f37-8c1e-39c052504ede@github.com>
 <I-DwskytFxE0FdHcLtDr7OX5wf4AbN6xh4jJtcnv48U=.e9b79329-4fa1-4f96-916c-29ba28a73d70@github.com>
Message-ID: <cJz_g6BSwiluDFYOT1MnIDnZCBAlO652VYG1R-0ptwg=.79db2307-7937-4164-a612-25a8507444ed@github.com>

On Mon, 16 Jan 2023 18:11:14 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 JTREG summary
>
> test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 71:
> 
>> 69:             frame.setVisible(true);
>> 70: 
>> 71:             JButton customApproveButton = fileChooser.getUI().getDefaultButton(fileChooser);
> 
> we should check the changes in getApproveButtonToolTipText and getApproveButtonMnemonic as well.

For Mnemonic the default value is zero, so just have to check if its zero right......?

-------------

PR: https://git.openjdk.org/jdk/pull/11901


From psadhukhan at openjdk.org  Tue Jan 17 05:17:09 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 17 Jan 2023 05:17:09 GMT
Subject: RFR: 8267582: BasicLookAndFeel should not call
 getComponentPopupMenu twice to get a popup menu
In-Reply-To: <rVW2gyOA88cdon5y0Mjiv8DlIMzX9khi3u2k1Nm2m5Y=.622ae3fb-8a75-4d93-8ebe-9e1403b856e1@github.com>
References: <rVW2gyOA88cdon5y0Mjiv8DlIMzX9khi3u2k1Nm2m5Y=.622ae3fb-8a75-4d93-8ebe-9e1403b856e1@github.com>
Message-ID: <WSV_fyYPlPfdDouBMZm8RmxI_3PqVKhCtsMwJtur9eQ=.95e6a286-42e9-4d6e-8ecc-7ba195a0ac78@github.com>

On Mon, 16 Jan 2023 20:07:07 GMT, SWinxy <duke at openjdk.org> wrote:

> Please review this small change to cache a component's popup menu in BLAF.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java line 35:

> 33: 
> 34: import javax.sound.sampled.*;
> 35: import javax.swing.*;

Fix looks ok.
But , please replace the wildcard imports with specific ones

-------------

PR: https://git.openjdk.org/jdk/pull/12017


From abhiscxk at openjdk.org  Tue Jan 17 05:30:14 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 17 Jan 2023 05:30:14 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v11]
In-Reply-To: <hyDYrgPkx980esjScy13J0_2NBhybCc1ZB_xKwZjTo4=.82362343-9f2a-4340-a74d-5cdecccff85f@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <hyDYrgPkx980esjScy13J0_2NBhybCc1ZB_xKwZjTo4=.82362343-9f2a-4340-a74d-5cdecccff85f@github.com>
Message-ID: <Xfo8UJm0Jocu6dw5mYrD3aeV96NDoaNv-WSUuvAnZaw=.0513a631-cff2-4999-97e4-b50c2ccf95d7@github.com>

On Tue, 17 Jan 2023 05:07:42 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tooltip and Mnemonic checks added to test

test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 24:

> 22:  */
> 23: import java.awt.Component;
> 24: import java.awt.Container;

`awt` imports may not be required. I think you can remove them.

-------------

PR: https://git.openjdk.org/jdk/pull/11901


From tr at openjdk.org  Tue Jan 17 05:37:38 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 17 Jan 2023 05:37:38 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v12]
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11901/files
  - new: https://git.openjdk.org/jdk/pull/11901/files/9438e8df..8c3d5c00

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11901&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11901&range=10-11

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11901.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11901/head:pull/11901

PR: https://git.openjdk.org/jdk/pull/11901


From jiefu at openjdk.org  Tue Jan 17 06:03:13 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 17 Jan 2023 06:03:13 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <OFfuAHdidKLnoukO-HBMeNeSSmAFI5_mb4mGx6f-EFI=.0192744e-3e2a-4fcb-aa45-87f0e3ba83a5@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <OFfuAHdidKLnoukO-HBMeNeSSmAFI5_mb4mGx6f-EFI=.0192744e-3e2a-4fcb-aa45-87f0e3ba83a5@github.com>
Message-ID: <Z1mb5W9xZsxCAsddrOnUd7BpoXR2wMxJfU8PosdtgJw=.36e86349-76eb-427f-8732-27fa4469cc1a@github.com>

On Tue, 17 Jan 2023 04:29:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hotspot changes are good.

Thanks @dholmes-ora .

-------------

PR: https://git.openjdk.org/jdk/pull/12005


From abhiscxk at openjdk.org  Tue Jan 17 06:16:13 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 17 Jan 2023 06:16:13 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v12]
In-Reply-To: <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
Message-ID: <EXw1e5yy3sZOZtXSb6HTT96qTkBOjcEVZgy6vg-ChX4=.7617ed3c-f1fc-4a06-9bba-9323c5e13934@github.com>

On Tue, 17 Jan 2023 05:37:38 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports

LGTM.

-------------

Marked as reviewed by abhiscxk (Author).

PR: https://git.openjdk.org/jdk/pull/11901


From psadhukhan at openjdk.org  Tue Jan 17 06:40:09 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 17 Jan 2023 06:40:09 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <pHTdqf0pQnv8VQCNpisrXxpJv4aMhxQWDq_hnt2p7Hg=.146b5118-09c0-47c4-b128-245801f4144e@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
 <pHTdqf0pQnv8VQCNpisrXxpJv4aMhxQWDq_hnt2p7Hg=.146b5118-09c0-47c4-b128-245801f4144e@github.com>
Message-ID: <Sf4b_RNuiz3OsybfUrBlBfoZnzmNOPmHrl8LH-NQrxM=.8df1e739-3949-4356-b998-c13b50572626@github.com>

On Mon, 16 Jan 2023 05:31:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> `list` and `c` points to same object
> _javax.swing.JList[,0,0,0x0,invalid,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.synth.SynthBorder at fc8b518,flags=3355472 8,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=DerivedColor(col or=57,105,138 parent=nimbusSelectionBackground offsets=0.0,0.0,0.0,0 pColor=57,105,138,selectionForeground=DerivedColor(color=255,255,255 parent= nimbusLightBackground offsets=0.0,0.0,0.0,0 pColor=255,255,255,visibleRowCount=22,layoutOrientation=0]_
> so there's nothing different in it between them..

Also, `c `and `this ` in SynthInternalFrameTitlePaneUI points also to same object
 _javax.swing.plaf.synth.SynthInternalFrameTitlePane[,0,0,0x0,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,max
imumSize=,minimumSize=,preferredSize=]_

so as such there is no functional change for this fix and it can be viewed as a code-cleanup to make synth classes consistent.

-------------

PR: https://git.openjdk.org/jdk/pull/11875


From abhiscxk at openjdk.org  Tue Jan 17 08:09:00 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 17 Jan 2023 08:09:00 GMT
Subject: RFR: 8300168: Typo in AccessibleJTableHeaderEntry javadoc
Message-ID: <4EwdNh6zXxHBnEAysBUG01Jh3lsTPjYzMs8yk-RSNMA=.040cea65-ccde-4cd2-afd8-e2589f13514c@github.com>

There was a typo error in method description of `public AccessibleJTableHeaderEntry(int c, JTableHeader p, JTable t)`. Replaced the text `AccessiblJTableHeaaderEntry` with `AccessibleJTableHeaderEntry`.

-------------

Commit messages:
 - Typo error fix

Changes: https://git.openjdk.org/jdk/pull/12024/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12024&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300168
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12024.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12024/head:pull/12024

PR: https://git.openjdk.org/jdk/pull/12024


From djelinski at openjdk.org  Tue Jan 17 08:14:48 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 17 Jan 2023 08:14:48 GMT
Subject: RFR: 8300117: Replace use of JNI_COMMIT mode with mode 0
Message-ID: <C_4vnxyyv4sLzIO2iCE8CfHI57jWmTbrZUKI0A-gkBQ=.753494dd-fbcb-4092-9878-06ac4d1301c0@github.com>

Please review this patch that fixes memory leaks in native code.

The call to `ReleaseXXArrayElements` with `JNI_COMMIT` parameter does not release the native buffer allocated by the previous `GetXXArrayElements` call. The buffer pointers were only stored in local variables and were lost on function exit.

No new regression test; existing tests under `java/awt/dnd` and `java/awt/datatransfer` cover all 3 modified functions.

Mach5 clientlibs tests continue to pass.

-------------

Commit messages:
 - Use mode = 0

Changes: https://git.openjdk.org/jdk/pull/12023/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12023&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300117
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12023.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12023/head:pull/12023

PR: https://git.openjdk.org/jdk/pull/12023


From mbaesken at openjdk.org  Tue Jan 17 08:19:38 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 17 Jan 2023 08:19:38 GMT
Subject: RFR: JDK-8300205: Swing test bug8078268 make latch timeout
 configurable [v2]
In-Reply-To: <yIdk4ayM8O8m36fa2MokAoaqBmY6GI3TosTVXZjWzyw=.b9236a8c-9045-4207-b64a-8a382664c32f@github.com>
References: <yIdk4ayM8O8m36fa2MokAoaqBmY6GI3TosTVXZjWzyw=.b9236a8c-9045-4207-b64a-8a382664c32f@github.com>
Message-ID: <R1YbbZUNFOY6rwZ5zw3G6u0hi4DZ0ABBSV-zSIRsWLU=.3281e026-5d39-43d8-b98b-d6933d21045b@github.com>

> The test javax/swing/text/html/parser/Parser/8078268/bug8078268.java has a latch timeout that is currently fix but should better be configurable to better deal with slow test infrastructures.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust COPYRIGHT, shorten line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12011/files
  - new: https://git.openjdk.org/jdk/pull/12011/files/0c46dace..eed9e967

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12011&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12011&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12011.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12011/head:pull/12011

PR: https://git.openjdk.org/jdk/pull/12011


From mbaesken at openjdk.org  Tue Jan 17 08:24:18 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 17 Jan 2023 08:24:18 GMT
Subject: Integrated: JDK-8300205: Swing test bug8078268 make latch timeout
 configurable
In-Reply-To: <yIdk4ayM8O8m36fa2MokAoaqBmY6GI3TosTVXZjWzyw=.b9236a8c-9045-4207-b64a-8a382664c32f@github.com>
References: <yIdk4ayM8O8m36fa2MokAoaqBmY6GI3TosTVXZjWzyw=.b9236a8c-9045-4207-b64a-8a382664c32f@github.com>
Message-ID: <YkgBIuSuqkfylLtSsbwLbdoZ9p7Cu4gChKo5TBln9EA=.a04cd75d-eb54-428f-9b22-0a0e7026ee24@github.com>

On Mon, 16 Jan 2023 15:09:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test javax/swing/text/html/parser/Parser/8078268/bug8078268.java has a latch timeout that is currently fix but should better be configurable to better deal with slow test infrastructures.

This pull request has now been integrated.

Changeset: e82dc693
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e82dc6935b5f575a53fcba9c96767cee1b535cb8
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8300205: Swing test bug8078268 make latch timeout configurable

Reviewed-by: aivanov, serb

-------------

PR: https://git.openjdk.org/jdk/pull/12011


From psadhukhan at openjdk.org  Tue Jan 17 08:27:11 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 17 Jan 2023 08:27:11 GMT
Subject: RFR: 8300168: Typo in AccessibleJTableHeaderEntry javadoc
In-Reply-To: <4EwdNh6zXxHBnEAysBUG01Jh3lsTPjYzMs8yk-RSNMA=.040cea65-ccde-4cd2-afd8-e2589f13514c@github.com>
References: <4EwdNh6zXxHBnEAysBUG01Jh3lsTPjYzMs8yk-RSNMA=.040cea65-ccde-4cd2-afd8-e2589f13514c@github.com>
Message-ID: <CtyPFJ3uI9BShngtXEjk16iyECr7MjOoCzICCcsB7kg=.553a02a1-18ff-4910-b939-4ed3cc0a2f77@github.com>

On Tue, 17 Jan 2023 08:01:03 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> There was a typo error in method description of `public AccessibleJTableHeaderEntry(int c, JTableHeader p, JTable t)`. Replaced the text `AccessiblJTableHeaaderEntry` with `AccessibleJTableHeaderEntry`.

src/java.desktop/share/classes/javax/swing/table/JTableHeader.java line 938:

> 936: 
> 937:             /**
> 938:              *  Constructs an AccessibleJTableHeaderEntry

There's an extra space in front of "Constructs"..please remove that too..

-------------

PR: https://git.openjdk.org/jdk/pull/12024


From abhiscxk at openjdk.org  Tue Jan 17 08:33:43 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 17 Jan 2023 08:33:43 GMT
Subject: RFR: 8300168: Typo in AccessibleJTableHeaderEntry javadoc [v2]
In-Reply-To: <4EwdNh6zXxHBnEAysBUG01Jh3lsTPjYzMs8yk-RSNMA=.040cea65-ccde-4cd2-afd8-e2589f13514c@github.com>
References: <4EwdNh6zXxHBnEAysBUG01Jh3lsTPjYzMs8yk-RSNMA=.040cea65-ccde-4cd2-afd8-e2589f13514c@github.com>
Message-ID: <uhfzBFndmpganDmYG6nePs9Gsyy0NfgumWHv5kVGq64=.2732659b-763e-46c8-8865-88fd4f480f50@github.com>

> There was a typo error in method description of `public AccessibleJTableHeaderEntry(int c, JTableHeader p, JTable t)`. Replaced the text `AccessiblJTableHeaaderEntry` with `AccessibleJTableHeaderEntry`.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Removed extra space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12024/files
  - new: https://git.openjdk.org/jdk/pull/12024/files/0ed8132e..54f61735

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12024&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12024&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12024.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12024/head:pull/12024

PR: https://git.openjdk.org/jdk/pull/12024


From abhiscxk at openjdk.org  Tue Jan 17 08:33:43 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 17 Jan 2023 08:33:43 GMT
Subject: RFR: 8300168: Typo in AccessibleJTableHeaderEntry javadoc [v2]
In-Reply-To: <CtyPFJ3uI9BShngtXEjk16iyECr7MjOoCzICCcsB7kg=.553a02a1-18ff-4910-b939-4ed3cc0a2f77@github.com>
References: <4EwdNh6zXxHBnEAysBUG01Jh3lsTPjYzMs8yk-RSNMA=.040cea65-ccde-4cd2-afd8-e2589f13514c@github.com>
 <CtyPFJ3uI9BShngtXEjk16iyECr7MjOoCzICCcsB7kg=.553a02a1-18ff-4910-b939-4ed3cc0a2f77@github.com>
Message-ID: <D6-p5ceghZRiUCCe0LeiyE9SX_ThO-E5jB3qXJAJjaI=.d883349b-3d85-4e80-8ce9-0116bdd882e3@github.com>

On Tue, 17 Jan 2023 08:24:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed extra space
>
> src/java.desktop/share/classes/javax/swing/table/JTableHeader.java line 938:
> 
>> 936: 
>> 937:             /**
>> 938:              *  Constructs an AccessibleJTableHeaderEntry
> 
> There's an extra space in front of "Constructs"..please remove that too..

Updated.

-------------

PR: https://git.openjdk.org/jdk/pull/12024


From psadhukhan at openjdk.org  Tue Jan 17 08:41:12 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 17 Jan 2023 08:41:12 GMT
Subject: RFR: 8300168: Typo in AccessibleJTableHeaderEntry javadoc [v2]
In-Reply-To: <uhfzBFndmpganDmYG6nePs9Gsyy0NfgumWHv5kVGq64=.2732659b-763e-46c8-8865-88fd4f480f50@github.com>
References: <4EwdNh6zXxHBnEAysBUG01Jh3lsTPjYzMs8yk-RSNMA=.040cea65-ccde-4cd2-afd8-e2589f13514c@github.com>
 <uhfzBFndmpganDmYG6nePs9Gsyy0NfgumWHv5kVGq64=.2732659b-763e-46c8-8865-88fd4f480f50@github.com>
Message-ID: <O7tAjNX2HAWOofVAzPedj9jvkEkBovDdq1KrI2fwh-Y=.f3203459-b296-4f98-ac51-9a0d04e11b40@github.com>

On Tue, 17 Jan 2023 08:33:43 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> There was a typo error in method description of `public AccessibleJTableHeaderEntry(int c, JTableHeader p, JTable t)`. Replaced the text `AccessiblJTableHeaaderEntry` with `AccessibleJTableHeaderEntry`.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed extra space

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12024


From tr at openjdk.org  Tue Jan 17 10:30:13 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 17 Jan 2023 10:30:13 GMT
Subject: RFR: 8300168: Typo in AccessibleJTableHeaderEntry javadoc [v2]
In-Reply-To: <uhfzBFndmpganDmYG6nePs9Gsyy0NfgumWHv5kVGq64=.2732659b-763e-46c8-8865-88fd4f480f50@github.com>
References: <4EwdNh6zXxHBnEAysBUG01Jh3lsTPjYzMs8yk-RSNMA=.040cea65-ccde-4cd2-afd8-e2589f13514c@github.com>
 <uhfzBFndmpganDmYG6nePs9Gsyy0NfgumWHv5kVGq64=.2732659b-763e-46c8-8865-88fd4f480f50@github.com>
Message-ID: <WJDG6tcE2CSILerQtpzWWsUxZLcQtHoGNWowdxGEj0k=.33f17d6d-626f-4806-b2df-d43a7a8ad392@github.com>

On Tue, 17 Jan 2023 08:33:43 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> There was a typo error in method description of `public AccessibleJTableHeaderEntry(int c, JTableHeader p, JTable t)`. Replaced the text `AccessiblJTableHeaaderEntry` with `AccessibleJTableHeaderEntry`.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed extra space

Marked as reviewed by tr (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/12024


From abhiscxk at openjdk.org  Tue Jan 17 10:43:19 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 17 Jan 2023 10:43:19 GMT
Subject: Integrated: 8300168: Typo in AccessibleJTableHeaderEntry javadoc
In-Reply-To: <4EwdNh6zXxHBnEAysBUG01Jh3lsTPjYzMs8yk-RSNMA=.040cea65-ccde-4cd2-afd8-e2589f13514c@github.com>
References: <4EwdNh6zXxHBnEAysBUG01Jh3lsTPjYzMs8yk-RSNMA=.040cea65-ccde-4cd2-afd8-e2589f13514c@github.com>
Message-ID: <XTLI44GqphEzcsxItg6UxlU8qFoBYvdhgT07skn-oGo=.456a87eb-95fb-40f7-95d9-650bcd736365@github.com>

On Tue, 17 Jan 2023 08:01:03 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> There was a typo error in method description of `public AccessibleJTableHeaderEntry(int c, JTableHeader p, JTable t)`. Replaced the text `AccessiblJTableHeaaderEntry` with `AccessibleJTableHeaderEntry`.

This pull request has now been integrated.

Changeset: 07d57531
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Committer: Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07d57531726092a003d4c5d4febd33e35e02a1a7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8300168: Typo in AccessibleJTableHeaderEntry javadoc

Reviewed-by: psadhukhan, tr

-------------

PR: https://git.openjdk.org/jdk/pull/12024


From jiefu at openjdk.org  Tue Jan 17 11:33:12 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 17 Jan 2023 11:33:12 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <vbGfneNvtdDItzIDppzwCHK_adtw5fm3DT3Pm_0Ygr0=.2346b778-78ec-4e9b-ac7f-3d32118a11be@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the fix for the build failure with clang-15.
> 
> 1. -Wbitwise-instead-of-logical
> 
>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
> 
> 
> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
> 
>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
> 
>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
> 
>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
> 
> 
> 3. -Wdeprecated-builtins
> 
>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
> 
>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
> 
> 4. -Wgnu-folding-constant
> 
>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
> 
> 
> Thanks.
> Best regards,
> Jie

Hi @kevinrushforth and @AlanBateman , are you fine with this change?
Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/12005


From vsitnikov at openjdk.org  Tue Jan 17 11:47:26 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Tue, 17 Jan 2023 11:47:26 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <aifLgLpgJS_gMzyzRP6INOO4R7bE50ruKJ6R5pQS-lk=.66345dcc-48ae-43d9-b205-8d2f8f1e7ebf@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
 <RL9o7v8nYmartQrhygV7sw42MUZ8vaS1qoqy0TzH_6s=.71f4b88f-3517-41f2-8e2f-d059eb3f4969@github.com>
 <aifLgLpgJS_gMzyzRP6INOO4R7bE50ruKJ6R5pQS-lk=.66345dcc-48ae-43d9-b205-8d2f8f1e7ebf@github.com>
Message-ID: <JxuulcLUmSJ-XI3ENSzO2Nji3I5Z-irlTUt3AITca0c=.d6978830-c241-4d1a-be0d-1515935c38e2@github.com>

On Mon, 16 Jan 2023 18:52:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The non-client parts look fine.
>
> @RogerRiggs Thanks!

@magicus , have you considered adding `.editorconfig` file (see https://editorconfig.org/ ) so it configures developers' editors to trim the whitespace?

Of course, `.editorconfig` does not enforce the policy, however, it would make it easier for those who use editors that support `.editorconfig`. For instance, IntelliJ editors support it by default.

-------------

PR: https://git.openjdk.org/jdk/pull/11491


From ihse at openjdk.org  Tue Jan 17 12:17:25 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 17 Jan 2023 12:17:25 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <JxuulcLUmSJ-XI3ENSzO2Nji3I5Z-irlTUt3AITca0c=.d6978830-c241-4d1a-be0d-1515935c38e2@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
 <RL9o7v8nYmartQrhygV7sw42MUZ8vaS1qoqy0TzH_6s=.71f4b88f-3517-41f2-8e2f-d059eb3f4969@github.com>
 <aifLgLpgJS_gMzyzRP6INOO4R7bE50ruKJ6R5pQS-lk=.66345dcc-48ae-43d9-b205-8d2f8f1e7ebf@github.com>
 <JxuulcLUmSJ-XI3ENSzO2Nji3I5Z-irlTUt3AITca0c=.d6978830-c241-4d1a-be0d-1515935c38e2@github.com>
Message-ID: <lKrVS5Y1fnd5UqKpq4potUFK_E7nBX4lAeqVoLY1OrM=.0db54199-ac6f-4b3a-bf25-f6df1db5bfef@github.com>

On Tue, 17 Jan 2023 11:44:32 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> @RogerRiggs Thanks!
>
> @magicus , have you considered adding `.editorconfig` file (see https://editorconfig.org/ ) so it configures developers' editors to trim the whitespace?
> 
> Of course, `.editorconfig` does not enforce the policy, however, it would make it easier for those who use editors that support `.editorconfig`. For instance, IntelliJ editors support it by default.

@vlsi That is an interesting suggestion. My experience with `.editorconfig` is that it is a bit so-so about getting it to actually describe the coding practices of a project, but it can probably be used for a thing like stripping trailing whitespace.

I suggest we continue that discussion in ide-support-dev at openjdk.org, to figure out exactly what can be added to an `.editorconfig file`, how it interacts with jcheck rules and test how different IDEs behave.

-------------

PR: https://git.openjdk.org/jdk/pull/11491


From serb at openjdk.org  Tue Jan 17 13:27:13 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 17 Jan 2023 13:27:13 GMT
Subject: RFR: 8300117: Replace use of JNI_COMMIT mode with mode 0
In-Reply-To: <C_4vnxyyv4sLzIO2iCE8CfHI57jWmTbrZUKI0A-gkBQ=.753494dd-fbcb-4092-9878-06ac4d1301c0@github.com>
References: <C_4vnxyyv4sLzIO2iCE8CfHI57jWmTbrZUKI0A-gkBQ=.753494dd-fbcb-4092-9878-06ac4d1301c0@github.com>
Message-ID: <uyv8tMRB1xxUYiWZvcT7cBV26u9qm87nsrbNPPCSnSo=.4a5fed9f-04ea-4f7b-bce8-0733e0872156@github.com>

On Tue, 17 Jan 2023 07:43:41 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that fixes memory leaks in native code.
> 
> The call to `ReleaseXXArrayElements` with `JNI_COMMIT` parameter does not release the native buffer allocated by the previous `GetXXArrayElements` call. The buffer pointers were only stored in local variables and were lost on function exit.
> 
> No new regression test; existing tests under `java/awt/dnd` and `java/awt/datatransfer` cover all 3 modified functions.
> 
> Mach5 clientlibs tests continue to pass.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12023


From kcr at openjdk.org  Tue Jan 17 13:38:14 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 17 Jan 2023 13:38:14 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <ABCj-zAMOh9x0xfkZN4dvaigzkTyWs6WWx1uRtQpZmA=.21c0b273-8122-4903-aeb7-0d65030cdc00@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the fix for the build failure with clang-15.
> 
> 1. -Wbitwise-instead-of-logical
> 
>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
> 
> 
> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
> 
>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
> 
>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
> 
>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
> 
> 
> 3. -Wdeprecated-builtins
> 
>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
> 
>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
> 
> 4. -Wgnu-folding-constant
> 
>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
> 
> 
> Thanks.
> Best regards,
> Jie

Yes, but I would wait for @prrace to review the Harfbuzz change.

-------------

PR: https://git.openjdk.org/jdk/pull/12005


From kcr at openjdk.org  Tue Jan 17 13:38:17 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 17 Jan 2023 13:38:17 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <0hacUHSSaPqiYtv3EsaC4UVe_da0hydgcTrpUpn9w6s=.ae39b693-7f04-40ab-94c0-a90f95c6c260@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <KNSxgTc0PTTJMrnnClBbw3aWl-OiDixgplMRl-F38nc=.fc1273ad-2bce-44e7-ae1f-ddca61a37119@github.com>
 <0hacUHSSaPqiYtv3EsaC4UVe_da0hydgcTrpUpn9w6s=.ae39b693-7f04-40ab-94c0-a90f95c6c260@github.com>
Message-ID: <vZLF4HQRfvxIa4lw69akNAPdD8t6YWmwGa_ARxwrtKc=.769c954d-9327-40d8-9e07-815dbab43b36@github.com>

On Sun, 15 Jan 2023 01:56:06 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> src/java.desktop/share/native/libharfbuzz/hb-meta.hh line 191:
>> 
>>> 189: #define hb_int_max(T) hb_int_max<T>::value
>>> 190: 
>>> 191: #if defined(__GNUC__) && __GNUC__ < 5 && !defined(__clang__)
>> 
>> Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm.
>
>> Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm.
> 
> Thanks @kevinrushforth for your review.
> 
> Yes, it had been fixed in the upstream and I just follow it.
> Please see https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 .
> 
> Or did you mean we had to sync the whole harfbuzz with the upstream?
> If so, I would suggest doing it in a separate PR.
> What do you think?
> Thanks.

No, I didn't mean to update all of harfbuzz. What you've done seems fine to me, but let's see what @prrace says.

-------------

PR: https://git.openjdk.org/jdk/pull/12005


From aivanov at openjdk.org  Tue Jan 17 15:43:46 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Jan 2023 15:43:46 GMT
Subject: RFR: 8300166: Unused array allocation in ProcessPath.doProcessPath
In-Reply-To: <_UJnizZOuCPw1KX0NA1zhrjfQp0nL73NOXlSkNz-VxQ=.4d89f2c5-87b0-46dd-9aeb-1c19e1636a29@github.com>
References: <_UJnizZOuCPw1KX0NA1zhrjfQp0nL73NOXlSkNz-VxQ=.4d89f2c5-87b0-46dd-9aeb-1c19e1636a29@github.com>
Message-ID: <VfQMYDUQSitLIV-smnzx8KUhLYK9r3594Hz0IDnPCRo=.d0261511-7eed-4ea5-b103-49319e6e9d9b@github.com>

On Sat, 7 Jan 2023 19:29:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> I don't see this array in `src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c` too. Seems leftovers from refactoring?

Looks good to me.

Builds are fine, clientlibs tests pass successfully.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11894


From aivanov at openjdk.org  Tue Jan 17 16:11:17 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Jan 2023 16:11:17 GMT
Subject: RFR: 8283203: Fix typo in SystemTray.getTrayIconSize javadoc
In-Reply-To: <jyFfacQPd-RpuTaqXuL7omzSVJ8SVtPUdHD384tIGGk=.b6462801-7074-4183-934f-c6bfbfabcf9d@github.com>
References: <jyFfacQPd-RpuTaqXuL7omzSVJ8SVtPUdHD384tIGGk=.b6462801-7074-4183-934f-c6bfbfabcf9d@github.com>
Message-ID: <8WRS-IcsjCKUIoGxWyET27PGVi5OOA7YGl68D8d2WPo=.90e0c2ee-7aba-4b57-9792-f96fccb12d84@github.com>

On Tue, 17 Jan 2023 01:53:05 GMT, SWinxy <duke at openjdk.org> wrote:

> Please review this itty-bitty typo fix.

Thank you for taking this one. It looks good to me except for additional words in the description.

Could you also update the copyright year?

src/java.desktop/share/classes/java/awt/SystemTray.java line 348:

> 346:      * Returns the size, in pixels, of the space that a tray icon will
> 347:      * occupy in the system tray. Developers may use this method to
> 348:      * acquire the preferred size for the image property of a tray icon

Suggestion:

     * acquire the preferred size of a tray icon

_?the image property?_ seems out of place, nor does it add clarity.

-------------

PR: https://git.openjdk.org/jdk/pull/12020


From aivanov at openjdk.org  Tue Jan 17 16:18:58 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Jan 2023 16:18:58 GMT
Subject: RFR: 8283203: Fix typo in SystemTray.getTrayIconSize javadoc
In-Reply-To: <jyFfacQPd-RpuTaqXuL7omzSVJ8SVtPUdHD384tIGGk=.b6462801-7074-4183-934f-c6bfbfabcf9d@github.com>
References: <jyFfacQPd-RpuTaqXuL7omzSVJ8SVtPUdHD384tIGGk=.b6462801-7074-4183-934f-c6bfbfabcf9d@github.com>
Message-ID: <B2NS8k-e322aZ6DKG1vepV4DOGOE3H4pXeG8V7MkbCY=.964e0b7a-274a-4fdc-a8f0-94140edc14e7@github.com>

On Tue, 17 Jan 2023 01:53:05 GMT, SWinxy <duke at openjdk.org> wrote:

> Please review this itty-bitty typo fix.

I submitted [JDK-8300280](https://bugs.openjdk.org/browse/JDK-8300280) regarding *??the size **in pixels**??*:
https://github.com/openjdk/jdk/blob/a9b9831f2a88ed3b7701d402b167a096b94aeb98/src/java.desktop/share/classes/java/awt/SystemTray.java#L346

-------------

PR: https://git.openjdk.org/jdk/pull/12020


From duke at openjdk.org  Tue Jan 17 16:23:36 2023
From: duke at openjdk.org (SWinxy)
Date: Tue, 17 Jan 2023 16:23:36 GMT
Subject: RFR: 8283203: Fix typo in SystemTray.getTrayIconSize javadoc [v2]
In-Reply-To: <jyFfacQPd-RpuTaqXuL7omzSVJ8SVtPUdHD384tIGGk=.b6462801-7074-4183-934f-c6bfbfabcf9d@github.com>
References: <jyFfacQPd-RpuTaqXuL7omzSVJ8SVtPUdHD384tIGGk=.b6462801-7074-4183-934f-c6bfbfabcf9d@github.com>
Message-ID: <eeFW6lqhfEXIQTzpq6ddBSFlq5DC7-pWD7758BQh1-E=.059e49d8-ea90-41ab-b79e-057b88d52d70@github.com>

> Please review this itty-bitty typo fix.

SWinxy has updated the pull request incrementally with one additional commit since the last revision:

  Copyright & rm fluff

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12020/files
  - new: https://git.openjdk.org/jdk/pull/12020/files/fde05c26..5345e4b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12020&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12020&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12020.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12020/head:pull/12020

PR: https://git.openjdk.org/jdk/pull/12020


From duke at openjdk.org  Tue Jan 17 16:50:51 2023
From: duke at openjdk.org (SWinxy)
Date: Tue, 17 Jan 2023 16:50:51 GMT
Subject: RFR: 8267582: BasicLookAndFeel should not call
 getComponentPopupMenu twice to get a popup menu [v2]
In-Reply-To: <rVW2gyOA88cdon5y0Mjiv8DlIMzX9khi3u2k1Nm2m5Y=.622ae3fb-8a75-4d93-8ebe-9e1403b856e1@github.com>
References: <rVW2gyOA88cdon5y0Mjiv8DlIMzX9khi3u2k1Nm2m5Y=.622ae3fb-8a75-4d93-8ebe-9e1403b856e1@github.com>
Message-ID: <g0aiOQAweZl1UFOF7dFLvfwf55zKXlSB6_rPQGyNbCg=.ded372f1-22c9-4400-b143-f2ee2082d9f2@github.com>

> Please review this small change to cache a component's popup menu in BLAF.

SWinxy has updated the pull request incrementally with one additional commit since the last revision:

  Single-class imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12017/files
  - new: https://git.openjdk.org/jdk/pull/12017/files/a17c4cdb..37746f07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12017&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12017&range=00-01

  Stats: 41 lines in 1 file changed: 36 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12017/head:pull/12017

PR: https://git.openjdk.org/jdk/pull/12017


From duke at openjdk.org  Tue Jan 17 16:50:54 2023
From: duke at openjdk.org (SWinxy)
Date: Tue, 17 Jan 2023 16:50:54 GMT
Subject: RFR: 8267582: BasicLookAndFeel should not call
 getComponentPopupMenu twice to get a popup menu [v2]
In-Reply-To: <WSV_fyYPlPfdDouBMZm8RmxI_3PqVKhCtsMwJtur9eQ=.95e6a286-42e9-4d6e-8ecc-7ba195a0ac78@github.com>
References: <rVW2gyOA88cdon5y0Mjiv8DlIMzX9khi3u2k1Nm2m5Y=.622ae3fb-8a75-4d93-8ebe-9e1403b856e1@github.com>
 <WSV_fyYPlPfdDouBMZm8RmxI_3PqVKhCtsMwJtur9eQ=.95e6a286-42e9-4d6e-8ecc-7ba195a0ac78@github.com>
Message-ID: <9Dcs_TeBNon4KtcE7o5DVnlNOEEga9eSSXOchrzjQPo=.3963b345-bac7-46f4-b02b-8e4ec6296b50@github.com>

On Tue, 17 Jan 2023 05:14:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Single-class imports
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java line 35:
> 
>> 33: 
>> 34: import javax.sound.sampled.*;
>> 35: import javax.swing.*;
> 
> Fix looks ok.
> But , please replace the wildcard imports with specific ones

Thank you!

-------------

PR: https://git.openjdk.org/jdk/pull/12017


From alanb at openjdk.org  Tue Jan 17 16:54:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Jan 2023 16:54:14 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <ABCj-zAMOh9x0xfkZN4dvaigzkTyWs6WWx1uRtQpZmA=.21c0b273-8122-4903-aeb7-0d65030cdc00@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <ABCj-zAMOh9x0xfkZN4dvaigzkTyWs6WWx1uRtQpZmA=.21c0b273-8122-4903-aeb7-0d65030cdc00@github.com>
Message-ID: <a8NjKk5ruGTmxeaA5kG9rlCH6_buPpBBCxsrbaOZX6Q=.88ba3920-4d30-451d-9691-98e25fdeb0d2@github.com>

On Tue, 17 Jan 2023 13:33:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the fix for the build failure with clang-15.
>> 
>> 1. -Wbitwise-instead-of-logical
>> 
>>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
>> 
>> 
>> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
>> 
>>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
>> 
>>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
>> 
>>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
>> 
>> 
>> 3. -Wdeprecated-builtins
>> 
>>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
>> 
>>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
>> 
>> 4. -Wgnu-folding-constant
>> 
>>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
>> 
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Yes, but I would wait for @prrace to review the Harfbuzz change.

> Hi @kevinrushforth and @AlanBateman , are you fine with this change?

No objection from me but I agree with Kevin to wait to see what Phil says about Harfbuzz.

-------------

PR: https://git.openjdk.org/jdk/pull/12005


From aivanov at openjdk.org  Tue Jan 17 17:00:19 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Jan 2023 17:00:19 GMT
Subject: RFR: 8283203: Fix typo in SystemTray.getTrayIconSize javadoc [v2]
In-Reply-To: <eeFW6lqhfEXIQTzpq6ddBSFlq5DC7-pWD7758BQh1-E=.059e49d8-ea90-41ab-b79e-057b88d52d70@github.com>
References: <jyFfacQPd-RpuTaqXuL7omzSVJ8SVtPUdHD384tIGGk=.b6462801-7074-4183-934f-c6bfbfabcf9d@github.com>
 <eeFW6lqhfEXIQTzpq6ddBSFlq5DC7-pWD7758BQh1-E=.059e49d8-ea90-41ab-b79e-057b88d52d70@github.com>
Message-ID: <wBoHnp1Wr-_cBcW0pyN5azrlLk3HEGakd-g-A5gKuiQ=.c759347d-39ca-462e-b149-6873b638ae5c@github.com>

On Tue, 17 Jan 2023 16:23:36 GMT, SWinxy <duke at openjdk.org> wrote:

>> Please review this itty-bitty typo fix.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright & rm fluff

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12020


From chen.j.patrick at gmail.com  Tue Jan 17 17:00:29 2023
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Tue, 17 Jan 2023 18:00:29 +0100
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <a8NjKk5ruGTmxeaA5kG9rlCH6_buPpBBCxsrbaOZX6Q=.88ba3920-4d30-451d-9691-98e25fdeb0d2@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <ABCj-zAMOh9x0xfkZN4dvaigzkTyWs6WWx1uRtQpZmA=.21c0b273-8122-4903-aeb7-0d65030cdc00@github.com>
 <a8NjKk5ruGTmxeaA5kG9rlCH6_buPpBBCxsrbaOZX6Q=.88ba3920-4d30-451d-9691-98e25fdeb0d2@github.com>
Message-ID: <CANmuJ8sw_xzeHAVRMBUoDQtTSQEaV0KqexU3aD3As78XBFCLGw@mail.gmail.com>

no you have to revert the commit


Le mar. 17 janv. 2023 ? 17:55, Alan Bateman <alanb at openjdk.org> a ?crit :

> On Tue, 17 Jan 2023 13:33:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
>
> >> Hi all,
> >>
> >> Please review the fix for the build failure with clang-15.
> >>
> >> 1. -Wbitwise-instead-of-logical
> >>
> >>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the
> warning
> >>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the
> code and disable warnings
> >>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the
> code and disable warnings
> >>
> >>
> >> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
> >>
> >>    1) Mainly caused by files under
> `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable
> warnings
> >>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
> >>
> >>    2) While compiling
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <---
> keep the code and disable warnings
> >>
> >>    3) Caused by
> src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed
> the warnings
> >>
> >>
> >> 3. -Wdeprecated-builtins
> >>
> >>    Caused by files under src/java.desktop/share/native/libharfbuzz/
> <--- fixed the warnings
> >>
> >>    Ref:
> https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
> >>
> >> 4. -Wgnu-folding-constant
> >>
> >>    Caused by
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m
> <--- keep the code and disable warnings
> >>
> >>
> >> Thanks.
> >> Best regards,
> >> Jie
> >
> > Yes, but I would wait for @prrace to review the Harfbuzz change.
>
> > Hi @kevinrushforth and @AlanBateman , are you fine with this change?
>
> No objection from me but I agree with Kevin to wait to see what Phil says
> about Harfbuzz.
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/12005
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230117/4dc50b9b/attachment.htm>

From duke at openjdk.org  Tue Jan 17 17:01:48 2023
From: duke at openjdk.org (Rajat Mahajan)
Date: Tue, 17 Jan 2023 17:01:48 GMT
Subject: RFR: 8286581: Make Java process DPI Aware if sun.java2d.dpiaware
 property is set [v2]
In-Reply-To: <HnbTtI7Q0467OzM1jTs1_yGl4ZZTzIEuQLuyUyseXLY=.ce6942e5-82e6-430b-a094-544a7d0ff76f@github.com>
References: <HnbTtI7Q0467OzM1jTs1_yGl4ZZTzIEuQLuyUyseXLY=.ce6942e5-82e6-430b-a094-544a7d0ff76f@github.com>
Message-ID: <Rsjp-dYL8GbJjnG-XtxyN7I4GnU9iWCZ9bNGX6K0Pqc=.a4a0034a-9cba-4f9e-955b-cc897c749b93@github.com>

> I tested by removing dpi-awareness settings from the manifest file, and then running my app with -Dsun.java2d.dpiaware=false. This showed java.exe as "Unaware" in task-manager, and with it set to true I saw "Per-Monitor (v2)" dpi awareness for java.exe.

Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:

  Updated copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11998/files
  - new: https://git.openjdk.org/jdk/pull/11998/files/96c61570..a661b71d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11998&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11998&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11998.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11998/head:pull/11998

PR: https://git.openjdk.org/jdk/pull/11998


From dnguyen at openjdk.org  Tue Jan 17 17:04:48 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 17 Jan 2023 17:04:48 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v12]
In-Reply-To: <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
Message-ID: <QjPugzqKOykagX8b9VuQ65VKvwhVKErd1ShOI_0VhUs=.c70d7114-6710-40a8-82db-f591908789f0@github.com>

On Tue, 17 Jan 2023 05:37:38 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports

The updates look good. Everything working as expected when ran with changes.

-------------

Marked as reviewed by dnguyen (Author).

PR: https://git.openjdk.org/jdk/pull/11901


From duke at openjdk.org  Tue Jan 17 17:22:26 2023
From: duke at openjdk.org (SWinxy)
Date: Tue, 17 Jan 2023 17:22:26 GMT
Subject: RFR: 8283203: Fix typo in SystemTray.getTrayIconSize javadoc [v2]
In-Reply-To: <eeFW6lqhfEXIQTzpq6ddBSFlq5DC7-pWD7758BQh1-E=.059e49d8-ea90-41ab-b79e-057b88d52d70@github.com>
References: <jyFfacQPd-RpuTaqXuL7omzSVJ8SVtPUdHD384tIGGk=.b6462801-7074-4183-934f-c6bfbfabcf9d@github.com>
 <eeFW6lqhfEXIQTzpq6ddBSFlq5DC7-pWD7758BQh1-E=.059e49d8-ea90-41ab-b79e-057b88d52d70@github.com>
Message-ID: <3NZjijnR0ku1to-6x_TNw6OLapWgq1RoaxewUIC9HZc=.e4bd854e-96fe-43f2-ab56-89478b9c4976@github.com>

On Tue, 17 Jan 2023 16:23:36 GMT, SWinxy <duke at openjdk.org> wrote:

>> Please review this itty-bitty typo fix.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright & rm fluff

@TheShermanTanker if you're good to sponsor.

-------------

PR: https://git.openjdk.org/jdk/pull/12020


From aivanov at openjdk.org  Tue Jan 17 17:29:23 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Jan 2023 17:29:23 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v10]
In-Reply-To: <cJz_g6BSwiluDFYOT1MnIDnZCBAlO652VYG1R-0ptwg=.79db2307-7937-4164-a612-25a8507444ed@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <fUE1LDTOwcDd-G9sYUlGP-gyQ_hCC5aWzXooTWQvjmo=.7aa155f8-b364-4f37-8c1e-39c052504ede@github.com>
 <I-DwskytFxE0FdHcLtDr7OX5wf4AbN6xh4jJtcnv48U=.e9b79329-4fa1-4f96-916c-29ba28a73d70@github.com>
 <cJz_g6BSwiluDFYOT1MnIDnZCBAlO652VYG1R-0ptwg=.79db2307-7937-4164-a612-25a8507444ed@github.com>
Message-ID: <YI5ADwikDfvIAGgkpxJ0XL-z3qGbnZyw0KKimTK97yc=.58ce292b-33d6-4786-8ff3-9ee3dbb485cd@github.com>

On Tue, 17 Jan 2023 05:00:47 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/CustomApproveButtonTest.java line 71:
>> 
>>> 69:             frame.setVisible(true);
>>> 70: 
>>> 71:             JButton customApproveButton = fileChooser.getUI().getDefaultButton(fileChooser);
>> 
>> we should check the changes in getApproveButtonToolTipText and getApproveButtonMnemonic as well.
>
> For Mnemonic the default value is zero, so just have to check if its zero right......?

The default value depends on L&F, yet it looks like no L&Fs that are part of JDK set a mnemonic, which makes perfect sense for the default button in a dialog box.

This may call for an additional test which ensures the custom dialog has mnemonic of the Open button.

-------------

PR: https://git.openjdk.org/jdk/pull/11901


From duke at openjdk.org  Tue Jan 17 17:34:21 2023
From: duke at openjdk.org (SWinxy)
Date: Tue, 17 Jan 2023 17:34:21 GMT
Subject: Integrated: 8283203: Fix typo in SystemTray.getTrayIconSize javadoc
In-Reply-To: <jyFfacQPd-RpuTaqXuL7omzSVJ8SVtPUdHD384tIGGk=.b6462801-7074-4183-934f-c6bfbfabcf9d@github.com>
References: <jyFfacQPd-RpuTaqXuL7omzSVJ8SVtPUdHD384tIGGk=.b6462801-7074-4183-934f-c6bfbfabcf9d@github.com>
Message-ID: <C1S3sh3kya5lSxgmPbxmkmT-EFTxzmHWxWXZK-q1_GE=.76070b7a-1438-4205-bff6-1d37b7c3ce43@github.com>

On Tue, 17 Jan 2023 01:53:05 GMT, SWinxy <duke at openjdk.org> wrote:

> Please review this itty-bitty typo fix.

This pull request has now been integrated.

Changeset: 8c12ae86
Author:    SWinxy <swinxythecat at gmail.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c12ae867350a866a6a110ea85d86404f1efb0fb
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8283203: Fix typo in SystemTray.getTrayIconSize javadoc

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/12020


From aivanov at openjdk.org  Tue Jan 17 17:58:24 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Jan 2023 17:58:24 GMT
Subject: RFR: 8286581: Make Java process DPI Aware if sun.java2d.dpiaware
 property is set [v2]
In-Reply-To: <Rsjp-dYL8GbJjnG-XtxyN7I4GnU9iWCZ9bNGX6K0Pqc=.a4a0034a-9cba-4f9e-955b-cc897c749b93@github.com>
References: <HnbTtI7Q0467OzM1jTs1_yGl4ZZTzIEuQLuyUyseXLY=.ce6942e5-82e6-430b-a094-544a7d0ff76f@github.com>
 <Rsjp-dYL8GbJjnG-XtxyN7I4GnU9iWCZ9bNGX6K0Pqc=.a4a0034a-9cba-4f9e-955b-cc897c749b93@github.com>
Message-ID: <l5g5WE5p0IEH9CZVFs7L-ai_BsftlVRhFPYDMjU5t-A=.3e0047f7-341e-49bb-89be-7b6ecf9dd93d@github.com>

On Tue, 17 Jan 2023 17:01:48 GMT, Rajat Mahajan <duke at openjdk.org> wrote:

>> I tested by removing dpi-awareness settings from the manifest file, and then running my app with -Dsun.java2d.dpiaware=false. This showed java.exe as "Unaware" in task-manager, and with it set to true I saw "Per-Monitor (v2)" dpi awareness for java.exe.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright year

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11998


From prr at openjdk.org  Tue Jan 17 18:05:14 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jan 2023 18:05:14 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <vZLF4HQRfvxIa4lw69akNAPdD8t6YWmwGa_ARxwrtKc=.769c954d-9327-40d8-9e07-815dbab43b36@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <KNSxgTc0PTTJMrnnClBbw3aWl-OiDixgplMRl-F38nc=.fc1273ad-2bce-44e7-ae1f-ddca61a37119@github.com>
 <0hacUHSSaPqiYtv3EsaC4UVe_da0hydgcTrpUpn9w6s=.ae39b693-7f04-40ab-94c0-a90f95c6c260@github.com>
 <vZLF4HQRfvxIa4lw69akNAPdD8t6YWmwGa_ARxwrtKc=.769c954d-9327-40d8-9e07-815dbab43b36@github.com>
Message-ID: <pIOV0HJbQQkRkMqZEUNMtTsmkYmsAw7SrO2qkIDwm2c=.3054d754-a519-4c59-a481-aebcf91f6673@github.com>

On Tue, 17 Jan 2023 13:35:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>> Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm.
>> 
>> Thanks @kevinrushforth for your review.
>> 
>> Yes, it had been fixed in the upstream and I just follow it.
>> Please see https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 .
>> 
>> Or did you mean we had to sync the whole harfbuzz with the upstream?
>> If so, I would suggest doing it in a separate PR.
>> What do you think?
>> Thanks.
>
> No, I didn't mean to update all of harfbuzz. What you've done seems fine to me, but let's see what @prrace says.

If the *exact* same change has been committed upstream then we are OK to take this because then when we upgrade harfbuzz (under a separate bug) whoever doing the upgrade can be blissfully ignorant of this. In fact it is because there is no easy way to be track changes on the JDK side and reapply them that we have this rule.

-------------

PR: https://git.openjdk.org/jdk/pull/12005


From prr at openjdk.org  Tue Jan 17 18:16:01 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jan 2023 18:16:01 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <4D6-l2p6z4lIpe84jpo-YMcnf1dUfmzrdF3C_KV1EgY=.ddd7f85b-58c5-451c-af94-aaae35f114bc@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the fix for the build failure with clang-15.
> 
> 1. -Wbitwise-instead-of-logical
> 
>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
> 
> 
> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
> 
>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
> 
>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
> 
>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
> 
> 
> 3. -Wdeprecated-builtins
> 
>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
> 
>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
> 
> 4. -Wgnu-folding-constant
> 
>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
> 
> 
> Thanks.
> Best regards,
> Jie

client changes are OK by me.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12005


From prr at openjdk.org  Tue Jan 17 18:22:51 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jan 2023 18:22:51 GMT
Subject: RFR: 8300117: Replace use of JNI_COMMIT mode with mode 0
In-Reply-To: <C_4vnxyyv4sLzIO2iCE8CfHI57jWmTbrZUKI0A-gkBQ=.753494dd-fbcb-4092-9878-06ac4d1301c0@github.com>
References: <C_4vnxyyv4sLzIO2iCE8CfHI57jWmTbrZUKI0A-gkBQ=.753494dd-fbcb-4092-9878-06ac4d1301c0@github.com>
Message-ID: <eDszZr3EcfqsPnwlO1sbpo0gpaZQsWOK8jihXTb_r7g=.778e9081-ddd4-445c-aea3-21085fb17f21@github.com>

On Tue, 17 Jan 2023 07:43:41 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that fixes memory leaks in native code.
> 
> The call to `ReleaseXXArrayElements` with `JNI_COMMIT` parameter does not release the native buffer allocated by the previous `GetXXArrayElements` call. The buffer pointers were only stored in local variables and were lost on function exit.
> 
> No new regression test; existing tests under `java/awt/dnd` and `java/awt/datatransfer` cover all 3 modified functions.
> 
> Mach5 clientlibs tests continue to pass.

I agree these all look like they should request the array to be freed.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12023


From prr at openjdk.org  Tue Jan 17 19:47:07 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jan 2023 19:47:07 GMT
Subject: RFR: 8299772: The ColorModel.getRGBdefault() method is not
 thread-safe
In-Reply-To: <Ov06tqQrCHkABN9x6zIYIdMjqK0qMEEqlboiSTIdHgw=.729da5c8-e6d5-428a-86af-08e41e84a2c0@github.com>
References: <Ov06tqQrCHkABN9x6zIYIdMjqK0qMEEqlboiSTIdHgw=.729da5c8-e6d5-428a-86af-08e41e84a2c0@github.com>
Message-ID: <U-5Gf0gS0FyYe6ffE5r3vMVOOZubBEYw2qfDa2qhryk=.a489a88f-6a38-4144-affa-9b06881d13fb@github.com>

On Sun, 8 Jan 2023 01:09:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The getRGBdefault() was made thread safe via holder implemented as a local interface.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11895


From prr at openjdk.org  Tue Jan 17 19:47:12 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jan 2023 19:47:12 GMT
Subject: RFR: 8286581: Make Java process DPI Aware if sun.java2d.dpiaware
 property is set [v2]
In-Reply-To: <Rsjp-dYL8GbJjnG-XtxyN7I4GnU9iWCZ9bNGX6K0Pqc=.a4a0034a-9cba-4f9e-955b-cc897c749b93@github.com>
References: <HnbTtI7Q0467OzM1jTs1_yGl4ZZTzIEuQLuyUyseXLY=.ce6942e5-82e6-430b-a094-544a7d0ff76f@github.com>
 <Rsjp-dYL8GbJjnG-XtxyN7I4GnU9iWCZ9bNGX6K0Pqc=.a4a0034a-9cba-4f9e-955b-cc897c749b93@github.com>
Message-ID: <wFjbwHUrnsOYc3-9eWd2447giOmRC5exXC80FFMQceI=.e442446d-82aa-4a88-ad60-f5fe8cbfd88b@github.com>

On Tue, 17 Jan 2023 17:01:48 GMT, Rajat Mahajan <duke at openjdk.org> wrote:

>> I tested by removing dpi-awareness settings from the manifest file, and then running my app with -Dsun.java2d.dpiaware=false. This showed java.exe as "Unaware" in task-manager, and with it set to true I saw "Per-Monitor (v2)" dpi awareness for java.exe.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright year

Can you explain why you think this change is needed if its already set ?
And additionally, you describe what happens with explicit setting of the property (when the manifest is disabled) but don't say which is the default.

-------------

PR: https://git.openjdk.org/jdk/pull/11998


From aivanov at openjdk.org  Tue Jan 17 20:10:34 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Jan 2023 20:10:34 GMT
Subject: RFR: 8286581: Make Java process DPI Aware if sun.java2d.dpiaware
 property is set [v2]
In-Reply-To: <wFjbwHUrnsOYc3-9eWd2447giOmRC5exXC80FFMQceI=.e442446d-82aa-4a88-ad60-f5fe8cbfd88b@github.com>
References: <HnbTtI7Q0467OzM1jTs1_yGl4ZZTzIEuQLuyUyseXLY=.ce6942e5-82e6-430b-a094-544a7d0ff76f@github.com>
 <Rsjp-dYL8GbJjnG-XtxyN7I4GnU9iWCZ9bNGX6K0Pqc=.a4a0034a-9cba-4f9e-955b-cc897c749b93@github.com>
 <wFjbwHUrnsOYc3-9eWd2447giOmRC5exXC80FFMQceI=.e442446d-82aa-4a88-ad60-f5fe8cbfd88b@github.com>
Message-ID: <TzD4zfNVLlzxcZu0yhVQENybi1U6e0yfZpLGi5A77zQ=.5160bbb9-c671-47d2-a07c-2a85f7e28e4b@github.com>

On Tue, 17 Jan 2023 19:43:40 GMT, Phil Race <prr at openjdk.org> wrote:

> Can you explain why you think this change is needed if its already set ?

Initially, I proposed to remove the property and code associated with it because its value isn't respected as the DPI Awareness is set in the manifest.

You [asked](https://bugs.openjdk.org/browse/JDK-8286581?focusedCommentId=14495409&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14495409) about a custom launcher which may not set the DPI Awareness in the manifest.

If the manifest entries are missing, Java calls [`SetProcessDPIAware`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setprocessdpiaware) which sets the process DPI Awareness to **System** (`DPI_AWARENESS_CONTEXT_SYSTEM_AWARE`). That is the UI on the _main screen_ is rendered as expected. Yet if the user changes the scale of the main screen or moves the window to a monitor with different scale, the UI will be auto-scaled by Windows, which means it will be blurry.

Java supports **Per-Monitor v2 DPI Awareness** (`DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2`). This fix addresses the difference and sets the DPI Awareness to the correct one in case if the manifest entries are missing for whatever reason.

> And additionally, you describe what happens with explicit setting of the property (when the manifest is disabled) but don't say which is the default.

The default value is `true` for the standard launcher.

https://github.com/openjdk/jdk/blob/ade08e190cc28cf0ce0194fa3fb67e48dc634e07/src/java.desktop/windows/classes/sun/java2d/windows/WindowsFlags.java#L220-L223

-------------

PR: https://git.openjdk.org/jdk/pull/11998


From darcy at openjdk.org  Tue Jan 17 20:13:58 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 17 Jan 2023 20:13:58 GMT
Subject: RFR: JDK-8300279: Use generalized see and link tags in core libs in
 client libs
Message-ID: <DwR5qnwkwO2zhI7u9gQyPwnrC_4x3mukb7YaJWVPVfo=.30c41101-47eb-4ccd-97ca-1fadf2acccdd@github.com>

Use new javadoc capabilities courtesy JDK-8200337 to use more readable in javadoc source anchors AWT's Shape interface. Analogous change is out for review in core libs, JDK-8300133.

-------------

Commit messages:
 - JDK-8300279: Use generalized see and link tags in core libs in client libs

Changes: https://git.openjdk.org/jdk/pull/12048/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12048&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300279
  Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12048.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12048/head:pull/12048

PR: https://git.openjdk.org/jdk/pull/12048


From prr at openjdk.org  Tue Jan 17 20:47:38 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jan 2023 20:47:38 GMT
Subject: RFR: 8280359: Try to remove duplicate code for coordinate
 calculation
In-Reply-To: <UwqaayGxh98sMkmmpxlYvwatXRmkqZ07HTsdL1P2GHg=.1dcd808f-7c2f-4a58-9290-dc1ff40f02ad@github.com>
References: <UwqaayGxh98sMkmmpxlYvwatXRmkqZ07HTsdL1P2GHg=.1dcd808f-7c2f-4a58-9290-dc1ff40f02ad@github.com>
Message-ID: <LkhftVQ8KhWHo13TLX10RKWYtnjO-48rzOYmJCW65_s=.8cb2507b-7616-466a-babb-9829abd116be@github.com>

On Mon, 12 Dec 2022 01:49:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The code from `AccessibilityGraphicsEnvironment` is moved/merged back to the `SunGraphicsEnvironment` from where it was initially [copied](https://github.com/openjdk/jdk18/pull/72#issuecomment-1001050200). The required API is exported from the `sun.java2d` to the `jdk.accessibility`(on WIndows only).

I don't want to do this.
Minimising such coupling between modules outweighs this code duplication

-------------

Changes requested by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11626


From prr at openjdk.org  Tue Jan 17 20:44:54 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jan 2023 20:44:54 GMT
Subject: RFR: 8299333: Unify exceptions used by all variants of
 ICC_Profile.getInstance(null)
In-Reply-To: <vcJUwGyej8Uk8AQC25VHJib-Tn0MMDATnf8H3JEZygQ=.8212bab6-583d-4e8b-9dce-15a94ef52c39@github.com>
References: <vcJUwGyej8Uk8AQC25VHJib-Tn0MMDATnf8H3JEZygQ=.8212bab6-583d-4e8b-9dce-15a94ef52c39@github.com>
Message-ID: <brPkEe83H9QJohcATccEPf4UEqZk37W-N0ktgcm0bsw=.92a039ff-4ec9-4e9e-87d3-46dc0562ae9f@github.com>

On Fri, 23 Dec 2022 23:32:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I tried to clean up the documentation in the `java.awt.color` package and specify how the `null` parameters are handled here and there. But it looks like the `ICC_profile` class is too specific so I would like to discuss it separately.
> 
> The ICC_Profile has these methods:
>  * `getInstance(int)`      - always throws specified `IllegalArgumentException` on the wrong constant
>  * `getInstance(byte[])` - always throws specified `IllegalArgumentException` on `null`
>  * `getInstance(String fileName)` - always throws unspecified `NullPointerException` on `null`
>  * `getInstance(InputStream)`      - thrown unspecified `NullPointerException` before [JDK-8227816](https://github.com/openjdk/jdk/commit/af20c6b9c4a3a21c1e2c7f56721e1077e7d8f388) and now throws specified but misleading `IOException: Stream closed` exception on `null`
> 
> So we have 3 methods that can get null as a parameter and each throw a different exception.
> 
> Note that all of the specs for the methods above have this part:
> 
>> @throws IllegalArgumentException If the stream does not contain valid ICC Profile data
> 
> So I have an idea to change `getInstance(String)` and `getInstance(InputStream)` to throw `IllegalArgumentException`  even if I personally prefer NPE to be thrown.
> 
> From another point of view the `ICC_Profile` profile has other methods:
>  * `write(String fileName)` - always throws unspecified `NullPointerException` on `null`
>  * `write(OutputStream) `  - always throws unspecified `NullPointerException` on `null`
> 
> I am not sure we can throw `IllegalArgumentException` from the `write` methods, so the specification for `getInstance(String)` and `getInstance(InputStream)` could be updated to throw NPE on null same as related `write`.
> 
> Thoughts?

mrserb wrote 
=====
>From another point of view the ICC_Profile profile has other methods:

write(String fileName) - always throws unspecified NullPointerException on null
write(OutputStream)  - always throws unspecified NullPointerException on null
I am not sure we can throw IllegalArgumentException from the write methods, so the specification for getInstance(String) and getInstance(InputStream) could be updated to throw NPE on null same as related write.
========

Now .. when we take this into consideration,  I'm inclined to look at the get/write ones for fileName and outputstream as pairs and think it might be best to just specify the NPE for ALL cases and forgo the "unification" with the other cases.

Since

-------------

PR: https://git.openjdk.org/jdk/pull/11784


From prr at openjdk.org  Tue Jan 17 20:54:18 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jan 2023 20:54:18 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows [v2]
In-Reply-To: <wwYWYUhyE0sZyy3_conm04PKsFs-LBBvTNn6gvwifiw=.c081b182-e7f5-4eea-a5d2-2cd77770936e@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
 <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
 <jmk5QwhSkR2NWMmalhzRkBJem_zRyAZn4egOHPc7g7k=.62398ce3-cb6a-41f6-8265-2cfe6fa963c3@github.com>
 <jAff87Y1F3KwyapG1gOQbTejQtJG_4hHAiNoO3ItZms=.71eeaac3-fc5e-46f6-849b-47c947503c00@github.com>
 <wwYWYUhyE0sZyy3_conm04PKsFs-LBBvTNn6gvwifiw=.c081b182-e7f5-4eea-a5d2-2cd77770936e@github.com>
Message-ID: <NPe7LWAlejLZmtfxO6JykWYBqEDbvOlsMYhrzr8ZEeA=.0fc10b85-1f0d-4acf-8e1b-a3ef287575e4@github.com>

On Fri, 6 Jan 2023 22:54:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> But I assume we should have a test somewhere that validates that this option is not null = "is not optional"?

Maybe core libs could add such a test.

The link  doesn't work for me  but I expect I'd need to look at each of those cases to understand what they are doing.

It doesn't change that the reason for this proposed change isn't valid.
We probably should remove that debugging property to make it clear.

-------------

PR: https://git.openjdk.org/jdk/pull/11559


From aivanov at openjdk.org  Tue Jan 17 21:13:58 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Jan 2023 21:13:58 GMT
Subject: RFR: JDK-8300279: Use generalized see and link tags in core libs
 in client libs
In-Reply-To: <DwR5qnwkwO2zhI7u9gQyPwnrC_4x3mukb7YaJWVPVfo=.30c41101-47eb-4ccd-97ca-1fadf2acccdd@github.com>
References: <DwR5qnwkwO2zhI7u9gQyPwnrC_4x3mukb7YaJWVPVfo=.30c41101-47eb-4ccd-97ca-1fadf2acccdd@github.com>
Message-ID: <e2ab0FeeykPc3NMW3D6zAr1K5X53tP1jXjl10AC08mc=.17c41919-e5f5-406f-97a6-86fb17ac402d@github.com>

On Tue, 17 Jan 2023 20:06:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use new javadoc capabilities courtesy JDK-8200337 to use more readable in javadoc source anchors AWT's Shape interface. Analogous change is out for review in core libs, JDK-8300133.

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12048


From aivanov at openjdk.org  Tue Jan 17 21:28:31 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Jan 2023 21:28:31 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
Message-ID: <SwHAnckthtEso6NhBKJtIA0U1it3F-O80x5d6bbRlUA=.7d3cda93-4925-405c-992f-1f7dd832e37d@github.com>

On Thu, 22 Dec 2022 05:13:34 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

This PR is superseded by #12010.

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From swinxythecat at gmail.com  Tue Jan 17 21:30:08 2023
From: swinxythecat at gmail.com (SWinxy)
Date: Tue, 17 Jan 2023 16:30:08 -0500
Subject: GraphicsDevice#getAvailableAcceleratedMemory
Message-ID: <CAPRuVTWfFGYKqE3Hk+TZC-CtSr=ujF=iVrk8H6aFC7VLmdGGdw@mail.gmail.com>

Hi all,

getAvailableAcceleratedMemory
<https://docs.oracle.com/en/java/javase/19/docs/api/java.desktop/java/awt/GraphicsDevice.html#getAvailableAcceleratedMemory()>'s
implementation (and lack thereof) is in conflict with the documentation,
making it quite problematic.

Windows is the only OS that has it implemented; macOS and Linux will return
-1. The bigger problem is that the return type is an int, which can't
represent the amount of bytes in modern systems. Representing the amount of
bytes in video memory with a signed 32-bit integer has a cap of 2047MB. My
GPU has 6x that amount.

Windows' impl uses this D3D function
<https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-getavailabletexturemem>,
returning
an *unsigned* 32-bit integer, closest to the actual amount of bytes it can
represent--ending up with a negative number when it's signed. The
documentation says "A negative return value indicates that the amount of
accelerated memory on this GraphicsDevice is indeterminate." Technically
true, but less than helpful.

The documentation for the method is... uh... probably outdated anyway as to
what the method can be used for. So our remedial options are to change the
documentation; implement macOS and Linux; deprecate it; change the return
type; or any combination. (My thoughts are for deprecating.)

What should we do?

-SWinxy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230117/3eef2beb/attachment.htm>

From prr at openjdk.org  Tue Jan 17 22:07:18 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jan 2023 22:07:18 GMT
Subject: RFR: JDK-8300279: Use generalized see and link tags in core libs
 in client libs
In-Reply-To: <DwR5qnwkwO2zhI7u9gQyPwnrC_4x3mukb7YaJWVPVfo=.30c41101-47eb-4ccd-97ca-1fadf2acccdd@github.com>
References: <DwR5qnwkwO2zhI7u9gQyPwnrC_4x3mukb7YaJWVPVfo=.30c41101-47eb-4ccd-97ca-1fadf2acccdd@github.com>
Message-ID: <wOyldKtfncVcLQx49SU51d_HX_hdj9-o-k0AUEKF2jE=.0fdea458-4478-4687-9ea8-1bbd85b5bb27@github.com>

On Tue, 17 Jan 2023 20:06:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use new javadoc capabilities courtesy JDK-8200337 to use more readable in javadoc source anchors AWT's Shape interface. Analogous change is out for review in core libs, JDK-8300133.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12048


From prr at openjdk.org  Tue Jan 17 22:12:26 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jan 2023 22:12:26 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <lKLFw4FVKMO_0woqf516ebwHnavZjjO2tvCAfD1Xm6w=.202160e7-e82f-49c4-8b78-58dbe3476b2d@github.com>
References: <lKLFw4FVKMO_0woqf516ebwHnavZjjO2tvCAfD1Xm6w=.202160e7-e82f-49c4-8b78-58dbe3476b2d@github.com>
Message-ID: <tqFtQsaZcTqWrDKfwQXJ2pz0TEIwLjiqLRfMdycnDDc=.d416cd22-5a0e-4bfb-8f90-7184e9217781@github.com>

On Mon, 16 Jan 2023 14:19:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This is somewhat a continuation of #11104 where the issue was discussed and where I found [the root cause](https://github.com/openjdk/jdk/pull/11104#issuecomment-1382435784).
> 
> **Root Cause**
> 
> The icon extraction code compares the returned handle to zero: 
> https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1157-L1158
> 
> On 64-bit systems, a valid handle can be negative. For example:
> 
> 
> getIcon : Desktop 16(16)
> GetIconLocation(uFlags=0x22, flags=0x4, index=-110) SUCCESS - szBuf=C:\Windows\system32\imageres.dll
> Extract - hres: 0, hIcon=0000000019B200F9, hIconSmall=FFFFFFFFF98C00EB, size=16(0x100020)
> SUCCEEDED
> !!! hIcon(0xfffffffff98c00eb) <= 0 : Desktop 16(16)
> 
> 
> Here in `size=16(0x100020)`, 16 is the requested icon size, the value in parenthesis is value of `iconSize` passed to the [`Extract`](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-iextracticonw-extract) method that contains the size for small icon in high word and that for large icon in low word. `Desktop 16(16)` means the icon of size 16?16 is requested, and we're extracting 16?16 icon.
> 
> The icon was extracted _successfully_ but its handle was interpreted as an error.
> 
> The same problem exists in the fallback code:
> https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1161
> 
> Then when the fallback code is executed, another problem occurs:
> 
> 
> GetIconLocation(uFlags=0x40, flags=0x1a3, index=-675088752) SUCCESS - szBuf=
> Extract - hres: 80004005, hIcon=0000000000000000, hIconSmall=000001A3D7C2F83A, size=16(100020)
> NOT SUCCEEDED
> hIcon = 0x1a3d7c2f83a : Desktop 16(16)
> 
> 
> The error code 0x80004005 is `E_FAIL`. Yet the return value is not verified in the code:
> https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp#L997-L1003
> 
> Since the icon handle is *seemingly* valid, it continues to extracting the icon bits:
> 
> 
> native getIconBits - fn_GetIconInfo returned false
> Error code: 0x57a - Invalid cursor handle.
> makeIcon: iconBits = null
> 
> 
> It's not a surprise. After all, the `Extract` method returned an error, which means neither icon handle is valid.
> 
> In the end, the `MultiResolutionIcon` contains `null`:
> 
> ????16 -> null
> ????32 -> BufferedImage @ 59e735d
> ????24 -> BufferedImage @ 60b2faf0
> 
> 
> This problem has existed for since [JDK-8182043](https://bugs.openjdk.org/browse/JDK-8182043), yet it went unnoticed because `getResolutionVariant` just returned a null. However, after [JDK-8282526](https://bugs.openjdk.org/browse/JDK-8282526) was integrated, the result is used, which leads to `NullPointerException`.
> 
> 
> **The Fix**
> 
> Handle the errors as `hIcon == E_PENDING || hIcon == 0` and `hIcon == 0`. In the fallback code where a default icon is requested, [`E_PENDING` cannot be returned](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-iextracticonw-geticonlocation#remarks), it's valid only if `GIL_ASYNC` flag is used.
> 
> Add `assert` statements to `MultiResolutionIconImage` for null-checks which will help us to catch a similar situation if it occurs.
> 
> **Testing**
> 
> The two errors combined lead to random failures. No particular host reproduced the problem more often.
> 
> While I was testing with the additional traces, sometimes 5 of 10 tests failed, other times only 1 of 10. There were a couple of test runs where no failures occurred.
> 
> With the fix applied, no failures occurred.

Aha !

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12010


From prr at openjdk.org  Tue Jan 17 22:14:35 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jan 2023 22:14:35 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
Message-ID: <zMcVSQm6D0YotjoJw_36jfH13JgOk57NEZR1nlmWFu0=.d6ff2198-7591-449e-abca-305571068503@github.com>

On Thu, 22 Dec 2022 05:13:34 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

This PR should be withdrawn

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From achung at openjdk.org  Tue Jan 17 22:15:38 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jan 2023 22:15:38 GMT
Subject: RFR: 8282217: Key events (key char and key code) changed for Swiss
 keyboard
In-Reply-To: <N9XfS6cL8s1G98UAiEr7ZvgzQB-HX6qKGptKZe7d810=.1f5932c5-fd00-4fe8-9c0b-99f2fa71d880@github.com>
References: <N9XfS6cL8s1G98UAiEr7ZvgzQB-HX6qKGptKZe7d810=.1f5932c5-fd00-4fe8-9c0b-99f2fa71d880@github.com>
Message-ID: <pg-1LqPavN0WWbaTYwptbxmyn199RUMdD0wA-Sj1M0A=.4d6db8a0-f925-4be5-8770-5e248fcfb61f@github.com>

On Fri, 6 Jan 2023 22:07:33 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removed check for MapVirtualKeyEx return value causing some keys to become undefined

My (US QWERTY) keyboard doesn't have a key between the Z and L shift keys, so I used the on screen keyboard in German. I typed the OEM 102 key and C x2 and I got >cc both before and after the change. Is there a way I can replicate the OEM 102 key and the test failure without the key on a physical keyboard?

-------------

PR: https://git.openjdk.org/jdk/pull/11887


From prr at openjdk.org  Tue Jan 17 22:20:58 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jan 2023 22:20:58 GMT
Subject: RFR: 8297191: [macos] printing page range "page 2 to 2" or
 "page 2 to 4" on macOS leads to not print
In-Reply-To: <ez2nIrw-TV-NYnzwJCLxnr-PdUYhf_AZm2MiMHiF9hI=.4bc5d42a-0b5a-4e42-a4be-fa66f2b8af2d@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
 <ez2nIrw-TV-NYnzwJCLxnr-PdUYhf_AZm2MiMHiF9hI=.4bc5d42a-0b5a-4e42-a4be-fa66f2b8af2d@github.com>
Message-ID: <bvZKOAWXAUhY3TfbbczlGN3qftulPzgZNmuxovdTSgo=.6c808b39-9ec6-404e-a0b0-ad88755c008d@github.com>

On Thu, 29 Dec 2022 09:36:32 GMT, Tibor Malanik <duke at openjdk.org> wrote:

> The problem is noticeable when setPageable on java.awt.print.PrinterJob is used

So why is the Test.java in the bugreport not using it ? And yet claiming it shows the problem >
And can we have a test with this fix, even if it is manual, so I can run it BEFORE and AFTER the  fix to verify it.

Perhaps you can identify an existing failing test that you can reference ?

-------------

PR: https://git.openjdk.org/jdk/pull/11266


From darcy at openjdk.org  Tue Jan 17 22:21:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 17 Jan 2023 22:21:05 GMT
Subject: Integrated: JDK-8300279: Use generalized see and link tags in core
 libs in client libs
In-Reply-To: <DwR5qnwkwO2zhI7u9gQyPwnrC_4x3mukb7YaJWVPVfo=.30c41101-47eb-4ccd-97ca-1fadf2acccdd@github.com>
References: <DwR5qnwkwO2zhI7u9gQyPwnrC_4x3mukb7YaJWVPVfo=.30c41101-47eb-4ccd-97ca-1fadf2acccdd@github.com>
Message-ID: <0RIfVZmF5ERhJomf1lRCheFGzC_Any0rUlLoLUKhEG4=.cd5883b4-d698-4509-9074-92479c535b14@github.com>

On Tue, 17 Jan 2023 20:06:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use new javadoc capabilities courtesy JDK-8200337 to use more readable in javadoc source anchors AWT's Shape interface. Analogous change is out for review in core libs, JDK-8300133.

This pull request has now been integrated.

Changeset: f9883fc4
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f9883fc45b3bf5fc6e104491d24f7303802f8dbd
Stats:     7 lines in 1 file changed: 0 ins; 1 del; 6 mod

8300279: Use generalized see and link tags in core libs in client libs

Reviewed-by: aivanov, prr

-------------

PR: https://git.openjdk.org/jdk/pull/12048


From jiefu at openjdk.org  Tue Jan 17 23:56:32 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 17 Jan 2023 23:56:32 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <0NMWnUwU-YKzQ9V5AtT03yxs2OQQ6GnbrqLfi989mkg=.34ce9025-a67a-40fd-b27c-fa5aee2795be@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the fix for the build failure with clang-15.
> 
> 1. -Wbitwise-instead-of-logical
> 
>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
> 
> 
> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
> 
>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
> 
>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
> 
>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
> 
> 
> 3. -Wdeprecated-builtins
> 
>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
> 
>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
> 
> 4. -Wgnu-folding-constant
> 
>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
> 
> 
> Thanks.
> Best regards,
> Jie

> _Mailing list message from [Patrick Chen](mailto:chen.j.patrick at gmail.com) on [build-dev](mailto:build-dev at mail.openjdk.org):_
> 
> no you have to revert the commit

Why?
Is there anything wrong?
Thanks.

> 
> Le mar. 17 janv. 2023 ? 17:55, Alan Bateman <alanb at openjdk.org> a ?crit :
> 
> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230117/4dc50b9b/attachment.htm>

-------------

PR: https://git.openjdk.org/jdk/pull/12005


From jiefu at openjdk.org  Tue Jan 17 23:56:34 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 17 Jan 2023 23:56:34 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <4D6-l2p6z4lIpe84jpo-YMcnf1dUfmzrdF3C_KV1EgY=.ddd7f85b-58c5-451c-af94-aaae35f114bc@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <4D6-l2p6z4lIpe84jpo-YMcnf1dUfmzrdF3C_KV1EgY=.ddd7f85b-58c5-451c-af94-aaae35f114bc@github.com>
Message-ID: <zNOhExpbkk_FGIAYNpmeyWJQi1mEtza3Zs1rilB6bU4=.57a554af-c017-49f9-9c48-0a9b0c57a431@github.com>

On Tue, 17 Jan 2023 18:12:44 GMT, Phil Race <prr at openjdk.org> wrote:

> client changes are OK by me.

Thanks @prrace .

-------------

PR: https://git.openjdk.org/jdk/pull/12005


From tr at openjdk.org  Wed Jan 18 04:56:40 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 18 Jan 2023 04:56:40 GMT
Subject: Withdrawn: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
Message-ID: <tkuXzznYmNPyAindvaXe0Ywb89_oTZDe7lFezyzuggs=.e80a49ea-4707-485e-87fa-d5519da998ec@github.com>

On Fri, 11 Nov 2022 08:18:19 GMT, Tejesh R <tr at openjdk.org> wrote:

> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From tr at openjdk.org  Wed Jan 18 06:45:13 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 18 Jan 2023 06:45:13 GMT
Subject: RFR: 8300405: Screen capture for test
 JFileChooserSetLocationTest.java, failure case
Message-ID: <H9i4szvE-s7cWX1cu8bkx6nLa3yvB44bftLmYbbfhvM=.a5ae761a-cfe3-4a71-80b2-88bbb6ae7858@github.com>

This is a diagnostic update related to [JDK-8295804](https://bugs.openjdk.org/browse/JDK-8295804). The issue was not reproducible and was showing up in particular machines (Where the machines are down now). So adding a screen capture to `BufferedImage` in case of failure so that it will help in analysis when the issue comes up in future.

-------------

Commit messages:
 - Diagnostic approach

Changes: https://git.openjdk.org/jdk/pull/12060/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12060&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300405
  Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12060.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12060/head:pull/12060

PR: https://git.openjdk.org/jdk/pull/12060


From alanb at openjdk.org  Wed Jan 18 07:24:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jan 2023 07:24:19 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows [v2]
In-Reply-To: <NPe7LWAlejLZmtfxO6JykWYBqEDbvOlsMYhrzr8ZEeA=.0fc10b85-1f0d-4acf-8e1b-a3ef287575e4@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
 <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
 <jmk5QwhSkR2NWMmalhzRkBJem_zRyAZn4egOHPc7g7k=.62398ce3-cb6a-41f6-8265-2cfe6fa963c3@github.com>
 <jAff87Y1F3KwyapG1gOQbTejQtJG_4hHAiNoO3ItZms=.71eeaac3-fc5e-46f6-849b-47c947503c00@github.com>
 <wwYWYUhyE0sZyy3_conm04PKsFs-LBBvTNn6gvwifiw=.c081b182-e7f5-4eea-a5d2-2cd77770936e@github.com>
 <NPe7LWAlejLZmtfxO6JykWYBqEDbvOlsMYhrzr8ZEeA=.0fc10b85-1f0d-4acf-8e1b-a3ef287575e4@github.com>
Message-ID: <pGXeOnyRyojvizMZB2N4Rx3mkNd7eyDdyih4cFIFDHQ=.89022386-4ca4-4ea3-a52f-01b812b65b63@github.com>

On Tue, 17 Jan 2023 20:51:36 GMT, Phil Race <prr at openjdk.org> wrote:

> Maybe core libs could add such a test.

It is tested by conformance tests but a test could be added to the OpenJDK jtreg tests if needed.

-------------

PR: https://git.openjdk.org/jdk/pull/11559


From tr at openjdk.org  Wed Jan 18 07:31:25 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 18 Jan 2023 07:31:25 GMT
Subject: RFR: 8300405: Screen capture for test
 JFileChooserSetLocationTest.java, failure case
In-Reply-To: <FyIXOWMhnHH0QDi6IfnVaGt0PpykTqcrXMpqCKHMiWQ=.79e524a3-edb1-49f1-b2a5-58f5d67f03fd@github.com>
References: <H9i4szvE-s7cWX1cu8bkx6nLa3yvB44bftLmYbbfhvM=.a5ae761a-cfe3-4a71-80b2-88bbb6ae7858@github.com>
 <FyIXOWMhnHH0QDi6IfnVaGt0PpykTqcrXMpqCKHMiWQ=.79e524a3-edb1-49f1-b2a5-58f5d67f03fd@github.com>
Message-ID: <agw-EQI8ao0aes0hP-3e3AXc0Rr696R0kK48fdUpSm4=.11b195d6-e521-4b6d-adf5-270238f4b1d7@github.com>

On Wed, 18 Jan 2023 07:06:26 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> In [JDK-8295804](https://bugs.openjdk.org/browse/JDK-8295804), it is mentioned that failure was observed in macOS 13 also. Did you try to reproduce the issue in macOS 13?

Not yet, since any particular host is not mentioned in JBS I will try in random host with 13.0.

-------------

PR: https://git.openjdk.org/jdk/pull/12060


From mvs at openjdk.org  Wed Jan 18 07:48:29 2023
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 18 Jan 2023 07:48:29 GMT
Subject: RFR: 8300409: Create an automated regression test for JComboBox titled
 border issues(JDK-8300269)
Message-ID: <pixfugLjVG8x0l_8hOAv-TuJSl9RGp5Rc6c7_ungvcs=.bc2069ce-026a-4bd6-980b-77cafd00bb44@github.com>

Create a automated regression test for JComboBox titled border issues([JDK-8300269](https://bugs.openjdk.org/browse/JDK-8300269)).

This test passes in JDK-20-ea+16 and fails in JDK-20-ea+16 and above.

-------------

Commit messages:
 - 8300409: Create an automated regression test for JComboBox titled border issues(JDK-8300269)

Changes: https://git.openjdk.org/jdk/pull/12061/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12061&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300409
  Stats: 176 lines in 1 file changed: 176 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12061.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12061/head:pull/12061

PR: https://git.openjdk.org/jdk/pull/12061


From abhiscxk at openjdk.org  Wed Jan 18 07:09:20 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 18 Jan 2023 07:09:20 GMT
Subject: RFR: 8300405: Screen capture for test
 JFileChooserSetLocationTest.java, failure case
In-Reply-To: <H9i4szvE-s7cWX1cu8bkx6nLa3yvB44bftLmYbbfhvM=.a5ae761a-cfe3-4a71-80b2-88bbb6ae7858@github.com>
References: <H9i4szvE-s7cWX1cu8bkx6nLa3yvB44bftLmYbbfhvM=.a5ae761a-cfe3-4a71-80b2-88bbb6ae7858@github.com>
Message-ID: <FyIXOWMhnHH0QDi6IfnVaGt0PpykTqcrXMpqCKHMiWQ=.79e524a3-edb1-49f1-b2a5-58f5d67f03fd@github.com>

On Wed, 18 Jan 2023 06:37:30 GMT, Tejesh R <tr at openjdk.org> wrote:

> This is a diagnostic update related to [JDK-8295804](https://bugs.openjdk.org/browse/JDK-8295804). The issue was not reproducible and was showing up in particular machines (Where the machines are down now). So adding a screen capture to `BufferedImage` in case of failure so that it will help in analysis when the issue comes up in future.

In [JDK-8295804](https://bugs.openjdk.org/browse/JDK-8295804), it is mentioned that failure was observed in macOS 13 also.
Did you try to reproduce the issue in macOS 13?

-------------

PR: https://git.openjdk.org/jdk/pull/12060


From djelinski at openjdk.org  Wed Jan 18 09:32:32 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 18 Jan 2023 09:32:32 GMT
Subject: Integrated: 8300117: Replace use of JNI_COMMIT mode with mode 0
In-Reply-To: <C_4vnxyyv4sLzIO2iCE8CfHI57jWmTbrZUKI0A-gkBQ=.753494dd-fbcb-4092-9878-06ac4d1301c0@github.com>
References: <C_4vnxyyv4sLzIO2iCE8CfHI57jWmTbrZUKI0A-gkBQ=.753494dd-fbcb-4092-9878-06ac4d1301c0@github.com>
Message-ID: <mV6IFiU6Xof-veEWTSy7CkSa91E9lyBGElMUWoQsHjI=.dfb1cce5-b426-4160-b24a-1f684b9ccf6f@github.com>

On Tue, 17 Jan 2023 07:43:41 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that fixes memory leaks in native code.
> 
> The call to `ReleaseXXArrayElements` with `JNI_COMMIT` parameter does not release the native buffer allocated by the previous `GetXXArrayElements` call. The buffer pointers were only stored in local variables and were lost on function exit.
> 
> No new regression test; existing tests under `java/awt/dnd` and `java/awt/datatransfer` cover all 3 modified functions.
> 
> Mach5 clientlibs tests continue to pass.

This pull request has now been integrated.

Changeset: 7c8b99ee
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7c8b99eedb46890c06af3b8e698b3ba169475231
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8300117: Replace use of JNI_COMMIT mode with mode 0

Reviewed-by: serb, prr

-------------

PR: https://git.openjdk.org/jdk/pull/12023


From aivanov at openjdk.org  Wed Jan 18 10:05:34 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jan 2023 10:05:34 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v12]
In-Reply-To: <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
Message-ID: <Pg3Iz33l7lyZ6EZVQ34JDtM55-31TxZB-RruEvxu_Bo=.74830bd5-2f2d-4101-9ca1-aabaaccefb39@github.com>

On Tue, 17 Jan 2023 05:37:38 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports

The test fails for me on macOS:


Caused by: java.lang.RuntimeException: Approve button tooptip is null in FileChooser!
        at CustomApproveButtonTest.<init>(CustomApproveButtonTest.java:78)
        at CustomApproveButtonTest$1.run(CustomApproveButtonTest.java:48)


I merged master into your PR branch to get the fix for [JDK-8300084](https://bugs.openjdk.org/browse/JDK-8300084) and re-built JDK before running the test.

-------------

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11901


From tr at openjdk.org  Wed Jan 18 10:13:32 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 18 Jan 2023 10:13:32 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v12]
In-Reply-To: <Pg3Iz33l7lyZ6EZVQ34JDtM55-31TxZB-RruEvxu_Bo=.74830bd5-2f2d-4101-9ca1-aabaaccefb39@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
 <Pg3Iz33l7lyZ6EZVQ34JDtM55-31TxZB-RruEvxu_Bo=.74830bd5-2f2d-4101-9ca1-aabaaccefb39@github.com>
Message-ID: <j2MkhXpGdA7iS36lFNXEvgGHnG3fdUmbwWCq_orL8bU=.9929e63e-2cab-4829-98c5-30d9822d7ecf@github.com>

On Wed, 18 Jan 2023 10:02:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test fails for me on macOS:
> 
> ```
> Caused by: java.lang.RuntimeException: Approve button tooptip is null in FileChooser!
>         at CustomApproveButtonTest.<init>(CustomApproveButtonTest.java:78)
>         at CustomApproveButtonTest$1.run(CustomApproveButtonTest.java:48)
> ```
> 
> I merged master into your PR branch to get the fix for [JDK-8300084](https://bugs.openjdk.org/browse/JDK-8300084) and re-built JDK before running the test.

In your local setup?

-------------

PR: https://git.openjdk.org/jdk/pull/11901


From tr at openjdk.org  Wed Jan 18 10:20:36 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 18 Jan 2023 10:20:36 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v12]
In-Reply-To: <j2MkhXpGdA7iS36lFNXEvgGHnG3fdUmbwWCq_orL8bU=.9929e63e-2cab-4829-98c5-30d9822d7ecf@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
 <Pg3Iz33l7lyZ6EZVQ34JDtM55-31TxZB-RruEvxu_Bo=.74830bd5-2f2d-4101-9ca1-aabaaccefb39@github.com>
 <j2MkhXpGdA7iS36lFNXEvgGHnG3fdUmbwWCq_orL8bU=.9929e63e-2cab-4829-98c5-30d9822d7ecf@github.com>
Message-ID: <g8Fy85DZEwnUUepoUtSMZYc1nrP0yN0i5Z-_RcQo_-s=.d5924396-cdef-406c-a60c-8dd63c93cad8@github.com>

On Wed, 18 Jan 2023 10:10:33 GMT, Tejesh R <tr at openjdk.org> wrote:

> > The test fails for me on macOS:
> > ```
> > Caused by: java.lang.RuntimeException: Approve button tooptip is null in FileChooser!
> >         at CustomApproveButtonTest.<init>(CustomApproveButtonTest.java:78)
> >         at CustomApproveButtonTest$1.run(CustomApproveButtonTest.java:48)
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I merged master into your PR branch to get the fix for [JDK-8300084](https://bugs.openjdk.org/browse/JDK-8300084) and re-built JDK before running the test.
> 
> In your local setup?
The fallback tooltip for approve button is null for aqua, we have to skip checking tooltip for aqua?

-------------

PR: https://git.openjdk.org/jdk/pull/11901


From tr at openjdk.org  Wed Jan 18 10:30:29 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 18 Jan 2023 10:30:29 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v12]
In-Reply-To: <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
Message-ID: <X3UsLkGPcF4NzCH0IFWA7C2E9N_35Abxz6t_dosM6Zo=.25afe397-54a2-47ec-a412-d4e3ca8610e3@github.com>

On Tue, 17 Jan 2023 05:37:38 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports

I will check both tooltip and mnemonic validation and update the PR.

-------------

PR: https://git.openjdk.org/jdk/pull/11901


From aivanov at openjdk.org  Wed Jan 18 10:34:29 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jan 2023 10:34:29 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v12]
In-Reply-To: <g8Fy85DZEwnUUepoUtSMZYc1nrP0yN0i5Z-_RcQo_-s=.d5924396-cdef-406c-a60c-8dd63c93cad8@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
 <Pg3Iz33l7lyZ6EZVQ34JDtM55-31TxZB-RruEvxu_Bo=.74830bd5-2f2d-4101-9ca1-aabaaccefb39@github.com>
 <j2MkhXpGdA7iS36lFNXEvgGHnG3fdUmbwWCq_orL8bU=.9929e63e-2cab-4829-98c5-30d9822d7ecf@github.com>
 <g8Fy85DZEwnUUepoUtSMZYc1nrP0yN0i5Z-_RcQo_-s=.d5924396-cdef-406c-a60c-8dd63c93cad8@github.com>
Message-ID: <GWdrngFyd9R9IM5YI9d12rLQs9mvCw-flaASIsaczXE=.c8966381-5b06-44c9-a406-22b7b9ffd150@github.com>

On Wed, 18 Jan 2023 10:18:05 GMT, Tejesh R <tr at openjdk.org> wrote:

> > > The test fails for me on macOS:
> > > ```
> > > Caused by: java.lang.RuntimeException: Approve button tooptip is null in FileChooser!
> > >         at CustomApproveButtonTest.<init>(CustomApproveButtonTest.java:78)
> > >         at CustomApproveButtonTest$1.run(CustomApproveButtonTest.java:48)
> > > ```
> > > 
> > > I merged master into your PR branch to get the fix for [JDK-8300084](https://bugs.openjdk.org/browse/JDK-8300084) and re-built JDK before running the test.
> > 
> > In your local setup?

Yes, in my local setup. I'm pretty sure it'll fail on mach5 too.

> > The fallback tooltip for approve button is null for aqua, we have to skip checking tooltip for aqua?

Should it rather be set to a non-null value?

Personally, I think the tooltip for the Approve button isn't needed as its purpose is obvious. However, the tooltip is added in all the L&F, so in custom case there should also be the tooltip.

-------------

PR: https://git.openjdk.org/jdk/pull/11901


From jiefu at openjdk.org  Wed Jan 18 10:35:30 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 18 Jan 2023 10:35:30 GMT
Subject: Integrated: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <bugPTQ5OV19Y9BPwcQJhkew1O3geVLxaKlsLGhG5hyc=.5e597842-eb82-471e-9c38-4894990fa04a@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the fix for the build failure with clang-15.
> 
> 1. -Wbitwise-instead-of-logical
> 
>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
> 
> 
> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
> 
>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
> 
>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
> 
>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
> 
> 
> 3. -Wdeprecated-builtins
> 
>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
> 
>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
> 
> 4. -Wgnu-folding-constant
> 
>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
> 
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: 15a9186d
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/15a9186db251f4be7a13e173842ac1bd858f984d
Stats:     15 lines in 6 files changed: 5 ins; 0 del; 10 mod

8300169: Build failure with clang-15

Reviewed-by: dholmes, prr

-------------

PR: https://git.openjdk.org/jdk/pull/12005


From jwaters at openjdk.org  Wed Jan 18 10:56:49 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 18 Jan 2023 10:56:49 GMT
Subject: RFR: 8300488: Incorrect usage of CATCH_BAD_ALLOC as a macro call
Message-ID: <JkeC-v1VztsqE9jFvIkup27o6Mv1BQfQmvkVaXgYQSM=.37564ba7-3abc-485c-9d27-c771777eedfa@github.com>

`CATCH_BAD_ALLOC` is a regular macro that does not take any parameters, awt_TrayIcon should not use it as a macro function as such

-------------

Commit messages:
 - Remove NULL argument from CATCH_BAD_ALLOC

Changes: https://git.openjdk.org/jdk/pull/12067/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12067&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300488
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12067.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12067/head:pull/12067

PR: https://git.openjdk.org/jdk/pull/12067


From jwaters at openjdk.org  Wed Jan 18 11:25:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 18 Jan 2023 11:25:18 GMT
Subject: RFR: 8300488: Incorrect usage of CATCH_BAD_ALLOC as a macro call
In-Reply-To: <JkeC-v1VztsqE9jFvIkup27o6Mv1BQfQmvkVaXgYQSM=.37564ba7-3abc-485c-9d27-c771777eedfa@github.com>
References: <JkeC-v1VztsqE9jFvIkup27o6Mv1BQfQmvkVaXgYQSM=.37564ba7-3abc-485c-9d27-c771777eedfa@github.com>
Message-ID: <Kb0-5oev3d_Ly6_BqRPaWMlf7SE0SoF6XUO091Oyl8k=.343b3b5b-a2d9-4270-93cc-ec5699237b18@github.com>

On Wed, 18 Jan 2023 10:48:58 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> `CATCH_BAD_ALLOC` is a regular macro that does not take any parameters, awt_TrayIcon should not use it as a macro function as such

@prrace Sorry for the direct page, but it's a small change so I figured why not

-------------

PR: https://git.openjdk.org/jdk/pull/12067


From aivanov at openjdk.org  Wed Jan 18 12:58:25 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jan 2023 12:58:25 GMT
Subject: RFR: 8300488: Incorrect usage of CATCH_BAD_ALLOC as a macro call
In-Reply-To: <JkeC-v1VztsqE9jFvIkup27o6Mv1BQfQmvkVaXgYQSM=.37564ba7-3abc-485c-9d27-c771777eedfa@github.com>
References: <JkeC-v1VztsqE9jFvIkup27o6Mv1BQfQmvkVaXgYQSM=.37564ba7-3abc-485c-9d27-c771777eedfa@github.com>
Message-ID: <qnCGeOYq_8suq91Uld07xcI7MGmc0AaObcbySZQzuMU=.e9255673-0a6b-4b65-b4f1-6b55b70e30ef@github.com>

On Wed, 18 Jan 2023 10:48:58 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> `CATCH_BAD_ALLOC` is a regular macro that does not take any parameters, awt_TrayIcon should not use it as a macro function as such

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12067


From aivanov at openjdk.org  Wed Jan 18 13:05:35 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jan 2023 13:05:35 GMT
Subject: RFR: 8267582: BasicLookAndFeel should not call
 getComponentPopupMenu twice to get a popup menu [v2]
In-Reply-To: <g0aiOQAweZl1UFOF7dFLvfwf55zKXlSB6_rPQGyNbCg=.ded372f1-22c9-4400-b143-f2ee2082d9f2@github.com>
References: <rVW2gyOA88cdon5y0Mjiv8DlIMzX9khi3u2k1Nm2m5Y=.622ae3fb-8a75-4d93-8ebe-9e1403b856e1@github.com>
 <g0aiOQAweZl1UFOF7dFLvfwf55zKXlSB6_rPQGyNbCg=.ded372f1-22c9-4400-b143-f2ee2082d9f2@github.com>
Message-ID: <qfrStUbEdw7027TwZzoJu30cMZQhcaHhnA4lK1hIHGo=.703f18cf-9598-455c-a9cd-7b8ffd62e605@github.com>

On Tue, 17 Jan 2023 16:50:51 GMT, SWinxy <duke at openjdk.org> wrote:

>> Please review this small change to cache a component's popup menu in BLAF.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Single-class imports

Please change your IDE settings to arrange imports in the following order:


import java.*;

import javax.*;

import com.*; // Other packages


In JDK code, its packages are a priority whereas `sun.*`, `com.*` and others are internal packages.

-------------

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12017


From jwaters at openjdk.org  Wed Jan 18 13:11:50 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 18 Jan 2023 13:11:50 GMT
Subject: RFR: 8300488: Incorrect usage of CATCH_BAD_ALLOC as a macro call
In-Reply-To: <JkeC-v1VztsqE9jFvIkup27o6Mv1BQfQmvkVaXgYQSM=.37564ba7-3abc-485c-9d27-c771777eedfa@github.com>
References: <JkeC-v1VztsqE9jFvIkup27o6Mv1BQfQmvkVaXgYQSM=.37564ba7-3abc-485c-9d27-c771777eedfa@github.com>
Message-ID: <LyUvG_KZZ46p-jIqULsaHPCET1FcBtWETGgApxm_yWQ=.b1c305af-4f11-44a6-b5ba-e516b4bacd69@github.com>

On Wed, 18 Jan 2023 10:48:58 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> `CATCH_BAD_ALLOC` is a regular macro that does not take any parameters, awt_TrayIcon should not use it as a macro function as such

Thanks for the review! :) (Also sorry Phil seems like I tagged you for no reason)

-------------

PR: https://git.openjdk.org/jdk/pull/12067


From jwaters at openjdk.org  Wed Jan 18 13:15:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 18 Jan 2023 13:15:18 GMT
Subject: Integrated: 8300488: Incorrect usage of CATCH_BAD_ALLOC as a macro
 call
In-Reply-To: <JkeC-v1VztsqE9jFvIkup27o6Mv1BQfQmvkVaXgYQSM=.37564ba7-3abc-485c-9d27-c771777eedfa@github.com>
References: <JkeC-v1VztsqE9jFvIkup27o6Mv1BQfQmvkVaXgYQSM=.37564ba7-3abc-485c-9d27-c771777eedfa@github.com>
Message-ID: <9i-JpQyPIAlmUoJM_77Z2URVe2aAf_Lc-CwmznUcjmI=.d631b463-ca7a-4bf6-b8e6-04ffd7e29562@github.com>

On Wed, 18 Jan 2023 10:48:58 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> `CATCH_BAD_ALLOC` is a regular macro that does not take any parameters, awt_TrayIcon should not use it as a macro function as such

This pull request has now been integrated.

Changeset: 1aded82e
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1aded82e546869f80b0464e92de137cc42db2658
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8300488: Incorrect usage of CATCH_BAD_ALLOC as a macro call

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/12067


From aturbanov at openjdk.org  Wed Jan 18 13:28:01 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 18 Jan 2023 13:28:01 GMT
Subject: Integrated: 8300166: Unused array allocation in
 ProcessPath.doProcessPath
In-Reply-To: <_UJnizZOuCPw1KX0NA1zhrjfQp0nL73NOXlSkNz-VxQ=.4d89f2c5-87b0-46dd-9aeb-1c19e1636a29@github.com>
References: <_UJnizZOuCPw1KX0NA1zhrjfQp0nL73NOXlSkNz-VxQ=.4d89f2c5-87b0-46dd-9aeb-1c19e1636a29@github.com>
Message-ID: <Q48c5PrQlJdYGrEOPGGy9khnD5QZ4UJ0OCtDfETM5Ds=.3b3578a5-2c8c-49b9-b6e8-dcad45d72d7b@github.com>

On Sat, 7 Jan 2023 19:29:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> I don't see this array in `src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c` too. Seems leftovers from refactoring?

This pull request has now been integrated.

Changeset: 85d8bacb
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85d8bacb0ff4015941db53305e6a0d5d28391e1f
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8300166: Unused array allocation in ProcessPath.doProcessPath

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/11894


From duke at openjdk.org  Wed Jan 18 14:51:23 2023
From: duke at openjdk.org (Nikita Provotorov)
Date: Wed, 18 Jan 2023 14:51:23 GMT
Subject: RFR: 8282217: Key events (key char and key code) changed for Swiss
 keyboard
In-Reply-To: <pg-1LqPavN0WWbaTYwptbxmyn199RUMdD0wA-Sj1M0A=.4d6db8a0-f925-4be5-8770-5e248fcfb61f@github.com>
References: <N9XfS6cL8s1G98UAiEr7ZvgzQB-HX6qKGptKZe7d810=.1f5932c5-fd00-4fe8-9c0b-99f2fa71d880@github.com>
 <pg-1LqPavN0WWbaTYwptbxmyn199RUMdD0wA-Sj1M0A=.4d6db8a0-f925-4be5-8770-5e248fcfb61f@github.com>
Message-ID: <Kda96TzF9dZmqfyc-QxDyNI7JfxkFYMBOMQ8oC4LnX0=.4af8734e-9828-4641-8843-dcfd6619a7f2@github.com>

On Tue, 17 Jan 2023 22:13:18 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Removed check for MapVirtualKeyEx return value causing some keys to become undefined
>
> My (US QWERTY) keyboard doesn't have a key between the Z and L shift keys, so I used the on screen keyboard in German. I typed the OEM 102 key and C x2 and I got >cc both before and after the change. Is there a way I can replicate the OEM 102 key and the test failure without the key on a physical keyboard?

@alisenchung unfortunately I don't have any suggestions, except try to use the ``` ~` ``` key (which is immediately to the left of `1` key) instead of the key between Z and LShift. Maybe it'll work

-------------

PR: https://git.openjdk.org/jdk/pull/11887


From tr at openjdk.org  Wed Jan 18 14:57:15 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 18 Jan 2023 14:57:15 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v12]
In-Reply-To: <GWdrngFyd9R9IM5YI9d12rLQs9mvCw-flaASIsaczXE=.c8966381-5b06-44c9-a406-22b7b9ffd150@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
 <Pg3Iz33l7lyZ6EZVQ34JDtM55-31TxZB-RruEvxu_Bo=.74830bd5-2f2d-4101-9ca1-aabaaccefb39@github.com>
 <j2MkhXpGdA7iS36lFNXEvgGHnG3fdUmbwWCq_orL8bU=.9929e63e-2cab-4829-98c5-30d9822d7ecf@github.com>
 <g8Fy85DZEwnUUepoUtSMZYc1nrP0yN0i5Z-_RcQo_-s=.d5924396-cdef-406c-a60c-8dd63c93cad8@github.com>
 <GWdrngFyd9R9IM5YI9d12rLQs9mvCw-flaASIsaczXE=.c8966381-5b06-44c9-a406-22b7b9ffd150@github.com>
Message-ID: <xc5jSzIn-jTFOO7m-7B89BNlb4bZaePWInCwMN10Vao=.adc658f0-c59f-47d0-acee-3a86312ca1ec@github.com>

On Wed, 18 Jan 2023 10:31:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > > The test fails for me on macOS:
> > > > ```
> > > > Caused by: java.lang.RuntimeException: Approve button tooptip is null in FileChooser!
> > > >         at CustomApproveButtonTest.<init>(CustomApproveButtonTest.java:78)
> > > >         at CustomApproveButtonTest$1.run(CustomApproveButtonTest.java:48)
> > > > ```
> > > > 
> > > > 
> > > >     
> > > >       
> > > >     
> > > > 
> > > >       
> > > >     
> > > > 
> > > >     
> > > >   
> > > > I merged master into your PR branch to get the fix for [JDK-8300084](https://bugs.openjdk.org/browse/JDK-8300084) and re-built JDK before running the test.
> > > 
> > > 
> > > In your local setup?
> 
> Yes, in my local setup. I'm pretty sure it'll fail on mach5 too.
> 
> > > The fallback tooltip for approve button is null for aqua, we have to skip checking tooltip for aqua?
> 
> Should it rather be set to a non-null value?
> 
> Personally, I think the tooltip for the Approve button isn't needed as its purpose is obvious. However, the tooltip is added in all the L&F, so in custom case there should also be the tooltip.

Yeah, but the fallback tooltip text for aqua L&F is set to null.

-------------

PR: https://git.openjdk.org/jdk/pull/11901


From duke at openjdk.org  Wed Jan 18 15:21:34 2023
From: duke at openjdk.org (SWinxy)
Date: Wed, 18 Jan 2023 15:21:34 GMT
Subject: RFR: 8267582: BasicLookAndFeel should not call
 getComponentPopupMenu twice to get a popup menu [v3]
In-Reply-To: <rVW2gyOA88cdon5y0Mjiv8DlIMzX9khi3u2k1Nm2m5Y=.622ae3fb-8a75-4d93-8ebe-9e1403b856e1@github.com>
References: <rVW2gyOA88cdon5y0Mjiv8DlIMzX9khi3u2k1Nm2m5Y=.622ae3fb-8a75-4d93-8ebe-9e1403b856e1@github.com>
Message-ID: <B9zQWhP3Z5z3pYOXHCNMtmkGtJto8Nu_VMqbeRv9XfY=.ccc76c42-0cab-4261-928a-81aa7df74d1f@github.com>

> Please review this small change to cache a component's popup menu in BLAF.

SWinxy has updated the pull request incrementally with one additional commit since the last revision:

  order imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12017/files
  - new: https://git.openjdk.org/jdk/pull/12017/files/37746f07..0abf6066

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12017&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12017&range=01-02

  Stats: 48 lines in 1 file changed: 19 ins; 18 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12017/head:pull/12017

PR: https://git.openjdk.org/jdk/pull/12017


From serb at openjdk.org  Wed Jan 18 15:31:55 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 18 Jan 2023 15:31:55 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <lKLFw4FVKMO_0woqf516ebwHnavZjjO2tvCAfD1Xm6w=.202160e7-e82f-49c4-8b78-58dbe3476b2d@github.com>
References: <lKLFw4FVKMO_0woqf516ebwHnavZjjO2tvCAfD1Xm6w=.202160e7-e82f-49c4-8b78-58dbe3476b2d@github.com>
Message-ID: <In15t1jl4hum51ZMGe0X32fmt-NxmRTSREvjN6aVX5g=.381038d0-7e41-47b1-a91b-573839c5dd0c@github.com>

On Mon, 16 Jan 2023 14:19:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This is somewhat a continuation of #11104 where the issue was discussed and where I found [the root cause](https://github.com/openjdk/jdk/pull/11104#issuecomment-1382435784).
> 
> **Root Cause**
> 
> The icon extraction code compares the returned handle to zero: 
> https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1157-L1158
> 
> On 64-bit systems, a valid handle can be negative. For example:
> 
> 
> getIcon : Desktop 16(16)
> GetIconLocation(uFlags=0x22, flags=0x4, index=-110) SUCCESS - szBuf=C:\Windows\system32\imageres.dll
> Extract - hres: 0, hIcon=0000000019B200F9, hIconSmall=FFFFFFFFF98C00EB, size=16(0x100020)
> SUCCEEDED
> !!! hIcon(0xfffffffff98c00eb) <= 0 : Desktop 16(16)
> 
> 
> Here in `size=16(0x100020)`, 16 is the requested icon size, the value in parenthesis is value of `iconSize` passed to the [`Extract`](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-iextracticonw-extract) method that contains the size for small icon in high word and that for large icon in low word. `Desktop 16(16)` means the icon of size 16?16 is requested, and we're extracting 16?16 icon.
> 
> The icon was extracted _successfully_ but its handle was interpreted as an error.
> 
> The same problem exists in the fallback code:
> https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1161
> 
> Then when the fallback code is executed, another problem occurs:
> 
> 
> GetIconLocation(uFlags=0x40, flags=0x1a3, index=-675088752) SUCCESS - szBuf=
> Extract - hres: 80004005, hIcon=0000000000000000, hIconSmall=000001A3D7C2F83A, size=16(100020)
> NOT SUCCEEDED
> hIcon = 0x1a3d7c2f83a : Desktop 16(16)
> 
> 
> The error code 0x80004005 is `E_FAIL`. Yet the return value is not verified in the code:
> https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp#L997-L1003
> 
> Since the icon handle is *seemingly* valid, it continues to extracting the icon bits:
> 
> 
> native getIconBits - fn_GetIconInfo returned false
> Error code: 0x57a - Invalid cursor handle.
> makeIcon: iconBits = null
> 
> 
> It's not a surprise. After all, the `Extract` method returned an error, which means neither icon handle is valid.
> 
> In the end, the `MultiResolutionIcon` contains `null`:
> 
> ????16 -> null
> ????32 -> BufferedImage @ 59e735d
> ????24 -> BufferedImage @ 60b2faf0
> 
> 
> This problem has existed for since [JDK-8182043](https://bugs.openjdk.org/browse/JDK-8182043), yet it went unnoticed because `getResolutionVariant` just returned a null. However, after [JDK-8282526](https://bugs.openjdk.org/browse/JDK-8282526) was integrated, the result is used, which leads to `NullPointerException`.
> 
> 
> **The Fix**
> 
> Handle the errors as `hIcon == E_PENDING || hIcon == 0` and `hIcon == 0`. In the fallback code where a default icon is requested, [`E_PENDING` cannot be returned](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-iextracticonw-geticonlocation#remarks), it's valid only if `GIL_ASYNC` flag is used.
> 
> Add `assert` statements to `MultiResolutionIconImage` for null-checks which will help us to catch a similar situation if it occurs.
> 
> **Testing**
> 
> The two errors combined lead to random failures. No particular host reproduced the problem more often.
> 
> While I was testing with the additional traces, sometimes 5 of 10 tests failed, other times only 1 of 10. There were a couple of test runs where no failures occurred.
> 
> With the fix applied, no failures occurred.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12010


From aivanov at openjdk.org  Wed Jan 18 15:50:22 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jan 2023 15:50:22 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v12]
In-Reply-To: <xc5jSzIn-jTFOO7m-7B89BNlb4bZaePWInCwMN10Vao=.adc658f0-c59f-47d0-acee-3a86312ca1ec@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
 <Pg3Iz33l7lyZ6EZVQ34JDtM55-31TxZB-RruEvxu_Bo=.74830bd5-2f2d-4101-9ca1-aabaaccefb39@github.com>
 <j2MkhXpGdA7iS36lFNXEvgGHnG3fdUmbwWCq_orL8bU=.9929e63e-2cab-4829-98c5-30d9822d7ecf@github.com>
 <g8Fy85DZEwnUUepoUtSMZYc1nrP0yN0i5Z-_RcQo_-s=.d5924396-cdef-406c-a60c-8dd63c93cad8@github.com>
 <GWdrngFyd9R9IM5YI9d12rLQs9mvCw-flaASIsaczXE=.c8966381-5b06-44c9-a406-22b7b9ffd150@github.com>
 <xc5jSzIn-jTFOO7m-7B89BNlb4bZaePWInCwMN10Vao=.adc658f0-c59f-47d0-acee-3a86312ca1ec@github.com>
Message-ID: <HXQHEqXHE0tzOBwz56JmF_Cedjq-cnsfjYWPfgMWyds=.47affc0f-1360-4415-80ad-df9ef2afc173@github.com>

On Wed, 18 Jan 2023 14:54:01 GMT, Tejesh R <tr at openjdk.org> wrote:

> > Should it rather be set to a non-null value?
> > Personally, I think the tooltip for the Approve button isn't needed as its purpose is obvious. However, the tooltip is added in all the L&F, so in custom case there should also be the tooltip.
> 
> Yeah, but the fallback tooltip text for aqua L&F is set to null.
> 
> https://github.com/openjdk/jdk/blob/754f6e6116b8889c49abf34d01f6fc3e9f1b3cb7/src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java#L2055

**Change the code** so that it's not null just like with `getDefaultButton` in #12008. Make Aqua L&F consistent with other L&Fs.

[JDK-8300549](https://bugs.openjdk.org/browse/JDK-8300549): JFileChooser Approve button tooltip is null in Aqua L&F in CUSTOM_DIALOG mode

If `AquaFileChooserUI` had extended `BasicFileChooserUI`, it would've gotten the correct fallbacks automatically with your fix. But it doesn't.

Shall it be updated to extend `BasicFileChooserUI`?

Does it make sense to update `AquaFileChooserUI` to fallback to `OPEN_DIALOG` defaults if `CUSTOM_DIALOG` is set?

Since a special property exists for the text of the custom Approve button text, a new property for the custom tooltip should be added. Or `FileChooser.chooseButton.textAndMnemonic` property could be removed if the above suggestion is implemented.

-------------

PR: https://git.openjdk.org/jdk/pull/11901


From prr at openjdk.org  Wed Jan 18 17:03:15 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Jan 2023 17:03:15 GMT
Subject: RFR: 8300167: Add validation of the raster's layout before using
 in native
In-Reply-To: <Erhi6Eslm9ab-0wUF4cDUTNWrE6m2ep91biO-PSPrlU=.84976aff-b0c6-478f-aa1d-32a0e6e1e715@github.com>
References: <Erhi6Eslm9ab-0wUF4cDUTNWrE6m2ep91biO-PSPrlU=.84976aff-b0c6-478f-aa1d-32a0e6e1e715@github.com>
Message-ID: <n2RiRT_C4TlM8o9x37sl5i--kqeQbm7oHUB6VKkf348=.59eb17cf-34e6-42de-83a6-26e2418b22d9@github.com>

On Sat, 14 Jan 2023 07:23:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Currently, we always validate image layouts passed from java to native, except for some types of rasters. One of the reasons why the rasters are skipped is that they are not public and have their own validation during construction. But it is unclear how it works in the multithreaded case. All these objects are not thread-safe - could it be possible that we can get the raster that is not completely constructed/validated?
> 
> FYI I have started to look into this method because when I did an accidental typo in pixel format in this method I got the same symptoms/crash as described [here](https://bugs.openjdk.org/browse/JDK-8278101). It might be unrelated but it is safer to fix.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12004


From prr at openjdk.org  Wed Jan 18 17:25:15 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Jan 2023 17:25:15 GMT
Subject: RFR: 8286581: Make Java process DPI Aware if sun.java2d.dpiaware
 property is set [v2]
In-Reply-To: <Rsjp-dYL8GbJjnG-XtxyN7I4GnU9iWCZ9bNGX6K0Pqc=.a4a0034a-9cba-4f9e-955b-cc897c749b93@github.com>
References: <HnbTtI7Q0467OzM1jTs1_yGl4ZZTzIEuQLuyUyseXLY=.ce6942e5-82e6-430b-a094-544a7d0ff76f@github.com>
 <Rsjp-dYL8GbJjnG-XtxyN7I4GnU9iWCZ9bNGX6K0Pqc=.a4a0034a-9cba-4f9e-955b-cc897c749b93@github.com>
Message-ID: <_PlLlEF7AvODaqBQSKNBF5XVEgU_WSTYOlPPNOgMua4=.03978714-de36-4f94-ac70-ea24f496c79a@github.com>

On Tue, 17 Jan 2023 17:01:48 GMT, Rajat Mahajan <duke at openjdk.org> wrote:

>> I tested by removing dpi-awareness settings from the manifest file, and then running my app with -Dsun.java2d.dpiaware=false. This showed java.exe as "Unaware" in task-manager, and with it set to true I saw "Per-Monitor (v2)" dpi awareness for java.exe.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright year

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11998


From prr at openjdk.org  Wed Jan 18 17:25:18 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Jan 2023 17:25:18 GMT
Subject: RFR: 8286581: Make Java process DPI Aware if sun.java2d.dpiaware
 property is set [v2]
In-Reply-To: <TzD4zfNVLlzxcZu0yhVQENybi1U6e0yfZpLGi5A77zQ=.5160bbb9-c671-47d2-a07c-2a85f7e28e4b@github.com>
References: <HnbTtI7Q0467OzM1jTs1_yGl4ZZTzIEuQLuyUyseXLY=.ce6942e5-82e6-430b-a094-544a7d0ff76f@github.com>
 <Rsjp-dYL8GbJjnG-XtxyN7I4GnU9iWCZ9bNGX6K0Pqc=.a4a0034a-9cba-4f9e-955b-cc897c749b93@github.com>
 <wFjbwHUrnsOYc3-9eWd2447giOmRC5exXC80FFMQceI=.e442446d-82aa-4a88-ad60-f5fe8cbfd88b@github.com>
 <TzD4zfNVLlzxcZu0yhVQENybi1U6e0yfZpLGi5A77zQ=.5160bbb9-c671-47d2-a07c-2a85f7e28e4b@github.com>
Message-ID: <zdFi1lBxkyQ2ftoQhNCaYMOQvwzNx8j4C9QarbEeKF4=.1e51aa9d-0b51-403e-9f4b-7427bf46715a@github.com>

On Tue, 17 Jan 2023 20:07:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> You [asked](https://bugs.openjdk.org/browse/JDK-8286581?focusedCommentId=14495409&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14495409) about a custom launcher which may not set the DPI Awareness in the manifest.

OK that is what I expected as the answer .. it really helps reviewers if a PR gives explanation of things like this in the initial description ..

-------------

PR: https://git.openjdk.org/jdk/pull/11998


From aivanov at openjdk.org  Wed Jan 18 17:29:14 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jan 2023 17:29:14 GMT
Subject: RFR: 8286581: Make Java process DPI Aware if sun.java2d.dpiaware
 property is set [v2]
In-Reply-To: <zdFi1lBxkyQ2ftoQhNCaYMOQvwzNx8j4C9QarbEeKF4=.1e51aa9d-0b51-403e-9f4b-7427bf46715a@github.com>
References: <HnbTtI7Q0467OzM1jTs1_yGl4ZZTzIEuQLuyUyseXLY=.ce6942e5-82e6-430b-a094-544a7d0ff76f@github.com>
 <Rsjp-dYL8GbJjnG-XtxyN7I4GnU9iWCZ9bNGX6K0Pqc=.a4a0034a-9cba-4f9e-955b-cc897c749b93@github.com>
 <wFjbwHUrnsOYc3-9eWd2447giOmRC5exXC80FFMQceI=.e442446d-82aa-4a88-ad60-f5fe8cbfd88b@github.com>
 <TzD4zfNVLlzxcZu0yhVQENybi1U6e0yfZpLGi5A77zQ=.5160bbb9-c671-47d2-a07c-2a85f7e28e4b@github.com>
 <zdFi1lBxkyQ2ftoQhNCaYMOQvwzNx8j4C9QarbEeKF4=.1e51aa9d-0b51-403e-9f4b-7427bf46715a@github.com>
Message-ID: <mUBUkFrxMkf0Bszmn4Su8qT7m7TczvlUdfT-Gb_FNUY=.be0c462f-425d-49df-9dca-d49b939c09a8@github.com>

On Wed, 18 Jan 2023 17:22:37 GMT, Phil Race <prr at openjdk.org> wrote:

> OK that is what I expected as the answer .. it really helps reviewers if a PR gives explanation of things like this in the initial description ..

Rajat and I discussed it, I agree providing a short summary of what the problem is helps reviewers as it saves time opening the JBS issue and reading through all the comments.

Thank you!

-------------

PR: https://git.openjdk.org/jdk/pull/11998


From duke at openjdk.org  Wed Jan 18 18:07:23 2023
From: duke at openjdk.org (Rajat Mahajan)
Date: Wed, 18 Jan 2023 18:07:23 GMT
Subject: Integrated: 8286581: Make Java process DPI Aware if
 sun.java2d.dpiaware property is set
In-Reply-To: <HnbTtI7Q0467OzM1jTs1_yGl4ZZTzIEuQLuyUyseXLY=.ce6942e5-82e6-430b-a094-544a7d0ff76f@github.com>
References: <HnbTtI7Q0467OzM1jTs1_yGl4ZZTzIEuQLuyUyseXLY=.ce6942e5-82e6-430b-a094-544a7d0ff76f@github.com>
Message-ID: <yo_VabFMvgr0spBWWnGtdqPJqTcVYe_vLsQQZ0MdmwI=.3cbb4b2d-2be6-4fe3-bd81-1110f63b4b3e@github.com>

On Fri, 13 Jan 2023 20:53:31 GMT, Rajat Mahajan <duke at openjdk.org> wrote:

> I tested by removing dpi-awareness settings from the manifest file, and then running my app with -Dsun.java2d.dpiaware=false. This showed java.exe as "Unaware" in task-manager, and with it set to true I saw "Per-Monitor (v2)" dpi awareness for java.exe.

This pull request has now been integrated.

Changeset: 2a46e07f
Author:    Rajat Mahajan <rajat.m.mahajan at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a46e07f7d85a3c7db93b53b5c347cd96a91cbb9
Stats:     15 lines in 1 file changed: 3 ins; 2 del; 10 mod

8286581: Make Java process DPI Aware if sun.java2d.dpiaware property is set

Reviewed-by: aivanov, prr

-------------

PR: https://git.openjdk.org/jdk/pull/11998


From serb at openjdk.org  Wed Jan 18 20:31:15 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 18 Jan 2023 20:31:15 GMT
Subject: Integrated: 8299772: The ColorModel.getRGBdefault() method is not
 thread-safe
In-Reply-To: <Ov06tqQrCHkABN9x6zIYIdMjqK0qMEEqlboiSTIdHgw=.729da5c8-e6d5-428a-86af-08e41e84a2c0@github.com>
References: <Ov06tqQrCHkABN9x6zIYIdMjqK0qMEEqlboiSTIdHgw=.729da5c8-e6d5-428a-86af-08e41e84a2c0@github.com>
Message-ID: <K6WtUtSPZLJGuGkhYM8mk7sCuFPYrp3q3j2JwD2NMkM=.e3b7475f-5b07-4a4b-8b5a-a5f21bd4de50@github.com>

On Sun, 8 Jan 2023 01:09:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The getRGBdefault() was made thread safe via holder implemented as a local interface.

This pull request has now been integrated.

Changeset: 8b70c432
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b70c432d31b29bf5f6b8d29809e3c3b91318be1
Stats:     80 lines in 2 files changed: 70 ins; 3 del; 7 mod

8299772: The ColorModel.getRGBdefault() method is not thread-safe

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/11895


From jwilhelm at openjdk.org  Wed Jan 18 22:07:58 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 18 Jan 2023 22:07:58 GMT
Subject: RFR: Merge jdk20
Message-ID: <aoXMpcOdw9mIXTxDzeZ_BL-vPIIxG7Cno_7ULOPDUcA=.587db5a6-79dc-4420-b76f-161ec629277d@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8300275: SegmentScope.isAccessibleBy returning incorrect values
 - 8300195: Fall-through issue occurs when using record pattern in switch statements
 - 8295723: security/infra/wycheproof/RunWycheproof.java fails with Assertion Error
 - 8295687: Better BMP bounds
 - 8293742: Better Banking of Sounds
 - 8293554: Enhanced DH Key Exchanges
 - 8287411: Enhance DTLS Performance
 - 8293717: Objective view of ObjectView
 - 8293734: Improve BMP image handling
 - ... and 5 more: https://git.openjdk.org/jdk/compare/8b70c432...77fb81ec

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=12085&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=12085&range=00.1

Changes: https://git.openjdk.org/jdk/pull/12085/files
  Stats: 564 lines in 27 files changed: 332 ins; 117 del; 115 mod
  Patch: https://git.openjdk.org/jdk/pull/12085.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12085/head:pull/12085

PR: https://git.openjdk.org/jdk/pull/12085


From jwilhelm at openjdk.org  Wed Jan 18 23:32:35 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 18 Jan 2023 23:32:35 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <aoXMpcOdw9mIXTxDzeZ_BL-vPIIxG7Cno_7ULOPDUcA=.587db5a6-79dc-4420-b76f-161ec629277d@github.com>
References: <aoXMpcOdw9mIXTxDzeZ_BL-vPIIxG7Cno_7ULOPDUcA=.587db5a6-79dc-4420-b76f-161ec629277d@github.com>
Message-ID: <WxP2Ie203v7YoiY0G-tY2xbu4Xnajzc2aRYwLBvaUtY=.ef8aa6e1-64b4-4e60-8898-4aaf24188522@github.com>

On Wed, 18 Jan 2023 21:56:13 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: fc9f8baf
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fc9f8baf56a8888362ad60d0e6dc8953690b80d3
Stats:     564 lines in 27 files changed: 332 ins; 117 del; 115 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/12085


From dnguyen at openjdk.org  Thu Jan 19 01:18:57 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 19 Jan 2023 01:18:57 GMT
Subject: RFR: 8300269: The selected item in an editable JComboBox with titled
 border is not visible in Aqua LAF
Message-ID: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>

The fixed height causes the titled border insets to reserve a majority of the height available for the component. This fixed height is meant for the default AquaComboBox usage, so the old default height is more applicable when a border, such as TitledBorder, is set on an Aqua Editable ComboBox.

A conditional to check for a border is added since this is the default for an AquaComboBox using AquaBorder in AquaComboBoxUI's rectangleForCurrentValue() step. A check for any border rather than an instance of a TitledBorder is used because this issue causes changes in other borders as well (I found it for LineBorder for example). 

The editable JComboBox is visible with a LineBorder, but the coordinates of the comboBox are aligned with the top of the arrowButton instead of the bottom (which was the case before the previous fix). So, the method now defaults to the behavior before the fix for any editable comboBox pre-fix if a different border is set.

-------------

Commit messages:
 - Add conditional to not fix height when a border is added

Changes: https://git.openjdk.org/jdk/pull/12087/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12087&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300269
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12087.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12087/head:pull/12087

PR: https://git.openjdk.org/jdk/pull/12087


From psadhukhan at openjdk.org  Thu Jan 19 03:51:28 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 19 Jan 2023 03:51:28 GMT
Subject: RFR: 8267582: BasicLookAndFeel should not call
 getComponentPopupMenu twice to get a popup menu [v3]
In-Reply-To: <B9zQWhP3Z5z3pYOXHCNMtmkGtJto8Nu_VMqbeRv9XfY=.ccc76c42-0cab-4261-928a-81aa7df74d1f@github.com>
References: <rVW2gyOA88cdon5y0Mjiv8DlIMzX9khi3u2k1Nm2m5Y=.622ae3fb-8a75-4d93-8ebe-9e1403b856e1@github.com>
 <B9zQWhP3Z5z3pYOXHCNMtmkGtJto8Nu_VMqbeRv9XfY=.ccc76c42-0cab-4261-928a-81aa7df74d1f@github.com>
Message-ID: <o_exGzavntVHpSvmw0NO_540uskxWJ5FBr5PB28NbEA=.f7186b61-0730-4c81-b939-e2a9b434da8d@github.com>

On Wed, 18 Jan 2023 15:21:34 GMT, SWinxy <duke at openjdk.org> wrote:

>> Please review this small change to cache a component's popup menu in BLAF.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   order imports

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12017


From psadhukhan at openjdk.org  Thu Jan 19 03:53:25 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 19 Jan 2023 03:53:25 GMT
Subject: RFR: 8300269: The selected item in an editable JComboBox with
 titled border is not visible in Aqua LAF
In-Reply-To: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>
References: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>
Message-ID: <CFFrSZYEN9eV3sg9w0RVpVEj-T8NpY5NOlXCJDfjLbU=.d69b0c53-5294-4887-aa8f-d3f83939b7a6@github.com>

On Thu, 19 Jan 2023 01:12:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> The fixed height causes the titled border insets to reserve a majority of the height available for the component. This fixed height is meant for the default AquaComboBox usage, so the old default height is more applicable when a border, such as TitledBorder, is set on an Aqua Editable ComboBox.
> 
> A conditional to check for a border is added since this is the default for an AquaComboBox using AquaBorder in AquaComboBoxUI's rectangleForCurrentValue() step. A check for any border rather than an instance of a TitledBorder is used because this issue causes changes in other borders as well (I found it for LineBorder for example). 
> 
> The editable JComboBox is visible with a LineBorder, but the coordinates of the comboBox are aligned with the top of the arrowButton instead of the bottom (which was the case before the previous fix). So, the method now defaults to the behavior before the fix for any editable comboBox pre-fix if a different border is set.

It probably will need a testcase.
You can work with @manukumarvs to see if https://github.com/openjdk/jdk/pull/12061 can be merged along with this..

-------------

PR: https://git.openjdk.org/jdk/pull/12087


From duke at openjdk.org  Thu Jan 19 04:45:33 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 19 Jan 2023 04:45:33 GMT
Subject: RFR: 8267582: BasicLookAndFeel should not call
 getComponentPopupMenu twice to get a popup menu [v3]
In-Reply-To: <B9zQWhP3Z5z3pYOXHCNMtmkGtJto8Nu_VMqbeRv9XfY=.ccc76c42-0cab-4261-928a-81aa7df74d1f@github.com>
References: <rVW2gyOA88cdon5y0Mjiv8DlIMzX9khi3u2k1Nm2m5Y=.622ae3fb-8a75-4d93-8ebe-9e1403b856e1@github.com>
 <B9zQWhP3Z5z3pYOXHCNMtmkGtJto8Nu_VMqbeRv9XfY=.ccc76c42-0cab-4261-928a-81aa7df74d1f@github.com>
Message-ID: <ohzJ7Ne0DcNXH5X8i3ZzuGM_ECohuZxToQN_lbw1K1A=.f1834a1b-b044-4d04-b827-8f6f4f4f3c21@github.com>

On Wed, 18 Jan 2023 15:21:34 GMT, SWinxy <duke at openjdk.org> wrote:

>> Please review this small change to cache a component's popup menu in BLAF.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   order imports

@TheShermanTanker you might be needed here!

-------------

PR: https://git.openjdk.org/jdk/pull/12017


From serb at openjdk.org  Thu Jan 19 05:05:37 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 19 Jan 2023 05:05:37 GMT
Subject: Integrated: 8300167: Add validation of the raster's layout before
 using in native
In-Reply-To: <Erhi6Eslm9ab-0wUF4cDUTNWrE6m2ep91biO-PSPrlU=.84976aff-b0c6-478f-aa1d-32a0e6e1e715@github.com>
References: <Erhi6Eslm9ab-0wUF4cDUTNWrE6m2ep91biO-PSPrlU=.84976aff-b0c6-478f-aa1d-32a0e6e1e715@github.com>
Message-ID: <BdOAf7i79ciWiNFEpG48URLrLqryepeK33Axd_Bt9bA=.4274ff80-620b-43aa-b380-08d823d9097d@github.com>

On Sat, 14 Jan 2023 07:23:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Currently, we always validate image layouts passed from java to native, except for some types of rasters. One of the reasons why the rasters are skipped is that they are not public and have their own validation during construction. But it is unclear how it works in the multithreaded case. All these objects are not thread-safe - could it be possible that we can get the raster that is not completely constructed/validated?
> 
> FYI I have started to look into this method because when I did an accidental typo in pixel format in this method I got the same symptoms/crash as described [here](https://bugs.openjdk.org/browse/JDK-8278101). It might be unrelated but it is safer to fix.

This pull request has now been integrated.

Changeset: 7348b9ec
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7348b9ec9373746bb76bc9fa9556f1811bd9e475
Stats:     9 lines in 1 file changed: 5 ins; 1 del; 3 mod

8300167: Add validation of the raster's layout before using in native

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/12004


From jwaters at openjdk.org  Thu Jan 19 05:08:43 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 19 Jan 2023 05:08:43 GMT
Subject: RFR: 8267582: BasicLookAndFeel should not call
 getComponentPopupMenu twice to get a popup menu [v3]
In-Reply-To: <B9zQWhP3Z5z3pYOXHCNMtmkGtJto8Nu_VMqbeRv9XfY=.ccc76c42-0cab-4261-928a-81aa7df74d1f@github.com>
References: <rVW2gyOA88cdon5y0Mjiv8DlIMzX9khi3u2k1Nm2m5Y=.622ae3fb-8a75-4d93-8ebe-9e1403b856e1@github.com>
 <B9zQWhP3Z5z3pYOXHCNMtmkGtJto8Nu_VMqbeRv9XfY=.ccc76c42-0cab-4261-928a-81aa7df74d1f@github.com>
Message-ID: <jOBiWkkKgNQqqdCtG0TVTe3NeTB06lRNp8SImu6Y13I=.32202dc4-4dd6-4536-9de7-51d32c571fb4@github.com>

On Wed, 18 Jan 2023 15:21:34 GMT, SWinxy <duke at openjdk.org> wrote:

>> Please review this small change to cache a component's popup menu in BLAF.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   order imports

Good Work buddy :)

-------------

PR: https://git.openjdk.org/jdk/pull/12017


From duke at openjdk.org  Thu Jan 19 05:08:43 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 19 Jan 2023 05:08:43 GMT
Subject: Integrated: 8267582: BasicLookAndFeel should not call
 getComponentPopupMenu twice to get a popup menu
In-Reply-To: <rVW2gyOA88cdon5y0Mjiv8DlIMzX9khi3u2k1Nm2m5Y=.622ae3fb-8a75-4d93-8ebe-9e1403b856e1@github.com>
References: <rVW2gyOA88cdon5y0Mjiv8DlIMzX9khi3u2k1Nm2m5Y=.622ae3fb-8a75-4d93-8ebe-9e1403b856e1@github.com>
Message-ID: <NM3e_zvWWM-bAXcawmG5_v6gDuHiy6xLjT8KuBsS3IM=.733e2d3b-d0e8-4a3f-9f1b-6185b74b399c@github.com>

On Mon, 16 Jan 2023 20:07:07 GMT, SWinxy <duke at openjdk.org> wrote:

> Please review this small change to cache a component's popup menu in BLAF.

This pull request has now been integrated.

Changeset: 2e9cb4b1
Author:    SWinxy <swinxythecat at gmail.com>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e9cb4b1f6ebba75cffa407f5142fdd95ed9bd88
Stats:     75 lines in 1 file changed: 31 ins; 22 del; 22 mod

8267582: BasicLookAndFeel should not call getComponentPopupMenu twice to get a popup menu

Reviewed-by: psadhukhan

-------------

PR: https://git.openjdk.org/jdk/pull/12017


From jdv at openjdk.org  Thu Jan 19 07:13:40 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 19 Jan 2023 07:13:40 GMT
Subject: RFR: 8244400: MenuItem may cache the size and did not update it
 when the screen DPI is changed [v3]
In-Reply-To: <3PaNLLK-YJG2ccMZRXvhk7R_KsdTIBUX7jseDNo_BYU=.b1a73ab8-a80b-487b-9274-a2cd699ef815@github.com>
References: <-uTiC-hv_VAqzznPs2lyYbPFmjJ06PIGZZCbEfuwPgE=.6d97f3a5-bd81-4697-9299-0e7039e2d9c2@github.com>
 <3PaNLLK-YJG2ccMZRXvhk7R_KsdTIBUX7jseDNo_BYU=.b1a73ab8-a80b-487b-9274-a2cd699ef815@github.com>
Message-ID: <JAS06xJ3mCRPMRCZ-vW_ul0DBd_bqpTfbaDvn8WL89M=.a8c91583-b805-418b-a11b-d4c4085edab8@github.com>

On Thu, 8 Dec 2022 03:38:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The MenuItemLayoutHelper.clearUsedParentClientProperties must be called automatically when the DPI was changed. 
>> Workaround added in the test for this bug is removed.
>> 
>> CI tests are ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Motif

@prsadhuk Are we waiting on something to push this change?

-------------

PR: https://git.openjdk.org/jdk/pull/11551


From jdv at openjdk.org  Thu Jan 19 07:33:31 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 19 Jan 2023 07:33:31 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v7]
In-Reply-To: <YPgkv5fhlsqkJI7qvEr9guo6JbOMF8gn9DfEK_8kVCY=.c11980fc-9f33-4119-8181-ed712c76fb3d@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <YPgkv5fhlsqkJI7qvEr9guo6JbOMF8gn9DfEK_8kVCY=.c11980fc-9f33-4119-8181-ed712c76fb3d@github.com>
Message-ID: <p92-d5-Qa3ep8bi27ZWdUb2rULEh6RcC1RYIxMygZJA=.61d377aa-8ae7-4fa0-81bc-bf212f7b75b9@github.com>

On Fri, 13 Jan 2023 20:36:46 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as functional parameter to the method.  
>> 
>> Following are the usual steps for any border scaling -
>> 
>> - Resetting transform.
>> - Calculating new width, height, x & y-translations.
>> - Perform the required border rendering.
>> - And at the end restore the previous transform.
>> 
>> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
>> 
>> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
>> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
>> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
>> 
>> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.
>
> Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyright year updated
>  - formatting changes, docs added

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11571


From jdv at openjdk.org  Thu Jan 19 08:05:54 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 19 Jan 2023 08:05:54 GMT
Subject: RFR: 8272288: Funky multiresolution image breaks graphics context
In-Reply-To: <v6GtuWIiXG4SzSCdmVGlwdf0hEEVHrZureMEm5NqcUE=.e5d62f8b-6a2f-429e-923a-1c05385f69ac@github.com>
References: <v6GtuWIiXG4SzSCdmVGlwdf0hEEVHrZureMEm5NqcUE=.e5d62f8b-6a2f-429e-923a-1c05385f69ac@github.com>
Message-ID: <iNCaZ-TKCpnVegXcn2cTVWzViSna4P4BcC4Q-n5VsI4=.288ef366-9700-459f-aa29-0ed34bda465e@github.com>

On Wed, 14 Dec 2022 08:20:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the next iteration of fixing the issue of rendering "broken" image. The fix for [JDK-7183828](https://bugs.openjdk.org/browse/JDK-7183828) changed the possible IllegalArgumentException during rendering to the InvalidPipeException in assumtion that the new exception will be catched by the java2d machinery and the current-accelerated pipeline will be invalidated and software-pipeline will take care about that image.
> 
> But that change uncover another bug, the accelerated-pipeline invalidation by the InvalidPipeException works in D3D pipeline only, other pipelines start to use software based surfaces, but do not report about that the client code, as a result the next code does not work as expected, since contentsLost alwys return false:
> 
>         do {
>             vi.validate(gc);
>             Graphics2D g = vi.createGraphics();
>             g.fillRect(0, 0, vi.getWidth(), vi.getHeight());
>             g.dispose();
>         } while (vi.contentsLost());
> 
> After this change the correct value will be reported by the contentsLost(), so the RepaintManager will be able to catch that.
> But this fix uncovered another bug. That fallback code path in the RepaintManager was not tested on HiDPI screen and does not work well. I'll file a separate bug about that.

test/jdk/java/awt/image/VolatileImage/ReportRenderingError.java line 91:

> 89:             Graphics2D g = vi.createGraphics();
> 90:             g.setColor(Color.RED);
> 91:             g.drawImage(image, 0, 0, null); // <- can cause InvalidPipeException

This drawImage call is expected to through InvalidPipeException all the times or is it intermittent?
If it is intermittent why so? Please explain.

It looks like after https://github.com/openjdk/jdk/commit/8da6c8d6 we will through InvalidPipeException for all cases of custom images and not intermittently.

-------------

PR: https://git.openjdk.org/jdk/pull/11664


From jdv at openjdk.org  Thu Jan 19 08:26:03 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 19 Jan 2023 08:26:03 GMT
Subject: RFR: 8272288: Funky multiresolution image breaks graphics context
In-Reply-To: <v6GtuWIiXG4SzSCdmVGlwdf0hEEVHrZureMEm5NqcUE=.e5d62f8b-6a2f-429e-923a-1c05385f69ac@github.com>
References: <v6GtuWIiXG4SzSCdmVGlwdf0hEEVHrZureMEm5NqcUE=.e5d62f8b-6a2f-429e-923a-1c05385f69ac@github.com>
Message-ID: <W_nWnq9ale7jiakx-FbMzSwAcjTAW1Ymgw9ITT-nnRc=.1071a41b-39dd-40d2-b4f1-7da5a84f7a14@github.com>

On Wed, 14 Dec 2022 08:20:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the next iteration of fixing the issue of rendering "broken" image. The fix for [JDK-7183828](https://bugs.openjdk.org/browse/JDK-7183828) changed the possible IllegalArgumentException during rendering to the InvalidPipeException in assumtion that the new exception will be catched by the java2d machinery and the current-accelerated pipeline will be invalidated and software-pipeline will take care about that image.
> 
> But that change uncover another bug, the accelerated-pipeline invalidation by the InvalidPipeException works in D3D pipeline only, other pipelines start to use software based surfaces, but do not report about that the client code, as a result the next code does not work as expected, since contentsLost alwys return false:
> 
>         do {
>             vi.validate(gc);
>             Graphics2D g = vi.createGraphics();
>             g.fillRect(0, 0, vi.getWidth(), vi.getHeight());
>             g.dispose();
>         } while (vi.contentsLost());
> 
> After this change the correct value will be reported by the contentsLost(), so the RepaintManager will be able to catch that.
> But this fix uncovered another bug. That fallback code path in the RepaintManager was not tested on HiDPI screen and does not work well. I'll file a separate bug about that.

test/jdk/java/awt/image/VolatileImage/ReportRenderingError.java line 61:

> 59:  *
> 60:  * @requires (os.family == "mac")
> 61:  * @run main/othervm -Dsun.java2d.opengl=True ReportRenderingError

I ran this test in macOS and without the fix it exits after checking only OpenGL pipeline. We dont override restoreContents() in CGLVolatileSurfaceManager/MTLVolatileSurfaceManager so its better if we can force the test to run on all pipelines on individual platforms and not exit on first failure based on jtreg instrcutions. This will make the test more robust.

-------------

PR: https://git.openjdk.org/jdk/pull/11664


From jdv at openjdk.org  Thu Jan 19 08:35:46 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 19 Jan 2023 08:35:46 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11 [v2]
In-Reply-To: <tyvPceH1cD44Cvhu0H9Nyh9fXjvVM6zRQY58eDGvhGc=.dcccbc38-d120-490e-9b4f-82177e604917@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
 <tyvPceH1cD44Cvhu0H9Nyh9fXjvVM6zRQY58eDGvhGc=.dcccbc38-d120-490e-9b4f-82177e604917@github.com>
Message-ID: <jymdI2d2qpgL3GwfP0yWP61PgRMBJPNkRsdSCk_xQfM=.191660db-f54f-472c-8bb1-426fc5429947@github.com>

On Thu, 22 Dec 2022 18:15:07 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> ViewportOverlapping was failing intermittently on Windows (Win10 & 11). Added robot.setAutoWaitForIdle() to ViewportOverlapping and its base class (OverlappingTestBase) to stabilize the test.
>> 
>> Additionally added awt & swings tests to exclusiveAccess.dir in TEST.ROOT.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted TEST.ROOT changes

Are these tests verified in our CI with multiple runs after exclusiveAccess is removed?

-------------

PR: https://git.openjdk.org/jdk/pull/11747


From aivanov at openjdk.org  Thu Jan 19 12:53:24 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 19 Jan 2023 12:53:24 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11 [v2]
In-Reply-To: <jymdI2d2qpgL3GwfP0yWP61PgRMBJPNkRsdSCk_xQfM=.191660db-f54f-472c-8bb1-426fc5429947@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
 <tyvPceH1cD44Cvhu0H9Nyh9fXjvVM6zRQY58eDGvhGc=.dcccbc38-d120-490e-9b4f-82177e604917@github.com>
 <jymdI2d2qpgL3GwfP0yWP61PgRMBJPNkRsdSCk_xQfM=.191660db-f54f-472c-8bb1-426fc5429947@github.com>
Message-ID: <lUHwfZSkMl_rIlc9NuUrgJBJbFBcoqRajYoWyPEXsHY=.6d4f4203-dfa3-48dc-9237-ad4baabf0fca@github.com>

On Thu, 19 Jan 2023 08:33:25 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Are these tests verified in our CI with multiple runs after exclusiveAccess is removed?

These tests have always run in exclusive access in the CI.

-------------

PR: https://git.openjdk.org/jdk/pull/11747


From aivanov at openjdk.org  Thu Jan 19 13:03:18 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 19 Jan 2023 13:03:18 GMT
Subject: Integrated: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <lKLFw4FVKMO_0woqf516ebwHnavZjjO2tvCAfD1Xm6w=.202160e7-e82f-49c4-8b78-58dbe3476b2d@github.com>
References: <lKLFw4FVKMO_0woqf516ebwHnavZjjO2tvCAfD1Xm6w=.202160e7-e82f-49c4-8b78-58dbe3476b2d@github.com>
Message-ID: <1lHoP79MEzftNnioAO0hazJEQZd3aqWEAkecSyv0NjQ=.266e36f1-0208-4f8b-abb5-53a946f2da8c@github.com>

On Mon, 16 Jan 2023 14:19:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This is somewhat a continuation of #11104 where the issue was discussed and where I found [the root cause](https://github.com/openjdk/jdk/pull/11104#issuecomment-1382435784).
> 
> **Root Cause**
> 
> The icon extraction code compares the returned handle to zero: 
> https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1157-L1158
> 
> On 64-bit systems, a valid handle can be negative. For example:
> 
> 
> getIcon : Desktop 16(16)
> GetIconLocation(uFlags=0x22, flags=0x4, index=-110) SUCCESS - szBuf=C:\Windows\system32\imageres.dll
> Extract - hres: 0, hIcon=0000000019B200F9, hIconSmall=FFFFFFFFF98C00EB, size=16(0x100020)
> SUCCEEDED
> !!! hIcon(0xfffffffff98c00eb) <= 0 : Desktop 16(16)
> 
> 
> Here in `size=16(0x100020)`, 16 is the requested icon size, the value in parenthesis is value of `iconSize` passed to the [`Extract`](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-iextracticonw-extract) method that contains the size for small icon in high word and that for large icon in low word. `Desktop 16(16)` means the icon of size 16?16 is requested, and we're extracting 16?16 icon.
> 
> The icon was extracted _successfully_ but its handle was interpreted as an error.
> 
> The same problem exists in the fallback code:
> https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1161
> 
> Then when the fallback code is executed, another problem occurs:
> 
> 
> GetIconLocation(uFlags=0x40, flags=0x1a3, index=-675088752) SUCCESS - szBuf=
> Extract - hres: 80004005, hIcon=0000000000000000, hIconSmall=000001A3D7C2F83A, size=16(100020)
> NOT SUCCEEDED
> hIcon = 0x1a3d7c2f83a : Desktop 16(16)
> 
> 
> The error code 0x80004005 is `E_FAIL`. Yet the return value is not verified in the code:
> https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp#L997-L1003
> 
> Since the icon handle is *seemingly* valid, it continues to extracting the icon bits:
> 
> 
> native getIconBits - fn_GetIconInfo returned false
> Error code: 0x57a - Invalid cursor handle.
> makeIcon: iconBits = null
> 
> 
> It's not a surprise. After all, the `Extract` method returned an error, which means neither icon handle is valid.
> 
> In the end, the `MultiResolutionIcon` contains `null`:
> 
> ????16 -> null
> ????32 -> BufferedImage @ 59e735d
> ????24 -> BufferedImage @ 60b2faf0
> 
> 
> This problem has existed for since [JDK-8182043](https://bugs.openjdk.org/browse/JDK-8182043), yet it went unnoticed because `getResolutionVariant` just returned a null. However, after [JDK-8282526](https://bugs.openjdk.org/browse/JDK-8282526) was integrated, the result is used, which leads to `NullPointerException`.
> 
> 
> **The Fix**
> 
> Handle the errors as `hIcon == E_PENDING || hIcon == 0` and `hIcon == 0`. In the fallback code where a default icon is requested, [`E_PENDING` cannot be returned](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-iextracticonw-geticonlocation#remarks), it's valid only if `GIL_ASYNC` flag is used.
> 
> Add `assert` statements to `MultiResolutionIconImage` for null-checks which will help us to catch a similar situation if it occurs.
> 
> **Testing**
> 
> The two errors combined lead to random failures. No particular host reproduced the problem more often.
> 
> While I was testing with the additional traces, sometimes 5 of 10 tests failed, other times only 1 of 10. There were a couple of test runs where no failures occurred.
> 
> With the fix applied, no failures occurred.

This pull request has now been integrated.

Changeset: 2e4a3c47
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e4a3c47e262f91a7f881d9d990eb81a929d1627
Stats:     29 lines in 4 files changed: 17 ins; 2 del; 10 mod

8293862: javax/swing/JFileChooser/8046391/bug8046391.java failed with 'Cannot invoke "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is null'

Co-authored-by: Tejesh R <tr at openjdk.org>
Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/12010


From aivanov at openjdk.org  Thu Jan 19 17:12:51 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 19 Jan 2023 17:12:51 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v7]
In-Reply-To: <YPgkv5fhlsqkJI7qvEr9guo6JbOMF8gn9DfEK_8kVCY=.c11980fc-9f33-4119-8181-ed712c76fb3d@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <YPgkv5fhlsqkJI7qvEr9guo6JbOMF8gn9DfEK_8kVCY=.c11980fc-9f33-4119-8181-ed712c76fb3d@github.com>
Message-ID: <dX7bbuLu2aws6Wl_qB0YM7vL-qcYCwJbDshHqBsPQKo=.82912ee9-1839-4a22-9be9-0851a43d9c47@github.com>

On Fri, 13 Jan 2023 20:36:46 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as functional parameter to the method.  
>> 
>> Following are the usual steps for any border scaling -
>> 
>> - Resetting transform.
>> - Calculating new width, height, x & y-translations.
>> - Perform the required border rendering.
>> - And at the end restore the previous transform.
>> 
>> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
>> 
>> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
>> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
>> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
>> 
>> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.
>
> Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyright year updated
>  - formatting changes, docs added

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 148:

> 146:     /**
> 147:      * Used within border classes to add specific border implementation details.
> 148:      */

Suggestion:

    /**
     * A task which paints an <i>unscaled</i> border after {@code Graphics}
     * transforms are removed. It's used with the
     * {@link #paintBorder(Component, Graphics, int, int, int, int, UnscaledBorderPainter)
     * SwingUtilities3.paintBorder} which manages changing the transforms and calculating the
     * coordinates and size of the border.
     */

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 151:

> 149:     @FunctionalInterface
> 150:     public interface UnscaledBorderPainter {
> 151:         void paintUnscaledBorder(Component c, Graphics g,

Suggestion:

        /**
         * Paints the border for the specified component after the
         * {@code Graphics} transforms are removed.
         *
         * <p>
         * The <i>x</i> and <i>y</i> of the painted border are zero.
         * 
         * @param c the component for which this border is being painted
         * @param g the paint graphics
         * @param w the width of the painted border, in physical pixels
         * @param h the height of the painted border, in physical pixels
         * @param scaleFactor the scale that was in the {@code Graphics}
         *                    
         * @see #paintBorder(Component, Graphics, int, int, int, int, UnscaledBorderPainter) SwingUtilities3.paintBorder
         * @see javax.swing.border.Border#paintBorder(Component, Graphics, int, int, int, int) Border.paintBorder
         */
        void paintUnscaledBorder(Component c, Graphics g,

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 159:

> 157:      * Performs common scaling transformation steps required for rendering
> 158:      * the border correctly at different scales.
> 159:      */

Suggestion:

    /**
     * Paints the border for a component ensuring its sides have consistent
     * thickness at different scales.
     * <p>
     * It performs the following steps:
     * <ol>
     *     <li>Reset the scale transform on the {@code Graphics},</li>
     *     <li>Call {@code painter} to paint the border,</li>
     *     <li>Restore the transform.</li>
     * </ol>
     *
     * @param c the component for which this border is being painted
     * @param g the paint graphics
     * @param x the x position of the painted border
     * @param y the y position of the painted border
     * @param w the width of the painted border
     * @param h the height of the painted border
     * @param painter the painter object which paints the border after
     *                the transform on the {@code Graphics} is reset
     */

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 167:

> 165:         // Step 1: Reset Transform
> 166:         AffineTransform at = null;
> 167:         Stroke oldStk = null;

Suggestion:

        Stroke oldStroke = null;

Let's spell the word in full. It's used twice in the method and I see no reason to abbreviate it.

-------------

PR: https://git.openjdk.org/jdk/pull/11571


From honkar at openjdk.org  Thu Jan 19 18:09:42 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 19 Jan 2023 18:09:42 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v8]
In-Reply-To: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
Message-ID: <rHO3mGvYZeRLzloj4sWU3qm0VK1RzMeZPq3kGcSie1M=.e482a3e9-380b-4cbb-bd4e-c62b70d278b1@github.com>

> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as functional parameter to the method.  
> 
> Following are the usual steps for any border scaling -
> 
> - Resetting transform.
> - Calculating new width, height, x & y-translations.
> - Perform the required border rendering.
> - And at the end restore the previous transform.
> 
> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
> 
> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
> 
> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  java doc update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11571/files
  - new: https://git.openjdk.org/jdk/pull/11571/files/ffb3dd17..7e7a36b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11571&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11571&range=06-07

  Stats: 44 lines in 1 file changed: 38 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11571.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11571/head:pull/11571

PR: https://git.openjdk.org/jdk/pull/11571


From dnguyen at openjdk.org  Thu Jan 19 18:11:52 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 19 Jan 2023 18:11:52 GMT
Subject: RFR: 8300409: Create an automated regression test for JComboBox
 titled border issues(JDK-8300269)
In-Reply-To: <pixfugLjVG8x0l_8hOAv-TuJSl9RGp5Rc6c7_ungvcs=.bc2069ce-026a-4bd6-980b-77cafd00bb44@github.com>
References: <pixfugLjVG8x0l_8hOAv-TuJSl9RGp5Rc6c7_ungvcs=.bc2069ce-026a-4bd6-980b-77cafd00bb44@github.com>
Message-ID: <CRR-Pr_e0we06hpWDuRVf-XOJ--C6bsLt047kSp00AE=.0cc3afa2-f0d8-44df-b81a-7a82c6e52678@github.com>

On Wed, 18 Jan 2023 07:41:01 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a automated regression test for JComboBox titled border issues([JDK-8300269](https://bugs.openjdk.org/browse/JDK-8300269)).
> 
> This test passes in JDK-20-ea+15 and fails in JDK-20-ea+16 and above.

Hi Manukumar! As discussed, I will merged this test into my [PR](https://github.com/openjdk/jdk/pull/12087) since the regression fix for this test is there. This way the fix and test will be in one PR. Thanks

-------------

PR: https://git.openjdk.org/jdk/pull/12061


From dnguyen at openjdk.org  Thu Jan 19 18:12:03 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 19 Jan 2023 18:12:03 GMT
Subject: RFR: 8300269: The selected item in an editable JComboBox with
 titled border is not visible in Aqua LAF [v2]
In-Reply-To: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>
References: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>
Message-ID: <pd2zMoD3rYpG08UI_skEsMLnEEJCGDhz2BcJ6nPD--E=.01ddf417-96a1-4ed3-a1be-20dccf76c6a0@github.com>

> The fixed height causes the titled border insets to reserve a majority of the height available for the component. This fixed height is meant for the default AquaComboBox usage, so the old default height is more applicable when a border, such as TitledBorder, is set on an Aqua Editable ComboBox.
> 
> A conditional to check for a border is added since this is the default for an AquaComboBox using AquaBorder in AquaComboBoxUI's rectangleForCurrentValue() step. A check for any border rather than an instance of a TitledBorder is used because this issue causes changes in other borders as well (I found it for LineBorder for example). 
> 
> The editable JComboBox is visible with a LineBorder, but the coordinates of the comboBox are aligned with the top of the arrowButton instead of the bottom (which was the case before the previous fix). So, the method now defaults to the behavior before the fix for any editable comboBox pre-fix if a different border is set.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Add test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12087/files
  - new: https://git.openjdk.org/jdk/pull/12087/files/1f6965c4..c093ef7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12087&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12087&range=00-01

  Stats: 176 lines in 1 file changed: 176 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12087.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12087/head:pull/12087

PR: https://git.openjdk.org/jdk/pull/12087


From aivanov at openjdk.org  Thu Jan 19 18:39:18 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 19 Jan 2023 18:39:18 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v8]
In-Reply-To: <rHO3mGvYZeRLzloj4sWU3qm0VK1RzMeZPq3kGcSie1M=.e482a3e9-380b-4cbb-bd4e-c62b70d278b1@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <rHO3mGvYZeRLzloj4sWU3qm0VK1RzMeZPq3kGcSie1M=.e482a3e9-380b-4cbb-bd4e-c62b70d278b1@github.com>
Message-ID: <rZPKwWvjnWplmxheBCLPj9EFB204SHktw8z3kheAZxw=.df28406f-b24e-47a6-be7b-998eebb926df@github.com>

On Thu, 19 Jan 2023 18:09:42 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as functional parameter to the method.  
>> 
>> Following are the usual steps for any border scaling -
>> 
>> - Resetting transform.
>> - Calculating new width, height, x & y-translations.
>> - Perform the required border rendering.
>> - And at the end restore the previous transform.
>> 
>> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
>> 
>> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
>> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
>> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
>> 
>> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   java doc update

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11571


From honkar at openjdk.org  Thu Jan 19 18:46:56 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 19 Jan 2023 18:46:56 GMT
Subject: Integrated: JDK-8294680: Refactor scaled border rendering
In-Reply-To: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
Message-ID: <s8mWlE5Q7ZJ15OFrG_zEG8qikS19Z348JWoAis4P0VY=.93a65e0a-2817-475e-a9bd-7ee3c5051d27@github.com>

On Wed, 7 Dec 2022 21:34:12 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as functional parameter to the method.  
> 
> Following are the usual steps for any border scaling -
> 
> - Resetting transform.
> - Calculating new width, height, x & y-translations.
> - Perform the required border rendering.
> - And at the end restore the previous transform.
> 
> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
> 
> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
> 
> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.

This pull request has now been integrated.

Changeset: 80ab50b3
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/80ab50b3389cbdae6bced7cea3f3a84b94c5bb82
Stats:     305 lines in 4 files changed: 150 ins; 137 del; 18 mod

8294680: Refactor scaled border rendering

Co-authored-by: Alexey Ivanov <aivanov at openjdk.org>
Reviewed-by: rmahajan, achung, aivanov, jdv

-------------

PR: https://git.openjdk.org/jdk/pull/11571


From aivanov at openjdk.org  Thu Jan 19 19:36:28 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 19 Jan 2023 19:36:28 GMT
Subject: Integrated: 8299553: Make ScaledEtchedBorderTest.java comprehensive
In-Reply-To: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>
References: <16MpXfqknL1eN5jBhZbTXeuB3LpUMtAYCotVFb1-syE=.305dd269-daa7-4a10-a8cf-9def0da4621f@github.com>
Message-ID: <Ps8Hn6YG6IkJvq7PMFifrytITuMQopQ8x8zSYP0f2jM=.97783f65-35f9-44da-a4d3-880ace44cbc6@github.com>

On Tue, 3 Jan 2023 19:59:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The `ScaledEtchedBorderTest.java` test ([JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614)) verifies that the thickness of lines of `EtchedBorder` is consistent. The component inside had the same background color as the frame. Yet if there's another component the background of which is different, that background could be seen.
> 
> The updated test covers the scenario reported in [JDK-8294921](https://bugs.openjdk.org/browse/JDK-8294921).
> 
> The bug itself is fixed by refactoring [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) the border rendering code which uses a more precise coordinate calculation, see #11571. Thus, I contribute the test under a separate bugid.
> 
> I also modified `ScaledLineBorderTest.java` so that the location of the child panels is saved when they're created as done in `ScaledTextFieldBorderTest.java` in #11498. I removed the unused `Component` import after this modification from both tests.

This pull request has now been integrated.

Changeset: 558d610b
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/558d610bebb6967b4cfe922f62f1c4ba0df7daaf
Stats:     288 lines in 3 files changed: 145 ins; 54 del; 89 mod

8299553: Make ScaledEtchedBorderTest.java comprehensive

Reviewed-by: serb, honkar, achung

-------------

PR: https://git.openjdk.org/jdk/pull/11836


From aivanov at openjdk.org  Thu Jan 19 19:53:40 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 19 Jan 2023 19:53:40 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v10]
In-Reply-To: <dDNMsroUmRgM-LitBnimoWYshMmIAU9yRzU_T0SFHBY=.b32e97e5-6b87-442f-8f15-4ad12c512292@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <dDNMsroUmRgM-LitBnimoWYshMmIAU9yRzU_T0SFHBY=.b32e97e5-6b87-442f-8f15-4ad12c512292@github.com>
Message-ID: <wUg25ziP1apMW7oImUPIYhKrX5gwdz6wU0Qb2LzHnvQ=.68d926e3-d3c6-4fe9-9186-51de599a5b3d@github.com>

On Mon, 31 Oct 2022 08:59:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> DefaultListSelectionModel.removeIndexInterva accepts `int` value which allows it to take in Integer.MAX_VALUE theoratically but it does calculation with that value which can results in IOOBE.
>> Fix is to make sure the calculation stays within bounds.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

The CSR was approved two days ago, yet the bots didn't update the status of the issue. It should be ready for integration.

-------------

PR: https://git.openjdk.org/jdk/pull/10409


From duke at openjdk.org  Thu Jan 19 20:08:50 2023
From: duke at openjdk.org (Dan Lutker)
Date: Thu, 19 Jan 2023 20:08:50 GMT
Subject: RFR: 8300692: GCC 12 reports some compiler warnings in bundled
 freetype
Message-ID: <lrtV6uGXgoi4gTbbdgTuDQwGz8RlxK33JQDnCSARDQ0=.217ef880-2b54-4acd-a429-8e239a96264d@github.com>

Disabling warnings for bundled Freetype

-------------

Commit messages:
 - 8300692: GCC 12 reports some compiler warnings in bundled freetype

Changes: https://git.openjdk.org/jdk/pull/12102/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12102&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300692
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12102.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12102/head:pull/12102

PR: https://git.openjdk.org/jdk/pull/12102


From erikj at openjdk.org  Thu Jan 19 20:53:16 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 19 Jan 2023 20:53:16 GMT
Subject: RFR: 8300692: GCC 12 reports some compiler warnings in bundled
 freetype
In-Reply-To: <lrtV6uGXgoi4gTbbdgTuDQwGz8RlxK33JQDnCSARDQ0=.217ef880-2b54-4acd-a429-8e239a96264d@github.com>
References: <lrtV6uGXgoi4gTbbdgTuDQwGz8RlxK33JQDnCSARDQ0=.217ef880-2b54-4acd-a429-8e239a96264d@github.com>
Message-ID: <nQnxrCmprRxO8Y5KW7SU2ynb9eGdAXXtk1QDKqu3gdY=.bc1d9660-9280-4e21-8d31-7aa2f98a2f91@github.com>

On Thu, 19 Jan 2023 20:00:56 GMT, Dan Lutker <duke at openjdk.org> wrote:

> Disabling warnings for bundled Freetype

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12102


From serb at openjdk.org  Fri Jan 20 03:02:34 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 20 Jan 2023 03:02:34 GMT
Subject: RFR: 8300692: GCC 12 reports some compiler warnings in bundled
 freetype
In-Reply-To: <lrtV6uGXgoi4gTbbdgTuDQwGz8RlxK33JQDnCSARDQ0=.217ef880-2b54-4acd-a429-8e239a96264d@github.com>
References: <lrtV6uGXgoi4gTbbdgTuDQwGz8RlxK33JQDnCSARDQ0=.217ef880-2b54-4acd-a429-8e239a96264d@github.com>
Message-ID: <FZsT_er4j-kT_8RAzMLjXWLLDoYS-v-C71Hj09d5cW8=.df8bc21b-44a5-4557-be77-da82cea208e3@github.com>

On Thu, 19 Jan 2023 20:00:56 GMT, Dan Lutker <duke at openjdk.org> wrote:

> Disabling warnings for bundled Freetype

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12102


From psadhukhan at openjdk.org  Fri Jan 20 06:45:37 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 20 Jan 2023 06:45:37 GMT
Subject: RFR: 8300269: The selected item in an editable JComboBox with
 titled border is not visible in Aqua LAF [v2]
In-Reply-To: <pd2zMoD3rYpG08UI_skEsMLnEEJCGDhz2BcJ6nPD--E=.01ddf417-96a1-4ed3-a1be-20dccf76c6a0@github.com>
References: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>
 <pd2zMoD3rYpG08UI_skEsMLnEEJCGDhz2BcJ6nPD--E=.01ddf417-96a1-4ed3-a1be-20dccf76c6a0@github.com>
Message-ID: <thCTGKlZsifToqClIspUZt9nio7StFwL7cdfCvcKTko=.e99abb0f-6ed4-4a3f-9aed-8c7d55dfc3b7@github.com>

On Thu, 19 Jan 2023 18:12:03 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The fixed height causes the titled border insets to reserve a majority of the height available for the component. This fixed height is meant for the default AquaComboBox usage, so the old default height is more applicable when a border, such as TitledBorder, is set on an Aqua Editable ComboBox.
>> 
>> A conditional to check for a border is added since this is the default for an AquaComboBox using AquaBorder in AquaComboBoxUI's rectangleForCurrentValue() step. A check for any border rather than an instance of a TitledBorder is used because this issue causes changes in other borders as well (I found it for LineBorder for example). 
>> 
>> The editable JComboBox is visible with a LineBorder, but the coordinates of the comboBox are aligned with the top of the arrowButton instead of the bottom (which was the case before the previous fix). So, the method now defaults to the behavior before the fix for any editable comboBox pre-fix if a different border is set.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 460:

> 458:         protected Rectangle rectangleForCurrentValue() {
> 459:             int width = comboBox.getWidth();
> 460:             int height = comboBox.getBorder() == null ? 22 : comboBox.getHeight();

Before JDK-8054572, comboBox.getHeight()+1 was used , shouldn't we use the same if we are going to fallback to previous way with border

`editorRect.height += 1;`

Also, it seems for TitledBorder the popupmenu is not aligned properly. It should have been at the base of the combobox, just as it is for without border...although I don think it's related to this fix but seems to be a bug nevertheless (in Date/Time macos settings, popupmenu for editable combobox is at the base)

![image](https://user-images.githubusercontent.com/43534309/213630526-9cdc5401-d975-4bc3-9cd8-db3a01057d47.png)

=======
Without border

![image](https://user-images.githubusercontent.com/43534309/213632563-6df07625-22f6-4630-9d3b-511b5ff3cadd.png)

test/jdk/javax/swing/JComboBox/JComboBoxWithTitledBorderTest.java line 168:

> 166:         try {
> 167:             final Rectangle screenBounds = new Rectangle(0, 0,
> 168:                     1280, 720);

Probably better to use Toolkit.getScreenSize() for this

-------------

PR: https://git.openjdk.org/jdk/pull/12087


From serb at openjdk.org  Fri Jan 20 08:12:27 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 20 Jan 2023 08:12:27 GMT
Subject: RFR: 8300405: Screen capture for test
 JFileChooserSetLocationTest.java, failure case
In-Reply-To: <H9i4szvE-s7cWX1cu8bkx6nLa3yvB44bftLmYbbfhvM=.a5ae761a-cfe3-4a71-80b2-88bbb6ae7858@github.com>
References: <H9i4szvE-s7cWX1cu8bkx6nLa3yvB44bftLmYbbfhvM=.a5ae761a-cfe3-4a71-80b2-88bbb6ae7858@github.com>
Message-ID: <0NOxQ1_CSyxQUp8B9fHVTWB2336tMohLsAVeNGbkCsY=.6ffbabef-d409-41ec-b777-7de6fa5b2a80@github.com>

On Wed, 18 Jan 2023 06:37:30 GMT, Tejesh R <tr at openjdk.org> wrote:

> This is a diagnostic update related to [JDK-8295804](https://bugs.openjdk.org/browse/JDK-8295804). The issue was not reproducible and was showing up in particular machines (Where the machines are down now). So adding a screen capture to `BufferedImage` in case of failure so that it will help in analysis when the issue comes up in future.

test/jdk/javax/swing/JFileChooser/JFileChooserSetLocationTest.java line 189:

> 187:             System.out.println("Test passed");
> 188:         } else {
> 189:             Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();

I think what you want to use here is the bounds of the screen, not the size, since the screen coordinates may start from non-zero values.

-------------

PR: https://git.openjdk.org/jdk/pull/12060


From aturbanov at openjdk.org  Fri Jan 20 08:23:06 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 20 Jan 2023 08:23:06 GMT
Subject: RFR: 8300731: Avoid unnecessary array fill after creation in
 PaletteBuilder
Message-ID: <K2tj6kSYeWRPjImxPtAXozzzLkwSbg10t22KtEaDVBU=.a44c8fbc-e8ab-4ed8-9d87-79951a5afa3c@github.com>

No need to fill elements of array with `null`: it was just created. Java guarantees that all elements of array are `null`s anyway.

-------------

Commit messages:
 - [PATCH] Avoid unnecessary array fill after creation

Changes: https://git.openjdk.org/jdk/pull/12101/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12101&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300731
  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12101.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12101/head:pull/12101

PR: https://git.openjdk.org/jdk/pull/12101


From duke at openjdk.org  Fri Jan 20 08:23:06 2023
From: duke at openjdk.org (SWinxy)
Date: Fri, 20 Jan 2023 08:23:06 GMT
Subject: RFR: 8300731: Avoid unnecessary array fill after creation in
 PaletteBuilder
In-Reply-To: <K2tj6kSYeWRPjImxPtAXozzzLkwSbg10t22KtEaDVBU=.a44c8fbc-e8ab-4ed8-9d87-79951a5afa3c@github.com>
References: <K2tj6kSYeWRPjImxPtAXozzzLkwSbg10t22KtEaDVBU=.a44c8fbc-e8ab-4ed8-9d87-79951a5afa3c@github.com>
Message-ID: <msMaVZ47hnjDkeIV9mh9VlWIp4h60785KsCTeeCzjnw=.9b217e62-092c-4381-aa75-3cbe26bab0a0@github.com>

On Thu, 19 Jan 2023 19:32:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with `null`: it was just created. Java guarantees that all elements of array are `null`s anyway.

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/12101


From serb at openjdk.org  Fri Jan 20 08:23:06 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 20 Jan 2023 08:23:06 GMT
Subject: RFR: 8300731: Avoid unnecessary array fill after creation in
 PaletteBuilder
In-Reply-To: <K2tj6kSYeWRPjImxPtAXozzzLkwSbg10t22KtEaDVBU=.a44c8fbc-e8ab-4ed8-9d87-79951a5afa3c@github.com>
References: <K2tj6kSYeWRPjImxPtAXozzzLkwSbg10t22KtEaDVBU=.a44c8fbc-e8ab-4ed8-9d87-79951a5afa3c@github.com>
Message-ID: <tzWcbi_lpmgW_hpzutwqgKb4HYgvJYj7_vGVxOygc6E=.b6d2796c-433c-4a73-9d4b-633fed78dfeb@github.com>

On Thu, 19 Jan 2023 19:32:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with `null`: it was just created. Java guarantees that all elements of array are `null`s anyway.

looks fine

-------------

PR: https://git.openjdk.org/jdk/pull/12101


From tr at openjdk.org  Fri Jan 20 09:44:29 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 20 Jan 2023 09:44:29 GMT
Subject: RFR: 8300405: Screen capture for test
 JFileChooserSetLocationTest.java, failure case
In-Reply-To: <0NOxQ1_CSyxQUp8B9fHVTWB2336tMohLsAVeNGbkCsY=.6ffbabef-d409-41ec-b777-7de6fa5b2a80@github.com>
References: <H9i4szvE-s7cWX1cu8bkx6nLa3yvB44bftLmYbbfhvM=.a5ae761a-cfe3-4a71-80b2-88bbb6ae7858@github.com>
 <0NOxQ1_CSyxQUp8B9fHVTWB2336tMohLsAVeNGbkCsY=.6ffbabef-d409-41ec-b777-7de6fa5b2a80@github.com>
Message-ID: <iWjXSjAapcQc8htKJrHeJS2ETnyNwW0ma7u30eZrsR4=.5e3433f2-2b59-4bf0-8d80-530507549280@github.com>

On Fri, 20 Jan 2023 08:09:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is a diagnostic update related to [JDK-8295804](https://bugs.openjdk.org/browse/JDK-8295804). The issue was not reproducible and was showing up in particular machines (Where the machines are down now). So adding a screen capture to `BufferedImage` in case of failure so that it will help in analysis when the issue comes up in future.
>
> test/jdk/javax/swing/JFileChooser/JFileChooserSetLocationTest.java line 189:
> 
>> 187:             System.out.println("Test passed");
>> 188:         } else {
>> 189:             Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
> 
> I think what you want to use here is the bounds of the screen, not the size, since the screen coordinates may start from non-zero values.

GraphicsConfiguration gc = GraphicsEnvironment.
                         getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();
                Rectangle gcBounds = gc.getBounds();

This way?

-------------

PR: https://git.openjdk.org/jdk/pull/12060


From djelinski at openjdk.org  Fri Jan 20 11:52:26 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 20 Jan 2023 11:52:26 GMT
Subject: RFR: 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: <pevQDS3VO_f5MY3ksFmPs45nWZZlAMbIpI21cFg7wBk=.734a182a-641a-4e0c-a1fe-8403c8a29200@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.

In case it helps with the review, most of the fixes do not change the behavior, but make the compiler happy:
- the changes to SAFE_TO_ALLOC: assuming that no negative values are passed to the macros, the end result will be the same (modulo that the SAFE_TO_ALLOC macros should probably use `>=` instead of `>`)
- adding `inline` to `static`: `inline` is a C11 thing, and is generally ignored by the compiler, but `static inline` functions may be unused and plain `static` trigger a warning when unused
- removed a few unused functions, moved `DTrace_PrintStdErr` into `#ifdef DEBUG`
- replaced `double` functions with `float` where the argument was a `float` and the result was stored in a `float`
- fixed the type of `PFNISTHEMEBACKGROUNDPARTIALLYTRANSPARENT` (this was only reported as a warning when compiler was run with `-analyze` parameter) (given that we dropped support for Win7 and older, can we link to uxtheme instead of checking for function availability?)
- removed `extern` on `DMemStatePtr` definition; it is still present on the declaration in header file, and definitions should not be `extern`

The following fixes may change behavior:
- changed `DMem_DumpHeader` to use snprintf, adjusted the buffer size to use what gcc suggested (may avoid crashing on long input)
- fixed error handling in `D3DBlitTextureToSurface` (`d3dc->SetTexture` failures were ignored) (warning only reported with `-analyze`)

-------------

PR: https://git.openjdk.org/jdk/pull/11841


From djelinski at openjdk.org  Fri Jan 20 12:01:06 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 20 Jan 2023 12:01:06 GMT
Subject: RFR: 8299592: Fix and reenable warnings in java.desktop native
 code compilation [v2]
In-Reply-To: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
References: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
Message-ID: <E7Uak5J0FFV1ik7CMYbs3Z87N_15lGVRcs5ZTsBtWhE=.1f760cef-d01b-446f-b6bc-4f7248ddccf0@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 ten commits:

 - 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=01
  Stats: 184 lines in 11 files changed: 2 ins; 120 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/11841.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11841/head:pull/11841

PR: https://git.openjdk.org/jdk/pull/11841


From serb at openjdk.org  Fri Jan 20 15:12:39 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 20 Jan 2023 15:12:39 GMT
Subject: RFR: 8300405: Screen capture for test
 JFileChooserSetLocationTest.java, failure case
In-Reply-To: <iWjXSjAapcQc8htKJrHeJS2ETnyNwW0ma7u30eZrsR4=.5e3433f2-2b59-4bf0-8d80-530507549280@github.com>
References: <H9i4szvE-s7cWX1cu8bkx6nLa3yvB44bftLmYbbfhvM=.a5ae761a-cfe3-4a71-80b2-88bbb6ae7858@github.com>
 <0NOxQ1_CSyxQUp8B9fHVTWB2336tMohLsAVeNGbkCsY=.6ffbabef-d409-41ec-b777-7de6fa5b2a80@github.com>
 <iWjXSjAapcQc8htKJrHeJS2ETnyNwW0ma7u30eZrsR4=.5e3433f2-2b59-4bf0-8d80-530507549280@github.com>
Message-ID: <y1mXha8588A2Q5COj5KR405oPvIXnw6mj6a999x-gKU=.95b9b5be-08bf-43b8-9b9e-641bf037c390@github.com>

On Fri, 20 Jan 2023 09:41:37 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/JFileChooserSetLocationTest.java line 189:
>> 
>>> 187:             System.out.println("Test passed");
>>> 188:         } else {
>>> 189:             Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
>> 
>> I think what you want to use here is the bounds of the screen, not the size, since the screen coordinates may start from non-zero values.
>
> GraphicsConfiguration gc = GraphicsEnvironment.
>                          getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();
>                 Rectangle gcBounds = gc.getBounds();
> 
> This way?

yes.

-------------

PR: https://git.openjdk.org/jdk/pull/12060


From serb at openjdk.org  Fri Jan 20 16:05:10 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 20 Jan 2023 16:05:10 GMT
Subject: Withdrawn: 8280359: Try to remove duplicate code for coordinate
 calculation
In-Reply-To: <UwqaayGxh98sMkmmpxlYvwatXRmkqZ07HTsdL1P2GHg=.1dcd808f-7c2f-4a58-9290-dc1ff40f02ad@github.com>
References: <UwqaayGxh98sMkmmpxlYvwatXRmkqZ07HTsdL1P2GHg=.1dcd808f-7c2f-4a58-9290-dc1ff40f02ad@github.com>
Message-ID: <ALNDaM5HnTgGRHl2muuYAE41J0TPorwtiIjjYNKBdiY=.24278342-b10e-41ac-83d8-a5f7bd1ac67d@github.com>

On Mon, 12 Dec 2022 01:49:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The code from `AccessibilityGraphicsEnvironment` is moved/merged back to the `SunGraphicsEnvironment` from where it was initially [copied](https://github.com/openjdk/jdk18/pull/72#issuecomment-1001050200). The required API is exported from the `sun.java2d` to the `jdk.accessibility`(on WIndows only).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11626


From serb at openjdk.org  Fri Jan 20 16:05:36 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 20 Jan 2023 16:05:36 GMT
Subject: RFR: 8300725: Improve performance of ColorConverOp for default
 destinations with alpha
Message-ID: <SCZI5xDSVmrvfz_JkKISEGXlwqeEb8WTTZm5wnV6HoI=.c939b603-9e76-4685-8254-d7cd1d1973a7@github.com>

The "default destination" for the ColorConverOp is used when the user passes "null" as the DST parameter. In this case, the "ColorConverOp.filter" creates the default image and uses ComponentColorModel: 8 bits per color component and optionally 8 bits for the alpha channel. For example for the ARGB source default destination will be RGBA format. Note that the RGBA format is not supported by BufferedImage directly, so the CUSTOM image type will be used.

Generic filtering of the CUSTOM image type is slow because we cannot pass that format directly to the CMM. But it would be good to support CUSTOM images that were created by the ColorConverOp.

Support of the default destination w/o alpha was implemented as part of the https://bugs.openjdk.org/browse/JDK-8005530. Since then we added support of the alpha to CMM code https://bugs.openjdk.org/browse/JDK-8012229.
Now we can improve the performance of the default destination if it has the alpha channel.

The numbers for filtering opaque and transparent images to the null destination:
<img width="705" alt="8300725" src="https://user-images.githubusercontent.com/14138494/213744370-241726f9-6653-403e-bb90-ce98fc089945.png">

-------------

Commit messages:
 - 8300725: Improve performance of ColorConverOp for default destinations with alpha

Changes: https://git.openjdk.org/jdk/pull/12110/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12110&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300725
  Stats: 74 lines in 3 files changed: 54 ins; 6 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/12110.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12110/head:pull/12110

PR: https://git.openjdk.org/jdk/pull/12110


From prr at openjdk.org  Fri Jan 20 16:27:35 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 20 Jan 2023 16:27:35 GMT
Subject: RFR: 8300725: Improve performance of ColorConverOp for default
 destinations with alpha
In-Reply-To: <SCZI5xDSVmrvfz_JkKISEGXlwqeEb8WTTZm5wnV6HoI=.c939b603-9e76-4685-8254-d7cd1d1973a7@github.com>
References: <SCZI5xDSVmrvfz_JkKISEGXlwqeEb8WTTZm5wnV6HoI=.c939b603-9e76-4685-8254-d7cd1d1973a7@github.com>
Message-ID: <9lKsp2rmX_5lzKR0yX7MO0QqEopmxO3gIXArj-druuQ=.7fe381fb-1eb6-4a36-bd52-ef366a51231b@github.com>

On Fri, 20 Jan 2023 06:02:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "default destination" for the ColorConverOp is used when the user passes "null" as the DST parameter. In this case, the "ColorConverOp.filter" creates the default image and uses ComponentColorModel: 8 bits per color component and optionally 8 bits for the alpha channel. For example for the ARGB source default destination will be RGBA format. Note that the RGBA format is not supported by BufferedImage directly, so the CUSTOM image type will be used.
> 
> Generic filtering of the CUSTOM image type is slow because we cannot pass that format directly to the CMM. But it would be good to support CUSTOM images that were created by the ColorConverOp.
> 
> Support of the default destination w/o alpha was implemented as part of the https://bugs.openjdk.org/browse/JDK-8005530. Since then we added support of the alpha to CMM code https://bugs.openjdk.org/browse/JDK-8012229.
> Now we can improve the performance of the default destination if it has the alpha channel.
> 
> The numbers for filtering opaque and transparent images to the null destination:
> <img width="705" alt="8300725" src="https://user-images.githubusercontent.com/14138494/213744370-241726f9-6653-403e-bb90-ce98fc089945.png">

The results look good.
I'll apply this patch and run all our automated tests. Although I doubt there'll be a failure it is prudent.
Please correct the spelling in the PR title. I already fixed the JBS issue.

-------------

PR: https://git.openjdk.org/jdk/pull/12110


From prr at openjdk.org  Fri Jan 20 19:17:27 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 20 Jan 2023 19:17:27 GMT
Subject: RFR: 8300731: Avoid unnecessary array fill after creation in
 PaletteBuilder
In-Reply-To: <K2tj6kSYeWRPjImxPtAXozzzLkwSbg10t22KtEaDVBU=.a44c8fbc-e8ab-4ed8-9d87-79951a5afa3c@github.com>
References: <K2tj6kSYeWRPjImxPtAXozzzLkwSbg10t22KtEaDVBU=.a44c8fbc-e8ab-4ed8-9d87-79951a5afa3c@github.com>
Message-ID: <PasPFYyQTSowen1p5qBgJmMjdQ6lpdTwR_eRitxb3ic=.fbfa33e8-44ff-46b7-9aea-3eb2ab5156a9@github.com>

On Thu, 19 Jan 2023 19:32:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with `null`: it was just created. Java guarantees that all elements of array are `null`s anyway.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12101


From alexsch at openjdk.org  Fri Jan 20 19:20:40 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Fri, 20 Jan 2023 19:20:40 GMT
Subject: Withdrawn: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows
In-Reply-To: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
Message-ID: <ZkyYasD_LJW89zvaGgUhJYbxW8yvsZT7aGM0k8-S8H8=.c18eec86-585b-496e-8539-a480647bc6d2@github.com>

On Wed, 7 Dec 2022 13:20:10 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> **Environment**: 
> GraalVM 22.3.0 with  jdk 19, Windows OS.
> 
> **Description**:
> Create a native image of Swing application using GraalVM and run it with ` -Dsun.awt.fontconfig=fontconfig.properties.src` java property.
> `java.lang.Error: java.home property not set` error is thrown.
> 
> For more details see https://github.com/oracle/graal/issues/4875.
> 
> **Solution**:
> The error is thrown by the code from [FontConfiguration.findFontConfigFile()](https://github.com/openjdk/jdk19u/blob/c9d485792b99233f381dcdfd69838e7b973909bd/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L175) method.
> GraalVM does not set `java.home`  property, that is why the `java.lang.Error: java.home property not set` is thrown.
> `FontConfiguration.findFontConfigFile()` method compares `java.home` property to null before checking user provided `sun.awt.fontconfig` java property.
> 
> The proposed fix swaps the order of `java.home` and `sun.awt.fontconfig` properties checking to avoid using `java.home` property in case `sun.awt.fontconfig` is set.
> 
> 
> **Steps to reproduce**:
> - Download graal 22.3.0 jdk 19 for Windows from [GraalVM Community Edition 22.3.0](https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0) page.
> - Install native-image
> 
> graalvm-ce-java19-22.3.0\bin\gu.cmd install native-image
> 
> - Create and compile `SwingSample.java` sample
> 
> import java.awt.*;
> import javax.swing.*;
> 
> public class SwingSample {
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeAndWait(() -> {
> 
>             JFrame frame = new JFrame("Hello World");
> 
>             JButton button = new JButton("Hello");
>             button.addActionListener(e -> {
>                 System.out.printf("Hello, World!%n");
>             });
> 
>             JPanel panel = new JPanel(new FlowLayout());
>             panel.add(button);
> 
>             frame.add(panel);
>             frame.setSize(400, 300);
>             frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>             frame.setVisible(true);
>         });
>     }
> }
> 
> - Run native-image-agent to generate configuration files
> 
> graalvm-ce-java19-22.3.0\bin\java.cmd -agentlib:native-image-agent=config-output-dir=conf-dir SwingSample
> 
> - Copy `graalvm-ce-java19-22.3.0\lib\fontconfig.properties.src` file to the sample dir
> - Generate native image with configuration files and `-Djava.awt.headless=false `, `-Dsun.awt.fontconfig=fontconfig.properties.src` java properties
> 
> call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64"
> graalvm-ce-java19-22.3.0\bin\native-image.cmd --no-fallback -Djava.awt.headless=false -Dsun.awt.fontconfig=fontconfig.properties.src -H:ResourceConfigurationFiles=conf-dir/resource-config.json -H:SerializationConfigurationFiles=conf-dir/serialization-config.json -H:ReflectionConfigurationFiles=conf-dir/reflect-config.json -H:JNIConfigurationFiles=conf-dir/jni-config.json SwingSample
> 
> - Run the native image with `-Dsun.awt.fontconfig=fontconfig.properties.src` java property.
> 
> swingsample.exe  -Dsun.awt.fontconfig=fontconfig.properties.src
> 
> Exception in thread "main" java.lang.reflect.InvocationTargetException
>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371)
>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346)
>         at java.desktop at 19.0.1/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480)
>         at SwingSample.main(SwingSample.java:7)
> Caused by: java.lang.Error: java.home property not set
>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
>         at java.desktop at 19.0.1/sun.awt.windows.WFontConfiguration.<init>(WFontConfiguration.java:41)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11559


From prr at openjdk.org  Fri Jan 20 20:17:26 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 20 Jan 2023 20:17:26 GMT
Subject: RFR: 8300725: Improve performance of ColorConvertOp for default
 destinations with alpha
In-Reply-To: <SCZI5xDSVmrvfz_JkKISEGXlwqeEb8WTTZm5wnV6HoI=.c939b603-9e76-4685-8254-d7cd1d1973a7@github.com>
References: <SCZI5xDSVmrvfz_JkKISEGXlwqeEb8WTTZm5wnV6HoI=.c939b603-9e76-4685-8254-d7cd1d1973a7@github.com>
Message-ID: <qHWdE5t7JqiW1_O8NpFIAO9hC2fvl5B1BZI0gKTD0iE=.a44380c6-ac1f-4f82-acb8-e2311ffd25d0@github.com>

On Fri, 20 Jan 2023 06:02:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "default destination" for the ColorConverOp is used when the user passes "null" as the DST parameter. In this case, the "ColorConverOp.filter" creates the default image and uses ComponentColorModel: 8 bits per color component and optionally 8 bits for the alpha channel. For example for the ARGB source default destination will be RGBA format. Note that the RGBA format is not supported by BufferedImage directly, so the CUSTOM image type will be used.
> 
> Generic filtering of the CUSTOM image type is slow because we cannot pass that format directly to the CMM. But it would be good to support CUSTOM images that were created by the ColorConverOp.
> 
> Support of the default destination w/o alpha was implemented as part of the https://bugs.openjdk.org/browse/JDK-8005530. Since then we added support of the alpha to CMM code https://bugs.openjdk.org/browse/JDK-8012229.
> Now we can improve the performance of the default destination if it has the alpha channel.
> 
> The numbers for filtering opaque and transparent images to the null destination:
> <img width="705" alt="8300725" src="https://user-images.githubusercontent.com/14138494/213744370-241726f9-6653-403e-bb90-ce98fc089945.png">

all tests passed

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12110


From serb at openjdk.org  Fri Jan 20 20:20:32 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 20 Jan 2023 20:20:32 GMT
Subject: RFR: 8299333: Unify exceptions used by all variants of
 ICC_Profile.getInstance(null) [v2]
In-Reply-To: <vcJUwGyej8Uk8AQC25VHJib-Tn0MMDATnf8H3JEZygQ=.8212bab6-583d-4e8b-9dce-15a94ef52c39@github.com>
References: <vcJUwGyej8Uk8AQC25VHJib-Tn0MMDATnf8H3JEZygQ=.8212bab6-583d-4e8b-9dce-15a94ef52c39@github.com>
Message-ID: <n1X_Q5o8h9ZPLX9GJXNA-S8RlaHYihgoljl3ybocxCE=.5837e7aa-cf06-4f88-9c06-30971035a564@github.com>

> I tried to clean up the documentation in the `java.awt.color` package and specify how the `null` parameters are handled here and there. But it looks like the `ICC_profile` class is too specific so I would like to discuss it separately.
> 
> The ICC_Profile has these methods:
>  * `getInstance(int)`      - always throws specified `IllegalArgumentException` on the wrong constant
>  * `getInstance(byte[])` - always throws specified `IllegalArgumentException` on `null`
>  * `getInstance(String fileName)` - always throws unspecified `NullPointerException` on `null`
>  * `getInstance(InputStream)`      - thrown unspecified `NullPointerException` before [JDK-8227816](https://github.com/openjdk/jdk/commit/af20c6b9c4a3a21c1e2c7f56721e1077e7d8f388) and now throws specified but misleading `IOException: Stream closed` exception on `null`
> 
> So we have 3 methods that can get null as a parameter and each throw a different exception.
> 
> Note that all of the specs for the methods above have this part:
> 
>> @throws IllegalArgumentException If the stream does not contain valid ICC Profile data
> 
> So I have an idea to change `getInstance(String)` and `getInstance(InputStream)` to throw `IllegalArgumentException`  even if I personally prefer NPE to be thrown.
> 
> From another point of view the `ICC_Profile` profile has other methods:
>  * `write(String fileName)` - always throws unspecified `NullPointerException` on `null`
>  * `write(OutputStream) `  - always throws unspecified `NullPointerException` on `null`
> 
> I am not sure we can throw `IllegalArgumentException` from the `write` methods, so the specification for `getInstance(String)` and `getInstance(InputStream)` could be updated to throw NPE on null same as related `write`.
> 
> Thoughts?

Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision:

 - Unify pairs for filenames and streams
 - Revert "8299333: Unify used exceptions by all variants of ICC_Profile.getInstance(null)"
   
   This reverts commit db5cfdc280c00e38949469f9bc6fcb3d06a12716.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11784/files
  - new: https://git.openjdk.org/jdk/pull/11784/files/db5cfdc2..9f7afa23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11784&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11784&range=00-01

  Stats: 107 lines in 3 files changed: 76 ins; 24 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11784.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11784/head:pull/11784

PR: https://git.openjdk.org/jdk/pull/11784


From serb at openjdk.org  Fri Jan 20 20:20:33 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 20 Jan 2023 20:20:33 GMT
Subject: RFR: 8299333: Unify exceptions used by all variants of
 ICC_Profile.getInstance(null)
In-Reply-To: <vcJUwGyej8Uk8AQC25VHJib-Tn0MMDATnf8H3JEZygQ=.8212bab6-583d-4e8b-9dce-15a94ef52c39@github.com>
References: <vcJUwGyej8Uk8AQC25VHJib-Tn0MMDATnf8H3JEZygQ=.8212bab6-583d-4e8b-9dce-15a94ef52c39@github.com>
Message-ID: <T0_ggNazV6OobCx9OdW5xntAirSpqs6BpG2OMfZsS70=.00a70321-21e9-4490-8fbe-89055b93e7c7@github.com>

On Fri, 23 Dec 2022 23:32:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I tried to clean up the documentation in the `java.awt.color` package and specify how the `null` parameters are handled here and there. But it looks like the `ICC_profile` class is too specific so I would like to discuss it separately.
> 
> The ICC_Profile has these methods:
>  * `getInstance(int)`      - always throws specified `IllegalArgumentException` on the wrong constant
>  * `getInstance(byte[])` - always throws specified `IllegalArgumentException` on `null`
>  * `getInstance(String fileName)` - always throws unspecified `NullPointerException` on `null`
>  * `getInstance(InputStream)`      - thrown unspecified `NullPointerException` before [JDK-8227816](https://github.com/openjdk/jdk/commit/af20c6b9c4a3a21c1e2c7f56721e1077e7d8f388) and now throws specified but misleading `IOException: Stream closed` exception on `null`
> 
> So we have 3 methods that can get null as a parameter and each throw a different exception.
> 
> Note that all of the specs for the methods above have this part:
> 
>> @throws IllegalArgumentException If the stream does not contain valid ICC Profile data
> 
> So I have an idea to change `getInstance(String)` and `getInstance(InputStream)` to throw `IllegalArgumentException`  even if I personally prefer NPE to be thrown.
> 
> From another point of view the `ICC_Profile` profile has other methods:
>  * `write(String fileName)` - always throws unspecified `NullPointerException` on `null`
>  * `write(OutputStream) `  - always throws unspecified `NullPointerException` on `null`
> 
> I am not sure we can throw `IllegalArgumentException` from the `write` methods, so the specification for `getInstance(String)` and `getInstance(InputStream)` could be updated to throw NPE on null same as related `write`.
> 
> Thoughts?

Something like this?

-------------

PR: https://git.openjdk.org/jdk/pull/11784


From prr at openjdk.org  Fri Jan 20 20:44:05 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 20 Jan 2023 20:44:05 GMT
Subject: RFR: 8299333: Unify exceptions used by all variants of
 ICC_Profile.getInstance(null)
In-Reply-To: <T0_ggNazV6OobCx9OdW5xntAirSpqs6BpG2OMfZsS70=.00a70321-21e9-4490-8fbe-89055b93e7c7@github.com>
References: <vcJUwGyej8Uk8AQC25VHJib-Tn0MMDATnf8H3JEZygQ=.8212bab6-583d-4e8b-9dce-15a94ef52c39@github.com>
 <T0_ggNazV6OobCx9OdW5xntAirSpqs6BpG2OMfZsS70=.00a70321-21e9-4490-8fbe-89055b93e7c7@github.com>
Message-ID: <D453eMegnoItQbhVLcMO9cFNS0TNxmhEhMqgwted-R8=.a9826ec2-e703-4b2a-82a1-37a40178d82e@github.com>

On Fri, 20 Jan 2023 20:16:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Something like this?

Yes.

If you file the CSR I will review it.
But I  also want to run a test job to see if there are any tests that need adjusting or excluding.

-------------

PR: https://git.openjdk.org/jdk/pull/11784


From dnguyen at openjdk.org  Fri Jan 20 21:27:23 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 20 Jan 2023 21:27:23 GMT
Subject: RFR: 8300269: The selected item in an editable JComboBox with
 titled border is not visible in Aqua LAF [v2]
In-Reply-To: <thCTGKlZsifToqClIspUZt9nio7StFwL7cdfCvcKTko=.e99abb0f-6ed4-4a3f-9aed-8c7d55dfc3b7@github.com>
References: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>
 <pd2zMoD3rYpG08UI_skEsMLnEEJCGDhz2BcJ6nPD--E=.01ddf417-96a1-4ed3-a1be-20dccf76c6a0@github.com>
 <thCTGKlZsifToqClIspUZt9nio7StFwL7cdfCvcKTko=.e99abb0f-6ed4-4a3f-9aed-8c7d55dfc3b7@github.com>
Message-ID: <40FzSk4MuKAFvcvF3gUQwNx9SWlXe4KOa-0L6QpyQPQ=.fccffd0a-09b3-445e-90d9-c840cf1b360f@github.com>

On Fri, 20 Jan 2023 06:41:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 460:
> 
>> 458:         protected Rectangle rectangleForCurrentValue() {
>> 459:             int width = comboBox.getWidth();
>> 460:             int height = comboBox.getBorder() == null ? 22 : comboBox.getHeight();
> 
> Before JDK-8054572, comboBox.getHeight()+1 was used , shouldn't we use the same if we are going to fallback to previous way with border
> 
> `editorRect.height += 1;`
> 
> Also, it seems for TitledBorder the popupmenu is not aligned properly. It should have been at the base of the combobox, just as it is for without border...although I don think it's related to this fix but seems to be a bug nevertheless (in Date/Time macos settings, popupmenu for editable combobox is at the base)
> 
> ![image](https://user-images.githubusercontent.com/43534309/213630526-9cdc5401-d975-4bc3-9cd8-db3a01057d47.png)
> 
> =======
> Without border
> 
> ![image](https://user-images.githubusercontent.com/43534309/213632563-6df07625-22f6-4630-9d3b-511b5ff3cadd.png)

Adding 1 to the height would go back to the previous implementation, but it actually causes the comboBox to look more misaligned by 1 extra pixel. I can re-add the +1 to return to the original method if preferred.

<img width="63" alt="Screen Shot 2023-01-20 at 12 54 47 PM" src="https://user-images.githubusercontent.com/96267980/213807706-81de1e18-8922-43f4-8313-72d8332a20b1.png">

I see the popup issue on my end as well. But this seems to be unrelated to the fix as you mentioned. I can create a separate JBS issue for this if needed.

-------------

PR: https://git.openjdk.org/jdk/pull/12087


From serb at openjdk.org  Fri Jan 20 22:22:08 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 20 Jan 2023 22:22:08 GMT
Subject: RFR: 8300731: Avoid unnecessary array fill after creation in
 PaletteBuilder
In-Reply-To: <K2tj6kSYeWRPjImxPtAXozzzLkwSbg10t22KtEaDVBU=.a44c8fbc-e8ab-4ed8-9d87-79951a5afa3c@github.com>
References: <K2tj6kSYeWRPjImxPtAXozzzLkwSbg10t22KtEaDVBU=.a44c8fbc-e8ab-4ed8-9d87-79951a5afa3c@github.com>
Message-ID: <hCESd-NSA0nud-2dElHziLiF_AiqX-bHMGGApg2SNeA=.c089e091-f026-4449-b492-e0ae8d78c5ae@github.com>

On Thu, 19 Jan 2023 19:32:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with `null`: it was just created. Java guarantees that all elements of array are `null`s anyway.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12101


From dnguyen at openjdk.org  Fri Jan 20 22:45:32 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 20 Jan 2023 22:45:32 GMT
Subject: RFR: 8300269: The selected item in an editable JComboBox with
 titled border is not visible in Aqua LAF [v3]
In-Reply-To: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>
References: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>
Message-ID: <fsiHv4-VagNQz4LMmOYH1_WT55MDE4jFLrtuDBq2Eyw=.9431fbc1-45af-48b9-8de3-f8b34a9f3515@github.com>

> The fixed height causes the titled border insets to reserve a majority of the height available for the component. This fixed height is meant for the default AquaComboBox usage, so the old default height is more applicable when a border, such as TitledBorder, is set on an Aqua Editable ComboBox.
> 
> A conditional to check for a border is added since this is the default for an AquaComboBox using AquaBorder in AquaComboBoxUI's rectangleForCurrentValue() step. A check for any border rather than an instance of a TitledBorder is used because this issue causes changes in other borders as well (I found it for LineBorder for example). 
> 
> The editable JComboBox is visible with a LineBorder, but the coordinates of the comboBox are aligned with the top of the arrowButton instead of the bottom (which was the case before the previous fix). So, the method now defaults to the behavior before the fix for any editable comboBox pre-fix if a different border is set.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Change bounds to toolkit screen size

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12087/files
  - new: https://git.openjdk.org/jdk/pull/12087/files/c093ef7a..5f6fc71f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12087&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12087&range=01-02

  Stats: 6 lines in 1 file changed: 3 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12087.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12087/head:pull/12087

PR: https://git.openjdk.org/jdk/pull/12087


From dnguyen at openjdk.org  Fri Jan 20 22:45:33 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 20 Jan 2023 22:45:33 GMT
Subject: RFR: 8300269: The selected item in an editable JComboBox with
 titled border is not visible in Aqua LAF [v2]
In-Reply-To: <thCTGKlZsifToqClIspUZt9nio7StFwL7cdfCvcKTko=.e99abb0f-6ed4-4a3f-9aed-8c7d55dfc3b7@github.com>
References: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>
 <pd2zMoD3rYpG08UI_skEsMLnEEJCGDhz2BcJ6nPD--E=.01ddf417-96a1-4ed3-a1be-20dccf76c6a0@github.com>
 <thCTGKlZsifToqClIspUZt9nio7StFwL7cdfCvcKTko=.e99abb0f-6ed4-4a3f-9aed-8c7d55dfc3b7@github.com>
Message-ID: <F-LivV6mVa-CTIh6QI__n0v4wQxyfvxRNC__5MG4sKk=.6917f0d9-f362-4191-b176-b45167b09577@github.com>

On Fri, 20 Jan 2023 06:41:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test
>
> test/jdk/javax/swing/JComboBox/JComboBoxWithTitledBorderTest.java line 168:
> 
>> 166:         try {
>> 167:             final Rectangle screenBounds = new Rectangle(0, 0,
>> 168:                     1280, 720);
> 
> Probably better to use Toolkit.getScreenSize() for this

Updated

-------------

PR: https://git.openjdk.org/jdk/pull/12087


From duke at openjdk.org  Fri Jan 20 23:39:19 2023
From: duke at openjdk.org (Dan Lutker)
Date: Fri, 20 Jan 2023 23:39:19 GMT
Subject: RFR: 8300692: GCC 12 reports some compiler warnings in bundled
 freetype [v2]
In-Reply-To: <lrtV6uGXgoi4gTbbdgTuDQwGz8RlxK33JQDnCSARDQ0=.217ef880-2b54-4acd-a429-8e239a96264d@github.com>
References: <lrtV6uGXgoi4gTbbdgTuDQwGz8RlxK33JQDnCSARDQ0=.217ef880-2b54-4acd-a429-8e239a96264d@github.com>
Message-ID: <pu5ihkMS58z4wzuVJu7_nRG0n7i1fj48RVQyPpUEFa0=.9ed5e458-9fd7-4407-b6c5-2cea0b26865b@github.com>

> Disabling warnings for bundled Freetype

Dan Lutker has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'openjdk:master' into 8300692
 - 8300692: GCC 12 reports some compiler warnings in bundled freetype

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12102/files
  - new: https://git.openjdk.org/jdk/pull/12102/files/8e12c4b8..f4c0601a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12102&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12102&range=00-01

  Stats: 2043 lines in 102 files changed: 663 ins; 382 del; 998 mod
  Patch: https://git.openjdk.org/jdk/pull/12102.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12102/head:pull/12102

PR: https://git.openjdk.org/jdk/pull/12102


From duke at openjdk.org  Fri Jan 20 23:47:37 2023
From: duke at openjdk.org (Dan Lutker)
Date: Fri, 20 Jan 2023 23:47:37 GMT
Subject: RFR: 8300692: GCC 12 reports some compiler warnings in bundled
 freetype [v3]
In-Reply-To: <lrtV6uGXgoi4gTbbdgTuDQwGz8RlxK33JQDnCSARDQ0=.217ef880-2b54-4acd-a429-8e239a96264d@github.com>
References: <lrtV6uGXgoi4gTbbdgTuDQwGz8RlxK33JQDnCSARDQ0=.217ef880-2b54-4acd-a429-8e239a96264d@github.com>
Message-ID: <si9w-vpHMjV8NHEFR6AvoRhxKLXAeR5chL1Igv7Z3mY=.ea5566dd-2d17-4a67-b521-9c8dcf9442d7@github.com>

> Disabling warnings for bundled Freetype

Dan Lutker 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.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12102/files
  - new: https://git.openjdk.org/jdk/pull/12102/files/f4c0601a..8e12c4b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12102&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12102&range=01-02

  Stats: 2043 lines in 102 files changed: 382 ins; 663 del; 998 mod
  Patch: https://git.openjdk.org/jdk/pull/12102.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12102/head:pull/12102

PR: https://git.openjdk.org/jdk/pull/12102


From duke at openjdk.org  Sat Jan 21 00:14:05 2023
From: duke at openjdk.org (Dan Lutker)
Date: Sat, 21 Jan 2023 00:14:05 GMT
Subject: RFR: 8300692: GCC 12 reports some compiler warnings in bundled
 freetype [v3]
In-Reply-To: <si9w-vpHMjV8NHEFR6AvoRhxKLXAeR5chL1Igv7Z3mY=.ea5566dd-2d17-4a67-b521-9c8dcf9442d7@github.com>
References: <lrtV6uGXgoi4gTbbdgTuDQwGz8RlxK33JQDnCSARDQ0=.217ef880-2b54-4acd-a429-8e239a96264d@github.com>
 <si9w-vpHMjV8NHEFR6AvoRhxKLXAeR5chL1Igv7Z3mY=.ea5566dd-2d17-4a67-b521-9c8dcf9442d7@github.com>
Message-ID: <tecXrwT-qJQfXgqzRWrWe3N6xRpP8hqdpyrd3WDjHLg=.c1ba250f-a286-49e5-9e1b-c5f43ec55e19@github.com>

On Fri, 20 Jan 2023 23:47:37 GMT, Dan Lutker <duke at openjdk.org> wrote:

>> Disabling warnings for bundled Freetype
>
> Dan Lutker has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8300692: GCC 12 reports some compiler warnings in bundled freetype

hs/tier1 compiler tests are passing locally and seem to also be failing in many of the other PRs open right now

-------------

PR: https://git.openjdk.org/jdk/pull/12102


From prr at openjdk.org  Sat Jan 21 02:07:05 2023
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Jan 2023 02:07:05 GMT
Subject: RFR: 8299333: Unify exceptions used by all variants of
 ICC_Profile.getInstance(null) [v2]
In-Reply-To: <n1X_Q5o8h9ZPLX9GJXNA-S8RlaHYihgoljl3ybocxCE=.5837e7aa-cf06-4f88-9c06-30971035a564@github.com>
References: <vcJUwGyej8Uk8AQC25VHJib-Tn0MMDATnf8H3JEZygQ=.8212bab6-583d-4e8b-9dce-15a94ef52c39@github.com>
 <n1X_Q5o8h9ZPLX9GJXNA-S8RlaHYihgoljl3ybocxCE=.5837e7aa-cf06-4f88-9c06-30971035a564@github.com>
Message-ID: <J17mFhJnPOicyb0rrOgd6R5Lg9sQkd9OKfFLhP-MAq0=.a418d9c9-81e8-4895-819a-81dcb9bb58ea@github.com>

On Fri, 20 Jan 2023 20:20:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I tried to clean up the documentation in the `java.awt.color` package and specify how the `null` parameters are handled here and there. But it looks like the `ICC_profile` class is too specific so I would like to discuss it separately.
>> 
>> The ICC_Profile has these methods:
>>  * `getInstance(int)`      - always throws specified `IllegalArgumentException` on the wrong constant
>>  * `getInstance(byte[])` - always throws specified `IllegalArgumentException` on `null`
>>  * `getInstance(String fileName)` - always throws unspecified `NullPointerException` on `null`
>>  * `getInstance(InputStream)`      - thrown unspecified `NullPointerException` before [JDK-8227816](https://github.com/openjdk/jdk/commit/af20c6b9c4a3a21c1e2c7f56721e1077e7d8f388) and now throws specified but misleading `IOException: Stream closed` exception on `null`
>> 
>> So we have 3 methods that can get null as a parameter and each throw a different exception.
>> 
>> Note that all of the specs for the methods above have this part:
>> 
>>> @throws IllegalArgumentException If the stream does not contain valid ICC Profile data
>> 
>> So I have an idea to change `getInstance(String)` and `getInstance(InputStream)` to throw `IllegalArgumentException`  even if I personally prefer NPE to be thrown.
>> 
>> From another point of view the `ICC_Profile` profile has other methods:
>>  * `write(String fileName)` - always throws unspecified `NullPointerException` on `null`
>>  * `write(OutputStream) `  - always throws unspecified `NullPointerException` on `null`
>> 
>> I am not sure we can throw `IllegalArgumentException` from the `write` methods, so the specification for `getInstance(String)` and `getInstance(InputStream)` could be updated to throw NPE on null same as related `write`.
>> 
>> Thoughts?
>
> Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Unify pairs for filenames and streams
>  - Revert "8299333: Unify used exceptions by all variants of ICC_Profile.getInstance(null)"
>    
>    This reverts commit db5cfdc280c00e38949469f9bc6fcb3d06a12716.

So there are 3 TCK tests for the behaviour of getInstance(InputStream) which expect the specified IOException or an IAE in the event the arg is null.
It will fail if we throw NPE (ie these 3 tests fail on all platforms with  your change)
Interestingly at one point at least one of these expected NPE which probably got fixed because it wasn't the specified behaviour. I expect it'll make JCK very happy to be validated that NPE was better :-)

-------------

PR: https://git.openjdk.org/jdk/pull/11784


From duke at openjdk.org  Sat Jan 21 03:15:47 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sat, 21 Jan 2023 03:15:47 GMT
Subject: RFR: 8299497: Usage of constructors of primitive wrapper classes
 should be avoided in java.desktop API docs
Message-ID: <P9dJXgEvyMRwKbqoZjhPf_7CtvxlDXZAWUd7QisG-cg=.2044dd48-e625-428e-99f5-5405004fb24d@github.com>

API docs of `java.awt.image.renderable.ParameterBlock` and `java.awt.font.LineBreakMeasurer` used deprecated constructors of `java.lang.Short` and `java.lang.Float`.

Replacing by `valueOf` factory methods.

-------------

Commit messages:
 - Update LineBreakMeasurer.java
 - Update ParameterBlock.java
 - Update LineBreakMeasurer.java

Changes: https://git.openjdk.org/jdk/pull/12128/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12128&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299497
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12128.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12128/head:pull/12128

PR: https://git.openjdk.org/jdk/pull/12128


From serb at openjdk.org  Sat Jan 21 04:21:04 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 21 Jan 2023 04:21:04 GMT
Subject: RFR: 8299333: Unify exceptions used by all variants of
 ICC_Profile.getInstance(null) [v2]
In-Reply-To: <J17mFhJnPOicyb0rrOgd6R5Lg9sQkd9OKfFLhP-MAq0=.a418d9c9-81e8-4895-819a-81dcb9bb58ea@github.com>
References: <vcJUwGyej8Uk8AQC25VHJib-Tn0MMDATnf8H3JEZygQ=.8212bab6-583d-4e8b-9dce-15a94ef52c39@github.com>
 <n1X_Q5o8h9ZPLX9GJXNA-S8RlaHYihgoljl3ybocxCE=.5837e7aa-cf06-4f88-9c06-30971035a564@github.com>
 <J17mFhJnPOicyb0rrOgd6R5Lg9sQkd9OKfFLhP-MAq0=.a418d9c9-81e8-4895-819a-81dcb9bb58ea@github.com>
Message-ID: <7nIYapaH_0HURk4X157KEsjxEf5ZtrcUN_ax7HY4wc4=.f657f417-1c96-4911-ad73-f27f3a3b9f5d@github.com>

On Sat, 21 Jan 2023 02:03:57 GMT, Phil Race <prr at openjdk.org> wrote:

> So there are 3 TCK tests for the behaviour of getInstance(InputStream) which expect the specified IOException or an IAE in the event the arg is null. It will fail if we throw NPE (ie these 3 tests fail on all platforms with your change) Interestingly at one point at least one of these expected NPE which probably got fixed because it wasn't the specified behaviour. I expect it'll make JCK very happy to be validated that NPE was better :-)

Yes, I remember that test that expected the unspecified NPE and then we changed that to the IOException

-------------

PR: https://git.openjdk.org/jdk/pull/11784


From serb at openjdk.org  Sat Jan 21 07:17:07 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 21 Jan 2023 07:17:07 GMT
Subject: Integrated: 8300725: Improve performance of ColorConvertOp for default
 destinations with alpha
In-Reply-To: <SCZI5xDSVmrvfz_JkKISEGXlwqeEb8WTTZm5wnV6HoI=.c939b603-9e76-4685-8254-d7cd1d1973a7@github.com>
References: <SCZI5xDSVmrvfz_JkKISEGXlwqeEb8WTTZm5wnV6HoI=.c939b603-9e76-4685-8254-d7cd1d1973a7@github.com>
Message-ID: <kV6VuWFcS_U9pv8pQUrHAy-FBct-iHpBL83q853h1Ao=.3c3227f6-3239-47c9-bd6d-6bc7828b0a13@github.com>

On Fri, 20 Jan 2023 06:02:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "default destination" for the ColorConverOp is used when the user passes "null" as the DST parameter. In this case, the "ColorConverOp.filter" creates the default image and uses ComponentColorModel: 8 bits per color component and optionally 8 bits for the alpha channel. For example for the ARGB source default destination will be RGBA format. Note that the RGBA format is not supported by BufferedImage directly, so the CUSTOM image type will be used.
> 
> Generic filtering of the CUSTOM image type is slow because we cannot pass that format directly to the CMM. But it would be good to support CUSTOM images that were created by the ColorConverOp.
> 
> Support of the default destination w/o alpha was implemented as part of the https://bugs.openjdk.org/browse/JDK-8005530. Since then we added support of the alpha to CMM code https://bugs.openjdk.org/browse/JDK-8012229.
> Now we can improve the performance of the default destination if it has the alpha channel.
> 
> The numbers for filtering opaque and transparent images to the null destination:
> <img width="705" alt="8300725" src="https://user-images.githubusercontent.com/14138494/213744370-241726f9-6653-403e-bb90-ce98fc089945.png">

This pull request has now been integrated.

Changeset: e1ee6727
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e1ee6727f70209cf046cafba109835ad4acc1c23
Stats:     74 lines in 3 files changed: 54 ins; 6 del; 14 mod

8300725: Improve performance of ColorConvertOp for default destinations with alpha

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/12110


From lbourges at openjdk.org  Sat Jan 21 08:48:12 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sat, 21 Jan 2023 08:48:12 GMT
Subject: RFR: 8300725: Improve performance of ColorConvertOp for default
 destinations with alpha
In-Reply-To: <SCZI5xDSVmrvfz_JkKISEGXlwqeEb8WTTZm5wnV6HoI=.c939b603-9e76-4685-8254-d7cd1d1973a7@github.com>
References: <SCZI5xDSVmrvfz_JkKISEGXlwqeEb8WTTZm5wnV6HoI=.c939b603-9e76-4685-8254-d7cd1d1973a7@github.com>
Message-ID: <TCOspsb6dEDmHvkmgWDQEffMZOivwE_Amezx_94nzFY=.cfc0bf58-40dd-4a8e-9158-f63f4303853d@github.com>

On Fri, 20 Jan 2023 06:02:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "default destination" for the ColorConverOp is used when the user passes "null" as the DST parameter. In this case, the "ColorConverOp.filter" creates the default image and uses ComponentColorModel: 8 bits per color component and optionally 8 bits for the alpha channel. For example for the ARGB source default destination will be RGBA format. Note that the RGBA format is not supported by BufferedImage directly, so the CUSTOM image type will be used.
> 
> Generic filtering of the CUSTOM image type is slow because we cannot pass that format directly to the CMM. But it would be good to support CUSTOM images that were created by the ColorConverOp.
> 
> Support of the default destination w/o alpha was implemented as part of the https://bugs.openjdk.org/browse/JDK-8005530. Since then we added support of the alpha to CMM code https://bugs.openjdk.org/browse/JDK-8012229.
> Now we can improve the performance of the default destination if it has the alpha channel.
> 
> The numbers for filtering opaque and transparent images to the null destination:
> <img width="705" alt="8300725" src="https://user-images.githubusercontent.com/14138494/213744370-241726f9-6653-403e-bb90-ce98fc089945.png">

Congratulations, it is amazing!

Would it be possible to add support for INT_BGRA_PREMUL as supported by skia default raster N32 format?

Of course I cab help but not alone as it means many changes in C macros & backends + CSR request ...

-------------

PR: https://git.openjdk.org/jdk/pull/12110


From jwaters at openjdk.org  Sat Jan 21 11:59:07 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 21 Jan 2023 11:59:07 GMT
Subject: RFR: 8300692: GCC 12 reports some compiler warnings in bundled
 freetype [v3]
In-Reply-To: <si9w-vpHMjV8NHEFR6AvoRhxKLXAeR5chL1Igv7Z3mY=.ea5566dd-2d17-4a67-b521-9c8dcf9442d7@github.com>
References: <lrtV6uGXgoi4gTbbdgTuDQwGz8RlxK33JQDnCSARDQ0=.217ef880-2b54-4acd-a429-8e239a96264d@github.com>
 <si9w-vpHMjV8NHEFR6AvoRhxKLXAeR5chL1Igv7Z3mY=.ea5566dd-2d17-4a67-b521-9c8dcf9442d7@github.com>
Message-ID: <CSn5y-jQ-unrWzKtMoYwDLPAY69ItFbHaGFcJX7NiKI=.17a55247-6595-4d79-969d-505470d260e1@github.com>

On Fri, 20 Jan 2023 23:47:37 GMT, Dan Lutker <duke at openjdk.org> wrote:

>> Disabling warnings for bundled Freetype
>
> Dan Lutker has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8300692: GCC 12 reports some compiler warnings in bundled freetype

Marked as reviewed by jwaters (Committer).

Was facing this issue just yesterday, thanks for the fix :P
Can confirm the failures are related to JIT Compiler IR issues

-------------

PR: https://git.openjdk.org/jdk/pull/12102


From duke at openjdk.org  Sat Jan 21 12:14:09 2023
From: duke at openjdk.org (Dan Lutker)
Date: Sat, 21 Jan 2023 12:14:09 GMT
Subject: Integrated: 8300692: GCC 12 reports some compiler warnings in bundled
 freetype
In-Reply-To: <lrtV6uGXgoi4gTbbdgTuDQwGz8RlxK33JQDnCSARDQ0=.217ef880-2b54-4acd-a429-8e239a96264d@github.com>
References: <lrtV6uGXgoi4gTbbdgTuDQwGz8RlxK33JQDnCSARDQ0=.217ef880-2b54-4acd-a429-8e239a96264d@github.com>
Message-ID: <lATbEo62c_FWSoLA_KaMJs2TA6-716YgMiS8hhHpYHE=.51fd5454-fe9e-496f-86b5-b6b45a32e559@github.com>

On Thu, 19 Jan 2023 20:00:56 GMT, Dan Lutker <duke at openjdk.org> wrote:

> Disabling warnings for bundled Freetype

This pull request has now been integrated.

Changeset: a6c2a2ae
Author:    Dan Lutker <lutkerd at amazon.com>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6c2a2ae79be6810dca55b13bfc8a7625f25d48d
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8300692: GCC 12 reports some compiler warnings in bundled freetype

Reviewed-by: erikj, serb, jwaters

-------------

PR: https://git.openjdk.org/jdk/pull/12102


From duke at openjdk.org  Sat Jan 21 18:18:11 2023
From: duke at openjdk.org (ScientificWare)
Date: Sat, 21 Jan 2023 18:18:11 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v23]
In-Reply-To: <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
Message-ID: <muHGFzojNURqpUi7mtVX8c48gXietTq4Jha_mEEET7M=.942543f9-d3ba-47be-b3cc-3be1326feb42@github.com>

On Wed, 28 Sep 2022 17:13:42 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:
> 
>    Moves jtreg tags to the class declaration
>   
>   Comment with tags isn't collapsed when viewed in an IDE if it's placed before the class declaration.

Still waiting a review.

-------------

PR: https://git.openjdk.org/jdk/pull/9825


From aturbanov at openjdk.org  Sat Jan 21 19:33:09 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 21 Jan 2023 19:33:09 GMT
Subject: Integrated: 8300731: Avoid unnecessary array fill after creation in
 PaletteBuilder
In-Reply-To: <K2tj6kSYeWRPjImxPtAXozzzLkwSbg10t22KtEaDVBU=.a44c8fbc-e8ab-4ed8-9d87-79951a5afa3c@github.com>
References: <K2tj6kSYeWRPjImxPtAXozzzLkwSbg10t22KtEaDVBU=.a44c8fbc-e8ab-4ed8-9d87-79951a5afa3c@github.com>
Message-ID: <7ywnIwRzok4IafvXP33PVLxeDiJRep92kt8ngjhzZoM=.7eb69702-7eeb-43e0-9589-34a672c26a21@github.com>

On Thu, 19 Jan 2023 19:32:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with `null`: it was just created. Java guarantees that all elements of array are `null`s anyway.

This pull request has now been integrated.

Changeset: cbfc069f
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cbfc069f6a27b272577ddf2abfbc7a3b64739571
Stats:     4 lines in 1 file changed: 0 ins; 3 del; 1 mod

8300731: Avoid unnecessary array fill after creation in PaletteBuilder

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/12101


From serb at openjdk.org  Sun Jan 22 16:20:03 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 22 Jan 2023 16:20:03 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <ml5KnXSuRa1uWxhC6_U3YcK8SlkCOlVIx18M6bVpnOQ=.ff55dd4d-66ef-4731-9d85-2f6677db84d2@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
 <ml5KnXSuRa1uWxhC6_U3YcK8SlkCOlVIx18M6bVpnOQ=.ff55dd4d-66ef-4731-9d85-2f6677db84d2@github.com>
Message-ID: <ZeqUIXZYGAzYQpthfKtbfF6K2l5OMjtSh_XbW0uXMTk=.0eafb053-ddc6-4392-a5c9-630f666c3380@github.com>

On Mon, 16 Jan 2023 19:28:05 GMT, SWinxy <duke at openjdk.org> wrote:

>As they ought to. All UI classes assume that the source for the property listener is the component it is the delegate for, which is why we see some classes passing e.getSource() and others passing the protected field. It's not something we can test, because the issues will arise when other people invoke the listener, and the JDK code doesn't (seem to) directly call it. 

It is called t notify the listener since we added the UI delegate to the list:

-------------

PR: https://git.openjdk.org/jdk/pull/11875


From serb at openjdk.org  Sun Jan 22 16:28:02 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 22 Jan 2023 16:28:02 GMT
Subject: RFR: 8299497: Usage of constructors of primitive wrapper classes
 should be avoided in java.desktop API docs
In-Reply-To: <P9dJXgEvyMRwKbqoZjhPf_7CtvxlDXZAWUd7QisG-cg=.2044dd48-e625-428e-99f5-5405004fb24d@github.com>
References: <P9dJXgEvyMRwKbqoZjhPf_7CtvxlDXZAWUd7QisG-cg=.2044dd48-e625-428e-99f5-5405004fb24d@github.com>
Message-ID: <88la1XVIg47U5lt0FkHIGpsSNTKHkyOOxT_v4GR9-YU=.2bddd22f-897c-4c5d-ada1-b71a44861871@github.com>

On Sat, 21 Jan 2023 02:55:29 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> API docs of `java.awt.image.renderable.ParameterBlock` and `java.awt.font.LineBreakMeasurer` used deprecated constructors of `java.lang.Short` and `java.lang.Float`.
> 
> Replacing by `valueOf` factory methods.

Please configure the tests in your repo:
>Testing is not configured
>In order to run pre-submit tests, the [source repository](https://github.com/yuantj/jdk-pr/actions) must be properly configured to allow test execution. See https://wiki.openjdk.org/display/SKARA/Testing for more information on how to configure this.

-------------

PR: https://git.openjdk.org/jdk/pull/12128


From serb at openjdk.org  Sun Jan 22 17:00:11 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 22 Jan 2023 17:00:11 GMT
Subject: RFR: 8300725: Improve performance of ColorConvertOp for default
 destinations with alpha
In-Reply-To: <TCOspsb6dEDmHvkmgWDQEffMZOivwE_Amezx_94nzFY=.cfc0bf58-40dd-4a8e-9158-f63f4303853d@github.com>
References: <SCZI5xDSVmrvfz_JkKISEGXlwqeEb8WTTZm5wnV6HoI=.c939b603-9e76-4685-8254-d7cd1d1973a7@github.com>
 <TCOspsb6dEDmHvkmgWDQEffMZOivwE_Amezx_94nzFY=.cfc0bf58-40dd-4a8e-9158-f63f4303853d@github.com>
Message-ID: <QXbAc9z7Ub2O31XuanBRXU_gVjeJSDvMEC8x8x6ft0g=.d2faf6f3-bd5e-407b-8b48-8d7050d619e3@github.com>

On Sat, 21 Jan 2023 08:44:16 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> Congratulations, it is amazing!
> 
> Would it be possible to add support for INT_BGRA_PREMUL as supported by skia default raster N32 format?
> 
> Of course I cab help but not alone as it means many changes in C macros & backends + CSR request ...

If it will speed up some use cases then why not.

-------------

PR: https://git.openjdk.org/jdk/pull/12110


From duke at openjdk.org  Sun Jan 22 17:25:01 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sun, 22 Jan 2023 17:25:01 GMT
Subject: RFR: 8299497: Usage of constructors of primitive wrapper classes
 should be avoided in java.desktop API docs
In-Reply-To: <88la1XVIg47U5lt0FkHIGpsSNTKHkyOOxT_v4GR9-YU=.2bddd22f-897c-4c5d-ada1-b71a44861871@github.com>
References: <P9dJXgEvyMRwKbqoZjhPf_7CtvxlDXZAWUd7QisG-cg=.2044dd48-e625-428e-99f5-5405004fb24d@github.com>
 <88la1XVIg47U5lt0FkHIGpsSNTKHkyOOxT_v4GR9-YU=.2bddd22f-897c-4c5d-ada1-b71a44861871@github.com>
Message-ID: <-TqUbrgGcW7ceapqRqCJUfaEYn0KdTZH7Bm0KOCwe5I=.d33d4d93-f7c6-4cd5-ba8a-be2d712b615c@github.com>

On Sun, 22 Jan 2023 16:25:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please configure the tests in your repo:
> 
> > Testing is not configured
> > In order to run pre-submit tests, the [source repository](https://github.com/yuantj/jdk-pr/actions) must be properly configured to allow test execution. See https://wiki.openjdk.org/display/SKARA/Testing for more information on how to configure this.

Configured just now.

-------------

PR: https://git.openjdk.org/jdk/pull/12128


From aturbanov at openjdk.org  Sun Jan 22 18:49:33 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 22 Jan 2023 18:49:33 GMT
Subject: RFR: 8300828: Avoid unnecessary array fill after creation in
 com.sun.media.sound
Message-ID: <TPY8zicw78H6toMXNTiTeZOtH93XIQdqeyFIJKxXY8A=.c8f069bb-4e3c-4f52-8612-236ae33e81f6@github.com>

No need to fill elements of array with default values if it was just created. Java guarantees that all elements of array have default values after allocations: boolean - `false`, reference types - `null`, double - `0.`

-------------

Commit messages:
 - [PATCH] Avoid unnecessary array fill after creation in com.sun.media.sound

Changes: https://git.openjdk.org/jdk/pull/12130/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12130&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300828
  Stats: 18 lines in 3 files changed: 0 ins; 14 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12130.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12130/head:pull/12130

PR: https://git.openjdk.org/jdk/pull/12130


From duke at openjdk.org  Sun Jan 22 18:49:34 2023
From: duke at openjdk.org (SWinxy)
Date: Sun, 22 Jan 2023 18:49:34 GMT
Subject: RFR: 8300828: Avoid unnecessary array fill after creation in
 com.sun.media.sound
In-Reply-To: <TPY8zicw78H6toMXNTiTeZOtH93XIQdqeyFIJKxXY8A=.c8f069bb-4e3c-4f52-8612-236ae33e81f6@github.com>
References: <TPY8zicw78H6toMXNTiTeZOtH93XIQdqeyFIJKxXY8A=.c8f069bb-4e3c-4f52-8612-236ae33e81f6@github.com>
Message-ID: <Rb7NfL7zQ0wu0ActuVSKjIW8zMdC91TaR_bb_7j7Qww=.3733eef0-e312-4b40-8f7f-3cf335273630@github.com>

On Sat, 21 Jan 2023 19:44:39 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of array have default values after allocations: boolean - `false`, reference types - `null`, double - `0.`

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/12130


From serb at openjdk.org  Sun Jan 22 18:49:34 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 22 Jan 2023 18:49:34 GMT
Subject: RFR: 8300828: Avoid unnecessary array fill after creation in
 com.sun.media.sound
In-Reply-To: <TPY8zicw78H6toMXNTiTeZOtH93XIQdqeyFIJKxXY8A=.c8f069bb-4e3c-4f52-8612-236ae33e81f6@github.com>
References: <TPY8zicw78H6toMXNTiTeZOtH93XIQdqeyFIJKxXY8A=.c8f069bb-4e3c-4f52-8612-236ae33e81f6@github.com>
Message-ID: <TGHLGd79dfPlV4Q4emDoTOi9L2AAkthYncNQ-AaOqhM=.a2b0fb29-de71-4a01-a59a-93e19977f04e@github.com>

On Sat, 21 Jan 2023 19:44:39 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of array have default values after allocations: boolean - `false`, reference types - `null`, double - `0.`

looks fine

-------------

PR: https://git.openjdk.org/jdk/pull/12130


From serb at openjdk.org  Sun Jan 22 19:50:00 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 22 Jan 2023 19:50:00 GMT
Subject: RFR: 8300828: Avoid unnecessary array fill after creation in
 com.sun.media.sound
In-Reply-To: <TPY8zicw78H6toMXNTiTeZOtH93XIQdqeyFIJKxXY8A=.c8f069bb-4e3c-4f52-8612-236ae33e81f6@github.com>
References: <TPY8zicw78H6toMXNTiTeZOtH93XIQdqeyFIJKxXY8A=.c8f069bb-4e3c-4f52-8612-236ae33e81f6@github.com>
Message-ID: <FaavWaWyl_gIw34U4_YuQHTxNA8B7jBAFojg1SeUSbc=.075c4c3e-779a-4da9-8802-b56e0c9d8448@github.com>

On Sat, 21 Jan 2023 19:44:39 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of array have default values after allocations: boolean - `false`, reference types - `null`, double - `0.`

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12130


From serb at openjdk.org  Sun Jan 22 20:18:03 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 22 Jan 2023 20:18:03 GMT
Subject: RFR: 8299497: Usage of constructors of primitive wrapper classes
 should be avoided in java.desktop API docs
In-Reply-To: <P9dJXgEvyMRwKbqoZjhPf_7CtvxlDXZAWUd7QisG-cg=.2044dd48-e625-428e-99f5-5405004fb24d@github.com>
References: <P9dJXgEvyMRwKbqoZjhPf_7CtvxlDXZAWUd7QisG-cg=.2044dd48-e625-428e-99f5-5405004fb24d@github.com>
Message-ID: <BCUJJIpoZ_pwx-y-H7PF-bbJ6uMENUjilJaoBaDz4R4=.db44d824-d2bf-40dd-90dc-6ed4ae7aacdf@github.com>

On Sat, 21 Jan 2023 02:55:29 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> API docs of `java.awt.image.renderable.ParameterBlock` and `java.awt.font.LineBreakMeasurer` used deprecated constructors of `java.lang.Short` and `java.lang.Float`.
> 
> Replacing by `valueOf` factory methods.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12128


From tr at openjdk.org  Mon Jan 23 05:19:05 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 23 Jan 2023 05:19:05 GMT
Subject: RFR: 8300405: Screen capture for test
 JFileChooserSetLocationTest.java, failure case [v2]
In-Reply-To: <H9i4szvE-s7cWX1cu8bkx6nLa3yvB44bftLmYbbfhvM=.a5ae761a-cfe3-4a71-80b2-88bbb6ae7858@github.com>
References: <H9i4szvE-s7cWX1cu8bkx6nLa3yvB44bftLmYbbfhvM=.a5ae761a-cfe3-4a71-80b2-88bbb6ae7858@github.com>
Message-ID: <HHcSH53itQETCl4xJBXi55BPZos9GcKAM4RXvhtOlnE=.01446a81-dca2-4f2f-b05e-1ef91d0cb077@github.com>

> This is a diagnostic update related to [JDK-8295804](https://bugs.openjdk.org/browse/JDK-8295804). The issue was not reproducible and was showing up in particular machines (Where the machines are down now). So adding a screen capture to `BufferedImage` in case of failure so that it will help in analysis when the issue comes up in future.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated screen capture bounds

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12060/files
  - new: https://git.openjdk.org/jdk/pull/12060/files/89ab2eb8..7f369bde

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12060&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12060&range=00-01

  Stats: 7 lines in 1 file changed: 4 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12060.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12060/head:pull/12060

PR: https://git.openjdk.org/jdk/pull/12060


From psadhukhan at openjdk.org  Mon Jan 23 06:04:01 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 23 Jan 2023 06:04:01 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <ZeqUIXZYGAzYQpthfKtbfF6K2l5OMjtSh_XbW0uXMTk=.0eafb053-ddc6-4392-a5c9-630f666c3380@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
 <ml5KnXSuRa1uWxhC6_U3YcK8SlkCOlVIx18M6bVpnOQ=.ff55dd4d-66ef-4731-9d85-2f6677db84d2@github.com>
 <ZeqUIXZYGAzYQpthfKtbfF6K2l5OMjtSh_XbW0uXMTk=.0eafb053-ddc6-4392-a5c9-630f666c3380@github.com>
Message-ID: <MA5IyokBsjXkbzGr9ObDoDlivOhUH89lOVhMm455bM8=.76099680-7eb2-44ba-915c-0e98932ef595@github.com>

On Sun, 22 Jan 2023 16:16:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > As they ought to. All UI classes assume that the source for the property listener is the component it is the delegate for, which is why we see some classes passing e.getSource() and others passing the protected field. It's not something we can test, because the issues will arise when other people invoke the listener, and the JDK code doesn't (seem to) directly call it.
> 
> It is called to notify the listener since we add the UI delegate to the list: `list.addPropertyChangeListener(this);` in the SynthListUI.
> 
> It means that if the application/test will add `another UI delegate` to the list, then `updateStyle((JList)e.getSource());` will read the style from `another UI delegate`, not the current/protected field. It seems true that the code expects to always read the styles from the protected field, and that intention seems to be the opposite of what we do in the current change, no?

I have tried with a test where it is seen that **object for e.getSource() and "c" and "list" are sam**e so practically there is no functional change for this fix....Please suggest what else you want the test to do?


UIManager.setLookAndFeel("javax.swing.plaf.nimbus.NimbusLookAndFeel");
        JFrame frame = new JFrame();
        JList list = new JList();
        list.setModel(new javax.swing.AbstractListModel() {
            String[] strings = { "Item 1", "Item 2", "Item 3", "Item 4", "Item 5" };
            @Override
            public int getSize() { return strings.length; }
            @Override
            public Object getElementAt(int i) { return strings[i]; }
        });
        frame.getContentPane().add(list);
        frame.pack();
        frame.setLocationRelativeTo(null);
        frame.setVisible(true);
        list.addPropertyChangeListener(new PropertyChangeListener() {
             @Override
            public void propertyChange(PropertyChangeEvent evt) {
                    System.out.println("In test " + evt.getSource());

            }
        });
        list.setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT);


SynthListUI e.getSource _javax.swing.JList[,0,0,119x100,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.synth.SynthBorder at 10aa41f2,flags=335
54728,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=DerivedColor
(color=57,105,138 parent=nimbusSelectionBackground offsets=0.0,0.0,0.0,0 pColor=57,105,138,selectionForeground=DerivedColor(color=255,255,255 par
ent=nimbusLightBackground offsets=0.0,0.0,0.0,0 pColor=255,255,255,visibleRowCount=8,layoutOrientation=0]_

SynthListUI c: _javax.swing.JList[,0,0,119x100,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.synth.SynthBorder at 10aa41f2,flags=33554728,max
imumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=DerivedColor(color=57
,105,138 parent=nimbusSelectionBackground offsets=0.0,0.0,0.0,0 pColor=57,105,138,selectionForeground=DerivedColor(color=255,255,255 parent=nimbu
sLightBackground offsets=0.0,0.0,0.0,0 pColor=255,255,255,visibleRowCount=8,layoutOrientation=0]_

SynthListUI list: _javax.swing.JList[,0,0,119x100,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.synth.SynthBorder at 10aa41f2,flags=33554728,
maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=DerivedColor(color
=57,105,138 parent=nimbusSelectionBackground offsets=0.0,0.0,0.0,0 pColor=57,105,138,selectionForeground=DerivedColor(color=255,255,255 parent=ni
mbusLightBackground offsets=0.0,0.0,0.0,0 pColor=255,255,255,visibleRowCount=8,layoutOrientation=0]_

In test _javax.swing.JList[,0,0,119x100,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.synth.SynthBorder at 10aa41f2,flags=33554728,maximumSiz
e=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=DerivedColor(color=57,105,13
8 parent=nimbusSelectionBackground offsets=0.0,0.0,0.0,0 pColor=57,105,138,selectionForeground=DerivedColor(color=255,255,255 parent=nimbusLightB
ackground offsets=0.0,0.0,0.0,0 pColor=255,255,255,visibleRowCount=8,layoutOrientation=0]_

-------------

PR: https://git.openjdk.org/jdk/pull/11875


From psadhukhan at openjdk.org  Mon Jan 23 06:14:04 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 23 Jan 2023 06:14:04 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <MA5IyokBsjXkbzGr9ObDoDlivOhUH89lOVhMm455bM8=.76099680-7eb2-44ba-915c-0e98932ef595@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
 <ml5KnXSuRa1uWxhC6_U3YcK8SlkCOlVIx18M6bVpnOQ=.ff55dd4d-66ef-4731-9d85-2f6677db84d2@github.com>
 <ZeqUIXZYGAzYQpthfKtbfF6K2l5OMjtSh_XbW0uXMTk=.0eafb053-ddc6-4392-a5c9-630f666c3380@github.com>
 <MA5IyokBsjXkbzGr9ObDoDlivOhUH89lOVhMm455bM8=.76099680-7eb2-44ba-915c-0e98932ef595@github.com>
Message-ID: <O3exgJpd2LDtW0Eqn4ax4WxsSyEZuQ5EgSQztT3SVqE=.d2d34152-a91d-4625-b2a9-6b3ac1112320@github.com>

On Mon, 23 Jan 2023 06:01:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems true that the code expects to always read the styles from the protected field, and that intention seems to be the opposite of what we do in the current change, no?

Also, it is done same for all other SYnth classes as I told earlier too.
For example, in SynthTable, it calls `updateStyle((JTable)event.getSource());` whereas in updateStyle() we use 
`SynthContext context = getContext(c, ENABLED);` even though we have protected field `protected JTable table;` in BasicTableUI being used in updateStyle() in SynthTableUI

so I think it was mistakenly done and it is remedied in current fix, otherwise we need to do SynthListUI changes to use protected field in other Synth classes too, but since the other way around is in majority, I think this is what should be done for consistency..

-------------

PR: https://git.openjdk.org/jdk/pull/11875


From psadhukhan at openjdk.org  Mon Jan 23 06:35:06 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 23 Jan 2023 06:35:06 GMT
Subject: RFR: 8300269: The selected item in an editable JComboBox with
 titled border is not visible in Aqua LAF [v3]
In-Reply-To: <fsiHv4-VagNQz4LMmOYH1_WT55MDE4jFLrtuDBq2Eyw=.9431fbc1-45af-48b9-8de3-f8b34a9f3515@github.com>
References: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>
 <fsiHv4-VagNQz4LMmOYH1_WT55MDE4jFLrtuDBq2Eyw=.9431fbc1-45af-48b9-8de3-f8b34a9f3515@github.com>
Message-ID: <Eer9B0KSjIdY5qjPeOpzYETRstdDWe7uRadGHME9x3M=.8705a66d-aeeb-43dc-b476-590728586819@github.com>

On Fri, 20 Jan 2023 22:45:32 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The fixed height causes the titled border insets to reserve a majority of the height available for the component. This fixed height is meant for the default AquaComboBox usage, so the old default height is more applicable when a border, such as TitledBorder, is set on an Aqua Editable ComboBox.
>> 
>> A conditional to check for a border is added since this is the default for an AquaComboBox using AquaBorder in AquaComboBoxUI's rectangleForCurrentValue() step. A check for any border rather than an instance of a TitledBorder is used because this issue causes changes in other borders as well (I found it for LineBorder for example). 
>> 
>> The editable JComboBox is visible with a LineBorder, but the coordinates of the comboBox are aligned with the top of the arrowButton instead of the bottom (which was the case before the previous fix). So, the method now defaults to the behavior before the fix for any editable comboBox pre-fix if a different border is set.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change bounds to toolkit screen size

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12087


From psadhukhan at openjdk.org  Mon Jan 23 06:35:07 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 23 Jan 2023 06:35:07 GMT
Subject: RFR: 8300269: The selected item in an editable JComboBox with
 titled border is not visible in Aqua LAF [v2]
In-Reply-To: <40FzSk4MuKAFvcvF3gUQwNx9SWlXe4KOa-0L6QpyQPQ=.fccffd0a-09b3-445e-90d9-c840cf1b360f@github.com>
References: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>
 <pd2zMoD3rYpG08UI_skEsMLnEEJCGDhz2BcJ6nPD--E=.01ddf417-96a1-4ed3-a1be-20dccf76c6a0@github.com>
 <thCTGKlZsifToqClIspUZt9nio7StFwL7cdfCvcKTko=.e99abb0f-6ed4-4a3f-9aed-8c7d55dfc3b7@github.com>
 <40FzSk4MuKAFvcvF3gUQwNx9SWlXe4KOa-0L6QpyQPQ=.fccffd0a-09b3-445e-90d9-c840cf1b360f@github.com>
Message-ID: <m4I-s12BNYtOMZXG9hioTsVBvUgsv-7AFwuUKLGH-OU=.7e09b9c6-b8f4-4332-a8c1-c2fe9253b25f@github.com>

On Fri, 20 Jan 2023 21:24:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 460:
>> 
>>> 458:         protected Rectangle rectangleForCurrentValue() {
>>> 459:             int width = comboBox.getWidth();
>>> 460:             int height = comboBox.getBorder() == null ? 22 : comboBox.getHeight();
>> 
>> Before JDK-8054572, comboBox.getHeight()+1 was used , shouldn't we use the same if we are going to fallback to previous way with border
>> 
>> `editorRect.height += 1;`
>> 
>> Also, it seems for TitledBorder the popupmenu is not aligned properly. It should have been at the base of the combobox, just as it is for without border...although I don think it's related to this fix but seems to be a bug nevertheless (in Date/Time macos settings, popupmenu for editable combobox is at the base)
>> 
>> ![image](https://user-images.githubusercontent.com/43534309/213630526-9cdc5401-d975-4bc3-9cd8-db3a01057d47.png)
>> 
>> =======
>> Without border
>> 
>> ![image](https://user-images.githubusercontent.com/43534309/213632563-6df07625-22f6-4630-9d3b-511b5ff3cadd.png)
>
> Adding 1 to the height would go back to the previous implementation, but it actually causes the comboBox to look more misaligned by 1 extra pixel. I can re-add the +1 to return to the original method if preferred.
> 
> <img width="63" alt="Screen Shot 2023-01-20 at 12 54 47 PM" src="https://user-images.githubusercontent.com/96267980/213807706-81de1e18-8922-43f4-8313-72d8332a20b1.png">
> 
> I see the popup issue on my end as well. But this seems to be unrelated to the fix as you mentioned. I can create a separate JBS issue for this if needed.

OK. I guess that's in Monterey, right? I guess it doesn't cause any difference in BigSur where I tested so I asked.

For popup issue, yes, please raise a JBS..

-------------

PR: https://git.openjdk.org/jdk/pull/12087


From psadhukhan at openjdk.org  Mon Jan 23 10:26:18 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 23 Jan 2023 10:26:18 GMT
Subject: Integrated: 8244400: MenuItem may cache the size and did not update it
 when the screen DPI is changed
In-Reply-To: <-uTiC-hv_VAqzznPs2lyYbPFmjJ06PIGZZCbEfuwPgE=.6d97f3a5-bd81-4697-9299-0e7039e2d9c2@github.com>
References: <-uTiC-hv_VAqzznPs2lyYbPFmjJ06PIGZZCbEfuwPgE=.6d97f3a5-bd81-4697-9299-0e7039e2d9c2@github.com>
Message-ID: <F9-5Cl0UUjmuS1CukVAl2CjMr3wP8_hlgyGmJM6RYcA=.02bda979-1170-4f12-8a00-0473801d7da6@github.com>

On Wed, 7 Dec 2022 03:48:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The MenuItemLayoutHelper.clearUsedParentClientProperties must be called automatically when the DPI was changed. 
> Workaround added in the test for this bug is removed.
> 
> CI tests are ok.

This pull request has now been integrated.

Changeset: 11aadc9d
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/11aadc9d98d364b91114c028c7e2eff8de2f2bf0
Stats:     16 lines in 2 files changed: 3 ins; 7 del; 6 mod

8244400: MenuItem may cache the size and did not update it when the screen DPI is changed

Reviewed-by: serb, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/11551


From prr at openjdk.org  Mon Jan 23 17:48:54 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Jan 2023 17:48:54 GMT
Subject: RFR: 8300828: Avoid unnecessary array fill after creation in
 com.sun.media.sound
In-Reply-To: <TPY8zicw78H6toMXNTiTeZOtH93XIQdqeyFIJKxXY8A=.c8f069bb-4e3c-4f52-8612-236ae33e81f6@github.com>
References: <TPY8zicw78H6toMXNTiTeZOtH93XIQdqeyFIJKxXY8A=.c8f069bb-4e3c-4f52-8612-236ae33e81f6@github.com>
Message-ID: <wNwi018V4dGXm5Bhp9t_Kx6XlMbcDBoqte-t1N49ryc=.1a1562aa-0d8f-494a-ac08-26d07dde0ce8@github.com>

On Sat, 21 Jan 2023 19:44:39 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of array have default values after allocations: boolean - `false`, reference types - `null`, double - `0.`

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12130


From dnguyen at openjdk.org  Mon Jan 23 17:49:45 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 23 Jan 2023 17:49:45 GMT
Subject: RFR: 8300269: The selected item in an editable JComboBox with
 titled border is not visible in Aqua LAF [v2]
In-Reply-To: <m4I-s12BNYtOMZXG9hioTsVBvUgsv-7AFwuUKLGH-OU=.7e09b9c6-b8f4-4332-a8c1-c2fe9253b25f@github.com>
References: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>
 <pd2zMoD3rYpG08UI_skEsMLnEEJCGDhz2BcJ6nPD--E=.01ddf417-96a1-4ed3-a1be-20dccf76c6a0@github.com>
 <thCTGKlZsifToqClIspUZt9nio7StFwL7cdfCvcKTko=.e99abb0f-6ed4-4a3f-9aed-8c7d55dfc3b7@github.com>
 <40FzSk4MuKAFvcvF3gUQwNx9SWlXe4KOa-0L6QpyQPQ=.fccffd0a-09b3-445e-90d9-c840cf1b360f@github.com>
 <m4I-s12BNYtOMZXG9hioTsVBvUgsv-7AFwuUKLGH-OU=.7e09b9c6-b8f4-4332-a8c1-c2fe9253b25f@github.com>
Message-ID: <ISty_-JkcXpY6YAE_yEY5-wc_y_WKBtI0VR7dGpiMpQ=.163d1d29-a11b-4a1e-b822-980aa0d582b6@github.com>

On Mon, 23 Jan 2023 06:31:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Adding 1 to the height would go back to the previous implementation, but it actually causes the comboBox to look more misaligned by 1 extra pixel. I can re-add the +1 to return to the original method if preferred.
>> 
>> <img width="63" alt="Screen Shot 2023-01-20 at 12 54 47 PM" src="https://user-images.githubusercontent.com/96267980/213807706-81de1e18-8922-43f4-8313-72d8332a20b1.png">
>> 
>> I see the popup issue on my end as well. But this seems to be unrelated to the fix as you mentioned. I can create a separate JBS issue for this if needed.
>
> OK. I guess that's in Monterey, right? I guess it doesn't cause any difference in BigSur where I tested so I asked.
> 
> For popup issue, yes, please raise a JBS..

Yes, this is in Monterey. I'll leave the height as is in this change then since it seems better overall.

I'll raise a new JBS issue for the popupmenu on an editable jcombobox.

-------------

PR: https://git.openjdk.org/jdk/pull/12087


From prr at openjdk.org  Mon Jan 23 17:50:43 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Jan 2023 17:50:43 GMT
Subject: RFR: 8299497: Usage of constructors of primitive wrapper classes
 should be avoided in java.desktop API docs
In-Reply-To: <P9dJXgEvyMRwKbqoZjhPf_7CtvxlDXZAWUd7QisG-cg=.2044dd48-e625-428e-99f5-5405004fb24d@github.com>
References: <P9dJXgEvyMRwKbqoZjhPf_7CtvxlDXZAWUd7QisG-cg=.2044dd48-e625-428e-99f5-5405004fb24d@github.com>
Message-ID: <T8TFjHobXBEPFxIAGCA8Ft9lgl0q5D-Lyi_HLjzyohU=.8c0d96a2-8a71-447c-9720-390f46e8e306@github.com>

On Sat, 21 Jan 2023 02:55:29 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> API docs of `java.awt.image.renderable.ParameterBlock` and `java.awt.font.LineBreakMeasurer` used deprecated constructors of `java.lang.Short` and `java.lang.Float`.
> 
> Replacing by `valueOf` factory methods.

This won't need a CSR

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12128


From duke at openjdk.org  Mon Jan 23 18:30:15 2023
From: duke at openjdk.org (SWinxy)
Date: Mon, 23 Jan 2023 18:30:15 GMT
Subject: RFR: 7131166: SynthListUI / SynthInternalFrameTitlePane
 updateStyle() ignores method argument
In-Reply-To: <O3exgJpd2LDtW0Eqn4ax4WxsSyEZuQ5EgSQztT3SVqE=.d2d34152-a91d-4625-b2a9-6b3ac1112320@github.com>
References: <8r3HwRdshQrMKEB_sYH2nUfcVIxOdDaL1Qsc0iBW0G8=.89dbaa65-1549-47df-ae5f-f2001b77d301@github.com>
 <ml5KnXSuRa1uWxhC6_U3YcK8SlkCOlVIx18M6bVpnOQ=.ff55dd4d-66ef-4731-9d85-2f6677db84d2@github.com>
 <ZeqUIXZYGAzYQpthfKtbfF6K2l5OMjtSh_XbW0uXMTk=.0eafb053-ddc6-4392-a5c9-630f666c3380@github.com>
 <MA5IyokBsjXkbzGr9ObDoDlivOhUH89lOVhMm455bM8=.76099680-7eb2-44ba-915c-0e98932ef595@github.com>
 <O3exgJpd2LDtW0Eqn4ax4WxsSyEZuQ5EgSQztT3SVqE=.d2d34152-a91d-4625-b2a9-6b3ac1112320@github.com>
Message-ID: <vY0s-_rgbf8-z2x-VZ_tSIXioDotNvghTs2RCDxt0KA=.aab8590c-3f2a-47fa-9984-67fb6692a1be@github.com>

On Mon, 23 Jan 2023 06:11:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I think it was mistakenly done

I agree. All classes would probably be fine if their code only referenced their protected object instead of the `e.getSource()` one. If they aren't, then that means there are bugs elsewhere.

-------------

PR: https://git.openjdk.org/jdk/pull/11875


From prr at openjdk.org  Mon Jan 23 20:52:06 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Jan 2023 20:52:06 GMT
Subject: RFR: 8300269: The selected item in an editable JComboBox with
 titled border is not visible in Aqua LAF [v3]
In-Reply-To: <fsiHv4-VagNQz4LMmOYH1_WT55MDE4jFLrtuDBq2Eyw=.9431fbc1-45af-48b9-8de3-f8b34a9f3515@github.com>
References: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>
 <fsiHv4-VagNQz4LMmOYH1_WT55MDE4jFLrtuDBq2Eyw=.9431fbc1-45af-48b9-8de3-f8b34a9f3515@github.com>
Message-ID: <QEBaN3aCWUKBsq06em6yl-5Rbpd3Kg4PKazDm55SsPk=.3472b97e-ebdc-4d2c-b941-49fa4a2c84ee@github.com>

On Fri, 20 Jan 2023 22:45:32 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The fixed height causes the titled border insets to reserve a majority of the height available for the component. This fixed height is meant for the default AquaComboBox usage, so the old default height is more applicable when a border, such as TitledBorder, is set on an Aqua Editable ComboBox.
>> 
>> A conditional to check for a border is added since this is the default for an AquaComboBox using AquaBorder in AquaComboBoxUI's rectangleForCurrentValue() step. A check for any border rather than an instance of a TitledBorder is used because this issue causes changes in other borders as well (I found it for LineBorder for example). 
>> 
>> The editable JComboBox is visible with a LineBorder, but the coordinates of the comboBox are aligned with the top of the arrowButton instead of the bottom (which was the case before the previous fix). So, the method now defaults to the behavior before the fix for any editable comboBox pre-fix if a different border is set.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change bounds to toolkit screen size

Based on what I see in the bug report showing the item is completely invisible
and that the fix looks safe and simple and local, I believe this should be considered a P2
regression in JDK 20 and fixed directly there ASAP.
So withdraw this PR and resubmit against JDK 20 following the RDP 2 protocols.

-------------

PR: https://git.openjdk.org/jdk/pull/12087


From aturbanov at openjdk.org  Mon Jan 23 21:07:55 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 23 Jan 2023 21:07:55 GMT
Subject: RFR: 8300929: Avoid unnecessary array fill after creation in
 java.awt.image
Message-ID: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>

No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.

-------------

Commit messages:
 - [PATCH] Avoid unnecessary array fill after creation in java.awt.image

Changes: https://git.openjdk.org/jdk/pull/12147/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12147&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300929
  Stats: 37 lines in 5 files changed: 1 ins; 30 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12147.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12147/head:pull/12147

PR: https://git.openjdk.org/jdk/pull/12147


From duke at openjdk.org  Mon Jan 23 21:13:06 2023
From: duke at openjdk.org (SWinxy)
Date: Mon, 23 Jan 2023 21:13:06 GMT
Subject: RFR: 8300929: Avoid unnecessary array fill after creation in
 java.awt.image
In-Reply-To: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
References: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
Message-ID: <FLJnRtxkWBKgdgOU31IoW7S3HXZ_98GyZ-Iz3tVuhSI=.3b8121c5-2f7d-404d-8a6b-2686fa093db7@github.com>

On Mon, 23 Jan 2023 17:20:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/12147


From aturbanov at openjdk.org  Mon Jan 23 21:14:13 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 23 Jan 2023 21:14:13 GMT
Subject: Integrated: 8300828: Avoid unnecessary array fill after creation in
 com.sun.media.sound
In-Reply-To: <TPY8zicw78H6toMXNTiTeZOtH93XIQdqeyFIJKxXY8A=.c8f069bb-4e3c-4f52-8612-236ae33e81f6@github.com>
References: <TPY8zicw78H6toMXNTiTeZOtH93XIQdqeyFIJKxXY8A=.c8f069bb-4e3c-4f52-8612-236ae33e81f6@github.com>
Message-ID: <y_samgeKg4B6w4AFVYPACVvKE38mhK9j4XO-AxMWjfI=.bc1e004e-ba50-443a-b281-8d0f9b8b8314@github.com>

On Sat, 21 Jan 2023 19:44:39 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of array have default values after allocations: boolean - `false`, reference types - `null`, double - `0.`

This pull request has now been integrated.

Changeset: f79e5871
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f79e5871813ab9554e3250cf4b36e92522bddd0a
Stats:     18 lines in 3 files changed: 0 ins; 14 del; 4 mod

8300828: Avoid unnecessary array fill after creation in com.sun.media.sound

Reviewed-by: serb, prr

-------------

PR: https://git.openjdk.org/jdk/pull/12130


From duke at openjdk.org  Tue Jan 24 01:28:11 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Tue, 24 Jan 2023 01:28:11 GMT
Subject: Integrated: 8299497: Usage of constructors of primitive wrapper
 classes should be avoided in java.desktop API docs
In-Reply-To: <P9dJXgEvyMRwKbqoZjhPf_7CtvxlDXZAWUd7QisG-cg=.2044dd48-e625-428e-99f5-5405004fb24d@github.com>
References: <P9dJXgEvyMRwKbqoZjhPf_7CtvxlDXZAWUd7QisG-cg=.2044dd48-e625-428e-99f5-5405004fb24d@github.com>
Message-ID: <6qTiAvzAxtV6nYkghiow4JdGicDM8LaGFAD6a-X1nSE=.6182ba7b-c9f4-4361-b18b-a0ce78177589@github.com>

On Sat, 21 Jan 2023 02:55:29 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> API docs of `java.awt.image.renderable.ParameterBlock` and `java.awt.font.LineBreakMeasurer` used deprecated constructors of `java.lang.Short` and `java.lang.Float`.
> 
> Replacing by `valueOf` factory methods.

This pull request has now been integrated.

Changeset: b5ee3d1f
Author:    Tingjun Yuan <yuantj1999 at outlook.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5ee3d1f2abf5af86438ac4c9e3da3cc026dffd3
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8299497: Usage of constructors of primitive wrapper classes should be avoided in java.desktop API docs

Reviewed-by: serb, prr

-------------

PR: https://git.openjdk.org/jdk/pull/12128


From serb at openjdk.org  Tue Jan 24 13:54:54 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 24 Jan 2023 13:54:54 GMT
Subject: RFR: 8238170: BeanContextSupport remove and propertyChange can
 deadlock
Message-ID: <qS_fxqeO2UlPD7Tqkc7Iqe4vYVBn0Az4B328s7uVw_k=.5560c0f8-33e0-4fb5-bd25-08220ff8a8e3@github.com>

Two methods in the BeanContextSupport class use two locks in a different order, which can cause a deadlock. 

Here is the first order: (1) first acquire BeanContext.globalHierarchyLock and then children:

    enter public method remove(Object) at line 484
    call remove(Object, boolean) at line 485
    acquire synchronization on BeanContext.globalHierarchyLock at line 502
    acquire synchronization on children at line 534

Here is the second order: (2) first acquire children and then BeanContext.globalHierarchyLock:

    enter public method propertyChange() at line 1110
    acquire synchronization on children at line 1114
    call remove(Object, boolean) at line 1121
    acquire synchronization on BeanContext.globalHierarchyLock at line 502 

The fix added the "BeanContext.globalHierarchyLock" before the usage of the "children" lock in the propertyChange method.

-------------

Commit messages:
 - Update BeanContextSupport.java
 - 8238170: BeanContextSupport remove and propertyChange can deadlock

Changes: https://git.openjdk.org/jdk/pull/12158/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12158&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8238170
  Stats: 158 lines in 3 files changed: 147 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12158.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12158/head:pull/12158

PR: https://git.openjdk.org/jdk/pull/12158


From attila at openjdk.org  Tue Jan 24 14:26:03 2023
From: attila at openjdk.org (Attila Szegedi)
Date: Tue, 24 Jan 2023 14:26:03 GMT
Subject: RFR: 8300929: Avoid unnecessary array fill after creation in
 java.awt.image
In-Reply-To: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
References: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
Message-ID: <6ZJM3NHYyyXOFttrMLqXSFWsvaIx_CXs6tCJvpabCcs=.9a433e91-2e11-40d4-b9ad-5d9e7d81ee9c@github.com>

On Mon, 23 Jan 2023 17:20:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.

Marked as reviewed by attila (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12147


From serb at openjdk.org  Tue Jan 24 16:29:15 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 24 Jan 2023 16:29:15 GMT
Subject: RFR: 8300929: Avoid unnecessary array fill after creation in
 java.awt.image
In-Reply-To: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
References: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
Message-ID: <RaGAJiwGcG8mxuY7kCdM2QG0AOn5zgzxb5LCLnnvXuI=.81c98a8a-e5a1-4a48-ae95-50d735bd45f1@github.com>

On Mon, 23 Jan 2023 17:20:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.

src/java.desktop/share/classes/java/awt/image/ComponentColorModel.java line 521:

> 519:             {
> 520:                 byte[] bpixel = new byte[numComponents];
> 521:                 for (int i = 0; i < numColorComponents; i++) {

Is it possible that indirectly this code threw the AIOBE for some wrong "numColorComponents"?

src/java.desktop/share/classes/java/awt/image/Raster.java line 372:

> 370:         for (int i = 0; i < bands; i++) {
> 371:             bankIndices[i] = i;
> 372:             bandOffsets[i] = 0;

I suggest to comment this line and adding a comment like "0 zero is the default value not need to be set"

-------------

PR: https://git.openjdk.org/jdk/pull/12147


From asemenov at openjdk.org  Tue Jan 24 17:16:20 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 24 Jan 2023 17:16:20 GMT
Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v4]
In-Reply-To: <KMaPkryUkSlIZdpEz7fkT1nAqPTJZIseooxtFBBT4dc=.2d3f244f-7e94-4e97-b932-99cef0c7eaab@github.com>
References: <iogsScwXVmrG-QaPPqnBIyBbyc30OmKOUPLjiSKpEEs=.c76d3e64-ea3e-4560-a88a-821f25f9680b@github.com>
 <KMaPkryUkSlIZdpEz7fkT1nAqPTJZIseooxtFBBT4dc=.2d3f244f-7e94-4e97-b932-99cef0c7eaab@github.com>
Message-ID: <w8vWHQxRs1FDdXrE0nDB9PDKn_D0G4E9Rtj1XfnNQfo=.1c2976b8-2db4-4822-b547-0103a0ec373e@github.com>

On Wed, 9 Nov 2022 09:42:00 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index.
>> 
>> @forantar @azuev-java @mrserb please review.
>> 
>> Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode".
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We are not using author tags in tests either - but that's just a nitpick.

Please do not close this pull request.

-------------

PR: https://git.openjdk.org/jdk/pull/8578


From aturbanov at openjdk.org  Tue Jan 24 18:27:16 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 24 Jan 2023 18:27:16 GMT
Subject: RFR: 8300929: Avoid unnecessary array fill after creation in
 java.awt.image
In-Reply-To: <RaGAJiwGcG8mxuY7kCdM2QG0AOn5zgzxb5LCLnnvXuI=.81c98a8a-e5a1-4a48-ae95-50d735bd45f1@github.com>
References: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
 <RaGAJiwGcG8mxuY7kCdM2QG0AOn5zgzxb5LCLnnvXuI=.81c98a8a-e5a1-4a48-ae95-50d735bd45f1@github.com>
Message-ID: <RdAJ3QUHwOsgkzMeFEJFlczXQdK473TzdU-vZV0kGxE=.23f516bd-ef34-4887-87ed-6fb3968ddc85@github.com>

On Tue, 24 Jan 2023 16:22:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.
>
> src/java.desktop/share/classes/java/awt/image/ComponentColorModel.java line 521:
> 
>> 519:             {
>> 520:                 byte[] bpixel = new byte[numComponents];
>> 521:                 for (int i = 0; i < numColorComponents; i++) {
> 
> Is it possible that indirectly this code threw the AIOBE for some wrong "numColorComponents"?

I believe it's impossible to get AIOBE here (at least without some reflection tricks).
`numColorComponents` and `numComponents` are assigned only in 2 places. And in both places it's guarantee that `numComponents >= numColorComponents`
![???????????](https://user-images.githubusercontent.com/741251/214376362-881adb6b-7ea9-4fd3-8787-d52626fb7489.png)

-------------

PR: https://git.openjdk.org/jdk/pull/12147


From aturbanov at openjdk.org  Tue Jan 24 18:31:12 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 24 Jan 2023 18:31:12 GMT
Subject: RFR: 8300929: Avoid unnecessary array fill after creation in
 java.awt.image
In-Reply-To: <RaGAJiwGcG8mxuY7kCdM2QG0AOn5zgzxb5LCLnnvXuI=.81c98a8a-e5a1-4a48-ae95-50d735bd45f1@github.com>
References: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
 <RaGAJiwGcG8mxuY7kCdM2QG0AOn5zgzxb5LCLnnvXuI=.81c98a8a-e5a1-4a48-ae95-50d735bd45f1@github.com>
Message-ID: <wzbJNMoIfMkwFF2Y465QIGWBbWfihY0A5x9DlsW0e74=.40ddb466-a67f-41f8-80ee-ebe67fb180b1@github.com>

On Tue, 24 Jan 2023 16:25:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.
>
> src/java.desktop/share/classes/java/awt/image/Raster.java line 372:
> 
>> 370:         for (int i = 0; i < bands; i++) {
>> 371:             bankIndices[i] = i;
>> 372:             bandOffsets[i] = 0;
> 
> I suggest to comment this line and adding a comment like "0 zero is the default value not need to be set"

I'm not really fan of commented out code.
What if I add a comment to the array declaration itself?

int[] bandOffsets = new int[bands]; // by default have 0 values

-------------

PR: https://git.openjdk.org/jdk/pull/12147


From attila at openjdk.org  Tue Jan 24 19:42:11 2023
From: attila at openjdk.org (Attila Szegedi)
Date: Tue, 24 Jan 2023 19:42:11 GMT
Subject: RFR: 8300929: Avoid unnecessary array fill after creation in
 java.awt.image
In-Reply-To: <RaGAJiwGcG8mxuY7kCdM2QG0AOn5zgzxb5LCLnnvXuI=.81c98a8a-e5a1-4a48-ae95-50d735bd45f1@github.com>
References: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
 <RaGAJiwGcG8mxuY7kCdM2QG0AOn5zgzxb5LCLnnvXuI=.81c98a8a-e5a1-4a48-ae95-50d735bd45f1@github.com>
Message-ID: <RRBMqJ6kaMOo-9kIqxHinRmKReqnxaCSM_bkVTpPjyc=.2dbe497e-7078-4ab2-8ed5-e51f66971ac1@github.com>

On Tue, 24 Jan 2023 16:25:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.
>
> src/java.desktop/share/classes/java/awt/image/Raster.java line 372:
> 
>> 370:         for (int i = 0; i < bands; i++) {
>> 371:             bankIndices[i] = i;
>> 372:             bandOffsets[i] = 0;
> 
> I suggest to comment this line and adding a comment like "0 zero is the default value not need to be set"

Yeah, please, no commented-out code. I'd be fine with the code as it was, I don't think it needs much clarification. If @mrserb insists on a comment then I agree that a comment on the array declaration should be sufficient.

-------------

PR: https://git.openjdk.org/jdk/pull/12147


From achung at openjdk.org  Tue Jan 24 20:14:20 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 24 Jan 2023 20:14:20 GMT
Subject: RFR: 8282217: Key events (key char and key code) changed for Swiss
 keyboard [v2]
In-Reply-To: <N9XfS6cL8s1G98UAiEr7ZvgzQB-HX6qKGptKZe7d810=.1f5932c5-fd00-4fe8-9c0b-99f2fa71d880@github.com>
References: <N9XfS6cL8s1G98UAiEr7ZvgzQB-HX6qKGptKZe7d810=.1f5932c5-fd00-4fe8-9c0b-99f2fa71d880@github.com>
Message-ID: <wDc27Q7Dva-G4BaW8mNU1ytaYrDE65zL5MFP3JeEMY4=.d12138b0-0092-4a5d-833e-ec6eb7b6d8ad@github.com>

> Removed check for MapVirtualKeyEx return value causing some keys to become undefined

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  readded check for dead key leading bit, added separate check for group separator

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11887/files
  - new: https://git.openjdk.org/jdk/pull/11887/files/bcaa7569..7f4d359b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11887&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11887&range=00-01

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11887.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11887/head:pull/11887

PR: https://git.openjdk.org/jdk/pull/11887


From aturbanov at openjdk.org  Tue Jan 24 20:15:05 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 24 Jan 2023 20:15:05 GMT
Subject: RFR: 8238170: BeanContextSupport remove and propertyChange can
 deadlock
In-Reply-To: <qS_fxqeO2UlPD7Tqkc7Iqe4vYVBn0Az4B328s7uVw_k=.5560c0f8-33e0-4fb5-bd25-08220ff8a8e3@github.com>
References: <qS_fxqeO2UlPD7Tqkc7Iqe4vYVBn0Az4B328s7uVw_k=.5560c0f8-33e0-4fb5-bd25-08220ff8a8e3@github.com>
Message-ID: <cHIwvUwEU6fS62odpaDPWdnE4tGbRPpr37GGHzxT_h0=.b47adbef-a383-458a-b50a-dc44e73f46ae@github.com>

On Tue, 24 Jan 2023 03:15:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Two methods in the BeanContextSupport class use two locks in a different order, which can cause a deadlock. 
> 
> Here is the first order: (1) first acquire BeanContext.globalHierarchyLock and then children:
> 
>     enter public method remove(Object) at line 484
>     call remove(Object, boolean) at line 485
>     acquire synchronization on BeanContext.globalHierarchyLock at line 502
>     acquire synchronization on children at line 534
> 
> Here is the second order: (2) first acquire children and then BeanContext.globalHierarchyLock:
> 
>     enter public method propertyChange() at line 1110
>     acquire synchronization on children at line 1114
>     call remove(Object, boolean) at line 1121
>     acquire synchronization on BeanContext.globalHierarchyLock at line 502 
> 
> The fix added the "BeanContext.globalHierarchyLock" before the usage of the "children" lock in the propertyChange method.

Oof... Approach for synchronization in `BeanContextServicesSupport` is confusing for me and inconsistent.
Do you know why read access to `children` is not syncrhonized in `java.beans.beancontext.BeanContextSupport#add` ?
https://github.com/openjdk/jdk/blob/3be5758bb413fb6b4dc6191d78ca38332d5153f1/src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java#L394

-------------

PR: https://git.openjdk.org/jdk/pull/12158


From dnguyen at openjdk.org  Tue Jan 24 20:57:43 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 20:57:43 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update
Message-ID: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>

Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
All tests passed

-------------

Commit messages:
 - Remove currency symbol entries
 - Remove whitespace using tool
 - Remove double quotes generated by translation tool
 - Revert translation's removal of <is considered> text
 - Update files for localization

Changes: https://git.openjdk.org/jdk20/pull/116/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300719
  Stats: 1030 lines in 81 files changed: 218 ins; 115 del; 697 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Tue Jan 24 21:08:11 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 21:08:11 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <4tI9y6FpAFrOiS4N4joygZHAHvPm-Ka2D9_3F8pyD6o=.fbb62ba6-4658-46b5-96f8-307ab3b41f81@github.com>

On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

@prrace @wangweij @naotoj @JoeWang-Java @plummercj @alexeysemenyukoracle
Could you review the changes from this localization drop?

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Tue Jan 24 21:48:11 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 21:48:11 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <SltPNoJFof9JSmmSGamoTHPgVj-sZYWE0-_ijvVAHq4=.904ae847-154e-4fbc-bb8f-3792d5767b3e@github.com>

On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

@magicus @LanceAndersen @jonathan-gibbons @pavelrappo @dougxc @lahodaj
Could you review the changes from this localization drop for the areas you're familiar with?

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From cjplummer at openjdk.org  Tue Jan 24 22:05:10 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 24 Jan 2023 22:05:10 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <B6mEwU9m4V_eHQKkH5EHYR4ofs8G7wh5Zzpt7K6-M7I=.a2729d77-4f00-4871-a4a1-2904ce852c74@github.com>

On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

jdk.console and jdk.management.agent changes look good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Tue Jan 24 22:12:26 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:12:26 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Change German help of jar command

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/4ced04fb..a2528015

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116


From naoto at openjdk.org  Tue Jan 24 22:24:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Jan 2023 22:24:15 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
Message-ID: <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>

On Tue, 24 Jan 2023 22:12:26 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change German help of jar command

Changes requested by naoto (Reviewer).

src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties line 174:

> 172: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON=\u53D6\u6D88\u8BA2\u9605(&U)
> 173: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON_TOOLTIP=\u505C\u6B62\u76D1\u542C\u901A\u77E5
> 174: MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean:

This looks like a prefix, so instead of removing the space, it should be replaced with `\u0020` like other locations.
Also, it seems that other l10n files (de, ja) do not seem to have spaces in the first place.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 38:

> 36: resource.post-msi-script=Auszuf\u00FChrendes Skript nach dem Erstellen der MSI-Datei f\u00FCr das EXE-Installationsprogramm
> 37: resource.wxl-file=WiX-Lokalisierungsdatei
> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Shouldn't this be `de`?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 38:

> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
> 37: resource.wxl-file=WiX\u30ED\u30FC\u30AB\u30EA\u30BC\u30FC\u30B7\u30E7\u30F3\u30FB\u30D5\u30A1\u30A4\u30EB
> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Shouldn't this be `ja`?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 38:

> 36: resource.post-msi-script=\u5728\u4E3A exe \u5B89\u88C5\u7A0B\u5E8F\u521B\u5EFA msi \u6587\u4EF6\u4E4B\u540E\u8981\u8FD0\u884C\u7684\u811A\u672C
> 37: resource.wxl-file=WiX \u672C\u5730\u5316\u6587\u4EF6
> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Shouldn't this be `zh_CN`?

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: CNY=\uffe5

Do not remove this.

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Tue Jan 24 22:24:16 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:24:16 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
Message-ID: <udjE03vk_yctaqPPRo9TBHGxQ4j6j3pjO3h21WasMlU=.03434916-5c1b-4d44-a232-f43b4c928ec8@github.com>

On Tue, 24 Jan 2023 22:05:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change German help of jar command
>
> src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties line 174:
> 
>> 172: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON=\u53D6\u6D88\u8BA2\u9605(&U)
>> 173: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON_TOOLTIP=\u505C\u6B62\u76D1\u542C\u901A\u77E5
>> 174: MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean:
> 
> This looks like a prefix, so instead of removing the space, it should be replaced with `\u0020` like other locations.
> Also, it seems that other l10n files (de, ja) do not seem to have spaces in the first place.

OK, I can make the manual edit for this

> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 38:
> 
>> 36: resource.post-msi-script=\u5728\u4E3A exe \u5B89\u88C5\u7A0B\u5E8F\u521B\u5EFA msi \u6587\u4EF6\u4E4B\u540E\u8981\u8FD0\u884C\u7684\u811A\u672C
>> 37: resource.wxl-file=WiX \u672C\u5730\u5316\u6587\u4EF6
>> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl
> 
> Shouldn't this be `zh_CN`?

The translation tool seems to use the English source file's file name here, so it's replaced. I will handle these 3 occurrences now. I thought I handled all occurrences of this, but these 3 slipped in

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Tue Jan 24 22:33:24 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:33:24 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Change localization codes. Add CNY back

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/a2528015..40291c61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=01-02

  Stats: 4 lines in 4 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Tue Jan 24 22:33:28 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:33:28 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
Message-ID: <aSepuyRGkRCKZRV73viMQmYFsLPiygi9ty1PrPJAfOA=.847916eb-487b-4d07-9959-df8e9e178ac9@github.com>

On Tue, 24 Jan 2023 22:12:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change German help of jar command
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 38:
> 
>> 36: resource.post-msi-script=Auszuf\u00FChrendes Skript nach dem Erstellen der MSI-Datei f\u00FCr das EXE-Installationsprogramm
>> 37: resource.wxl-file=WiX-Lokalisierungsdatei
>> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl
> 
> Shouldn't this be `de`?

Changed back similar to with zh_CN

> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 38:
> 
>> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>> 37: resource.wxl-file=WiX\u30ED\u30FC\u30AB\u30EA\u30BC\u30FC\u30B7\u30E7\u30F3\u30FB\u30D5\u30A1\u30A4\u30EB
>> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl
> 
> Shouldn't this be `ja`?

Changed back similar to with zh_CN

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Tue Jan 24 22:33:29 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:33:29 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
Message-ID: <uWum8tAJrTs5hLSFFUV1E67SZFZsqqAsHpCELrLIMaM=.d90513b3-c6af-43a5-bb37-2024bcfc3f70@github.com>

On Tue, 24 Jan 2023 22:14:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change localization codes. Add CNY back
>
> src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63:
> 
>> 61: # written authorization of the copyright holder.
>> 62: 
>> 63: CNY=\uffe5
> 
> Do not remove this.

Added back. Thanks for catching this!

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From prr at openjdk.org  Tue Jan 24 22:44:13 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Jan 2023 22:44:13 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
Message-ID: <gQ5g-MSzzcsErcy0NLkwj4OOYoilBeIRyRHnNlZzfFM=.05615d12-452b-4bab-89cf-9ed5ffb91510@github.com>

On Tue, 24 Jan 2023 22:12:26 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change German help of jar command

Removing the trailing white space seems OK in the desktop resources.
I checked the base (English) version of the files and none of them have trailing white space so it seems unlikely it is significant.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116


From jlu at openjdk.org  Tue Jan 24 22:44:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 24 Jan 2023 22:44:14 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <udjE03vk_yctaqPPRo9TBHGxQ4j6j3pjO3h21WasMlU=.03434916-5c1b-4d44-a232-f43b4c928ec8@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
 <udjE03vk_yctaqPPRo9TBHGxQ4j6j3pjO3h21WasMlU=.03434916-5c1b-4d44-a232-f43b4c928ec8@github.com>
Message-ID: <asI2PH6xlHtgVW2Mj-E4puV5nna6IRYlNLeu2qIisXQ=.527599ac-16ce-41f1-bb92-263bb85b79f6@github.com>

On Tue, 24 Jan 2023 22:20:22 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties line 174:
>> 
>>> 172: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON=\u53D6\u6D88\u8BA2\u9605(&U)
>>> 173: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON_TOOLTIP=\u505C\u6B62\u76D1\u542C\u901A\u77E5
>>> 174: MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean:
>> 
>> This looks like a prefix, so instead of removing the space, it should be replaced with `\u0020` like other locations.
>> Also, it seems that other l10n files (de, ja) do not seem to have spaces in the first place.
>
> OK, I can make the manual edit for this

This change was made because it was compared to the original messages.properties. In that file, the respective line is given as `MANAGE_HOTSPOT_MBEANS_IN_COLON_=Manage Hotspot MBeans in:` with no trailing space. That's why in this file, to ensure consistency, the trailing space was stripped.

I think either this space should be removed, or all 4 (en, ja, de, zh) should have the `\u0020` appended. I agree that since it is a prefix it would make sense for a space to be there, but there is no guarantee that what comes after, or even the code that loads the .properties file does not already handles that necessary space.

Should the space remain removed like in the English source file and the other l10n files, or do you think all 4 should be changed to add `\u0020`?

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From duke at openjdk.org  Tue Jan 24 22:48:08 2023
From: duke at openjdk.org (Tres Finocchiaro)
Date: Tue, 24 Jan 2023 22:48:08 GMT
Subject: RFR: 8295737: macOS: Print content cut off when width > height
 with portrait orientation [v4]
In-Reply-To: <V5gvpteeBdnxA9CP2GvxRkNWQZkfXc4TwIQRTO4T6Gs=.e3a3c51d-0b29-483e-8bae-14fd12ac65d1@github.com>
References: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
 <V5gvpteeBdnxA9CP2GvxRkNWQZkfXc4TwIQRTO4T6Gs=.e3a3c51d-0b29-483e-8bae-14fd12ac65d1@github.com>
Message-ID: <f-HOHXYHJ1xT4VXjB7pVOMObC8V2Cif--dY3wIdkMzo=.237eb39a-34a6-4e5f-a7a7-4458b1db0a4b@github.com>

On Tue, 29 Nov 2022 10:36:32 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation.
>> 
>> To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS.
>> 
>> Four rectangles are printed:
>> 1. size 300x100, portrait orientation
>> 2. size 300x100, landscape orientation
>> 3. size 100x300, portrait orientation
>> 4. size 100x300, landscape orientation
>> 
>> The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf)
>> 
>> The reason is that NSPrintInfo class does not allow to set paper size and orientation independently.
>> Setting paper size width large than height changes NSPrintInfo orientation to landscape.
>> Setting paper size width less than height changes NSPrintInfo orientation to portrait.
>> Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height.
>> 
>> The Cocoa code that shows NSPrintInfo behavior:
>> 
>> #import <Cocoa/Cocoa.h>
>> 
>> int main()
>> {
>>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>>     NSApp = [NSApplication sharedApplication];
>> 
>>     #ifdef __MAC_10_9 // code for SDK 10.9 or newer
>>     #define NS_PORTRAIT NSPaperOrientationPortrait
>>     #define NS_LANDSCAPE NSPaperOrientationLandscape
>>     #else // code for SDK 10.8 or older
>>     #define NS_PORTRAIT NSPortraitOrientation
>>     #define NS_LANDSCAPE NSLandscapeOrientation
>>     #endif
>> 
>>     printf("NS_PORTRAIT: %d\n", NS_PORTRAIT);
>>     printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE);
>> 
>>     printf("create default print info\n");
>>     NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy];
>>     NSSize size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     printf("call setUpPrintOperationDefaultValues\n");
>>     [defaultPrintInfo setUpPrintOperationDefaultValues];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     double w = 300.0;
>>     double h = 100.0;
>>     printf("set size: [%f, %f]\n", w, h);
>>     [defaultPrintInfo setPaperSize:NSMakeSize(w, h)];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     printf("Set NS_PORTRAIT orientation\n");
>>     [defaultPrintInfo setOrientation: NS_PORTRAIT];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     [NSApp run];
>> 
>>     [NSApp release];
>>     [pool release];
>>     return(EXIT_SUCCESS);
>> } 
>> 
>> 
>> On macOS Mojave 10.14.5 it prints:
>> 
>> 
>> NS_PORTRAIT: 0
>> NS_LANDSCAPE: 1
>> create default print info
>> orientation: 0, paper size: [612.000000, 792.000000]
>> call setUpPrintOperationDefaultValues
>> orientation: 0, paper size: [612.000000, 792.000000]
>> set size: [300.000000, 100.000000]
>> orientation: 1, paper size: [300.000000, 100.000000] // orientation flip
>> Set NS_PORTRAIT orientation
>> orientation: 0, paper size: [100.000000, 300.000000] // size flip
>> ``` 
>> 
>> There are four possible cases for printing a rectangle with different size and orientation:
>> 1. Input: paper size: (w > h), orientation portrait
>>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: landscape
>>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (h, w), orientation: portrait
>>   Note: width and height are swapped
>> 2. Input: paper size: (w > h), orientation landscape
>>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: portrait
>>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (w, h), orientation: landscape
>> 3. Input: paper size: (w < h), orientation portrait
>>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: portrait
>>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (w, h), orientation: portrait
>> 4. Input: paper size: (w < h), orientation landscape
>>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: landscape
>>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (h, w), orientation: landscape
>>   Note: width and height are swapped
>> 
>> Only for cases 1 and 4 the final width and height are swapped.
>> The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle.
>> 
>> It is not full fix which draws rectangles for cases 1 and 4 in the requested size.
>> Setting requested size leads that subsequent orientation flips width and height.
>> The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix.
>> 
>> Printed rectangles before and after the fix:
>> 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf),  [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf)
>> 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf),  [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf)
>> 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf),  [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf)
>> 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf),  [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf)
>> 
>> All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf),  [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in FlipPageFormat class comments

Bumping for bots

-------------

PR: https://git.openjdk.org/jdk/pull/10808


From serb at openjdk.org  Tue Jan 24 22:53:11 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 24 Jan 2023 22:53:11 GMT
Subject: RFR: 8300929: Avoid unnecessary array fill after creation in
 java.awt.image
In-Reply-To: <RRBMqJ6kaMOo-9kIqxHinRmKReqnxaCSM_bkVTpPjyc=.2dbe497e-7078-4ab2-8ed5-e51f66971ac1@github.com>
References: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
 <RaGAJiwGcG8mxuY7kCdM2QG0AOn5zgzxb5LCLnnvXuI=.81c98a8a-e5a1-4a48-ae95-50d735bd45f1@github.com>
 <RRBMqJ6kaMOo-9kIqxHinRmKReqnxaCSM_bkVTpPjyc=.2dbe497e-7078-4ab2-8ed5-e51f66971ac1@github.com>
Message-ID: <4wl-9TD1_Q7eUgtGNlXVEwPgFvbJTvTIBIsJP8FfJ9U=.8c1ae7e9-df51-4e21-acba-62b2115e51fc@github.com>

On Tue, 24 Jan 2023 19:39:38 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/image/Raster.java line 372:
>> 
>>> 370:         for (int i = 0; i < bands; i++) {
>>> 371:             bankIndices[i] = i;
>>> 372:             bandOffsets[i] = 0;
>> 
>> I suggest to comment this line and adding a comment like "0 zero is the default value not need to be set"
>
> Yeah, please, no commented-out code. I'd be fine with the code as it was, I don't think it needs much clarification. If @mrserb insists on a comment then I agree that a comment on the array declaration should be sufficient.

That is not about the default values in the array but about missing initialization of `bandOffsets`, which we will skip intentionally. So it won't raise the question later why we initiated the Indices and not offsets.

-------------

PR: https://git.openjdk.org/jdk/pull/12147


From joehw at openjdk.org  Tue Jan 24 22:59:07 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 24 Jan 2023 22:59:07 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
Message-ID: <8IAAljdZ35sxC22s2SeFdCTX5xmx83YUFr8dwOYtXzA=.028e67c7-0969-4204-b843-0c0f2d79574f@github.com>

On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change localization codes. Add CNY back

Marked as reviewed by joehw (Reviewer).

java.xml changes look good to me. Thanks.

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From naoto at openjdk.org  Tue Jan 24 22:59:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Jan 2023 22:59:08 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <asI2PH6xlHtgVW2Mj-E4puV5nna6IRYlNLeu2qIisXQ=.527599ac-16ce-41f1-bb92-263bb85b79f6@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
 <udjE03vk_yctaqPPRo9TBHGxQ4j6j3pjO3h21WasMlU=.03434916-5c1b-4d44-a232-f43b4c928ec8@github.com>
 <asI2PH6xlHtgVW2Mj-E4puV5nna6IRYlNLeu2qIisXQ=.527599ac-16ce-41f1-bb92-263bb85b79f6@github.com>
Message-ID: <CsAAVzIKnnz5XUpUrnwieoCon_IUB2AloJD3f088IQ0=.cafe7f9a-af56-4ed0-a57a-10ac66ba0958@github.com>

On Tue, 24 Jan 2023 22:40:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> OK, I can make the manual edit for this
>
> This change was made because it was compared to the original messages.properties. In that file, the respective line is given as `MANAGE_HOTSPOT_MBEANS_IN_COLON_=Manage Hotspot MBeans in:` with no trailing space. That's why in this file, to ensure consistency, the trailing space was stripped.
> 
> I think either this space should be removed, or all 4 (en, ja, de, zh) should have the `\u0020` appended. I agree that since it is a prefix it would make sense for a space to be there, but there is no guarantee that what comes after, or even the code that loads the .properties file does not already handles that necessary space.
> 
> Should the space remain removed like in the English source file and the other l10n files, or do you think all 4 should be changed to add `\u0020`?

Confirmed that the message is for a label (`sun.tools.jconsole.LabeledComponent`), followed by a Component, so no space seems needed in each file. Sorry for the false alarm.

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Tue Jan 24 22:59:08 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:59:08 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <CsAAVzIKnnz5XUpUrnwieoCon_IUB2AloJD3f088IQ0=.cafe7f9a-af56-4ed0-a57a-10ac66ba0958@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
 <udjE03vk_yctaqPPRo9TBHGxQ4j6j3pjO3h21WasMlU=.03434916-5c1b-4d44-a232-f43b4c928ec8@github.com>
 <asI2PH6xlHtgVW2Mj-E4puV5nna6IRYlNLeu2qIisXQ=.527599ac-16ce-41f1-bb92-263bb85b79f6@github.com>
 <CsAAVzIKnnz5XUpUrnwieoCon_IUB2AloJD3f088IQ0=.cafe7f9a-af56-4ed0-a57a-10ac66ba0958@github.com>
Message-ID: <l0IK6fz7xp_c34lMdRgzs570ED6G2oXQ-CZwZ9pU1XU=.7b1893fe-06c8-4a9c-acf1-00ec66245dc2@github.com>

On Tue, 24 Jan 2023 22:49:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change was made because it was compared to the original messages.properties. In that file, the respective line is given as `MANAGE_HOTSPOT_MBEANS_IN_COLON_=Manage Hotspot MBeans in:` with no trailing space. That's why in this file, to ensure consistency, the trailing space was stripped.
>> 
>> I think either this space should be removed, or all 4 (en, ja, de, zh) should have the `\u0020` appended. I agree that since it is a prefix it would make sense for a space to be there, but there is no guarantee that what comes after, or even the code that loads the .properties file does not already handles that necessary space.
>> 
>> Should the space remain removed like in the English source file and the other l10n files, or do you think all 4 should be changed to add `\u0020`?
>
> Confirmed that the message is for a label (`sun.tools.jconsole.LabeledComponent`), followed by a Component, so no space seems needed in each file. Sorry for the false alarm.

Ok I left this change out of my most recent update just in case. I addressed all the other comments I believe. Thanks!

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From asemenyuk at openjdk.org  Tue Jan 24 22:59:12 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 24 Jan 2023 22:59:12 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
Message-ID: <SYT5AGvWO_Miz8XToU091Kyt7GKfYd167UmiGFLjy6Q=.963f58d4-d913-4ab4-abd3-8bb9c10ae16a@github.com>

On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change localization codes. Add CNY back

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="de-de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">

Please revert the value of the `Culture` attribute.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="ja-jp" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="932">

Please revert the value of the `Culture` attribute.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_zh_CN.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="zh-CN" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="936">

Please revert the value of the `Culture` attribute.

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From serb at openjdk.org  Tue Jan 24 23:02:03 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 24 Jan 2023 23:02:03 GMT
Subject: RFR: 8238170: BeanContextSupport remove and propertyChange can
 deadlock
In-Reply-To: <cHIwvUwEU6fS62odpaDPWdnE4tGbRPpr37GGHzxT_h0=.b47adbef-a383-458a-b50a-dc44e73f46ae@github.com>
References: <qS_fxqeO2UlPD7Tqkc7Iqe4vYVBn0Az4B328s7uVw_k=.5560c0f8-33e0-4fb5-bd25-08220ff8a8e3@github.com>
 <cHIwvUwEU6fS62odpaDPWdnE4tGbRPpr37GGHzxT_h0=.b47adbef-a383-458a-b50a-dc44e73f46ae@github.com>
Message-ID: <tTRbBs7OynO3ih6kMDUIh1R8bnUpYiOhnTvnrXy2gqM=.2adc8ba2-f74f-4d7b-b0e8-91e692daf493@github.com>

On Tue, 24 Jan 2023 20:12:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Oof... Approach for synchronization in `BeanContextServicesSupport` is confusing for me and inconsistent. Do you know why read access to `children` is not syncrhonized in `java.beans.beancontext.BeanContextSupport#add` ?
> 
> https://github.com/openjdk/jdk/blob/3be5758bb413fb6b4dc6191d78ca38332d5153f1/src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java#L394

Because synchronization in that class is mostly broken.

> // test before locking

I think it is an attempt to make a performance optimization even if it has a race, not sure that it works as expected.

-------------

PR: https://git.openjdk.org/jdk/pull/12158


From jlu at openjdk.org  Tue Jan 24 23:06:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 24 Jan 2023 23:06:14 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
Message-ID: <NHJe4Mt27DnzPaNGgGPmBegrpITlHxclp91qKggg9Xg=.899a3122-736b-48d9-a564-f629ad1e3096@github.com>

On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change localization codes. Add CNY back

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_ja.properties line 62:

> 60: dedup-legal-notices.usage=\  --dedup-legal-notices [error-if-not-same-content]\n                            \u3059\u3079\u3066\u306E\u6CD5\u5F8B\u4E0A\u306E\u6CE8\u610F\u70B9\u306E\u91CD\u8907\u3092\u9664\u5916\u3057\u307E\u3059\u3002\n                            error-if-not-same-content\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u3001\n                            \u540C\u3058\u30D5\u30A1\u30A4\u30EB\u540D\u306E2\u3064\u306E\u30D5\u30A1\u30A4\u30EB\u304C\u7570\u306A\u3063\u3066\u3044\u308B\u3068\n                            \u30A8\u30E9\u30FC\u306B\u306A\u308A\u307E\u3059\u3002
> 61: 
> 62: exclude-files.argument=\u9664\u5916\u3059\u308B\u30D5\u30A1\u30A4\u30EB\u306E<pattern-list> 

It seems like the translation process added a space here, but it does not appear in the original. This should be removed.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 194:

> 192: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
> 193: 
> 194: main.plugin.category=\u7C7B\u522B 

Same as above.

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From asemenyuk at openjdk.org  Tue Jan 24 23:19:12 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 24 Jan 2023 23:19:12 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
Message-ID: <53tinlttCmtNrOBaz7F54bKSeftrurnsr9OVoQzzjC8=.191b9195-e775-4b4b-8811-d34789cec36e@github.com>

On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change localization codes. Add CNY back

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_zh_CN.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="zh-CN" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="936">

Please revert the value of the Culture attribute.

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From achung at openjdk.org  Tue Jan 24 23:23:32 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 24 Jan 2023 23:23:32 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v2]
In-Reply-To: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
Message-ID: <_F66GasxdremocPjHV9uOyJLZQy83LD3KZ7FJFgtPU4=.f8e837d5-8ebc-4f10-8849-47334cb213d9@github.com>

> Fixed test bug where mouse location was being calculated before robot mouseMove operation was complete

Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - re-test
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8292588/MultiScreenLocationTest
 - added robot wait to prevent mouse position from being calculated before robot finishes mouseMove

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10363/files
  - new: https://git.openjdk.org/jdk/pull/10363/files/e54b2739..281589c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10363&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10363&range=00-01

  Stats: 470448 lines in 7446 files changed: 239380 ins; 152172 del; 78896 mod
  Patch: https://git.openjdk.org/jdk/pull/10363.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10363/head:pull/10363

PR: https://git.openjdk.org/jdk/pull/10363


From achung at openjdk.org  Tue Jan 24 23:30:04 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 24 Jan 2023 23:30:04 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v2]
In-Reply-To: <u_xoruMy7Z4J9sy0zrJbeBiolJq0DhzjlheR92GXRSQ=.c28a5857-7d6e-468f-b342-38a4b50df6dc@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
 <xSKq7POrfrJ4KYYBA8crdY5rJCjciMK4NEK-LZTcjDk=.8161df0a-2d8c-4784-948b-b7632af2d7e0@github.com>
 <2JMfR5LPnaps6mypICTmVJ06Wvz-aM8TZCUCGFtPfRI=.a2f95c1a-08e4-484d-b9bd-d2e2de8b7a93@github.com>
 <BR-jEkqs-cfBcLbYOIochka2ttiiXyyeVEbWMXq-ZPY=.d124a284-b194-4cf5-b4f5-8faf6c7a5856@github.com>
 <u_xoruMy7Z4J9sy0zrJbeBiolJq0DhzjlheR92GXRSQ=.c28a5857-7d6e-468f-b342-38a4b50df6dc@github.com>
Message-ID: <dbDsSlJPi8DKDXev_48YFIorx3IJBGetffypTOuSx-0=.f61aafda-9142-4e70-8dc7-187970b449a5@github.com>

On Tue, 11 Oct 2022 00:25:04 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>>> > Can we move the test file to one directory back as we are doing it in swing test fix. Means moving the test to Multscreen folder, instead of MultiScreenLocationTest.....?
>>> 
>>> I second this. The test can sit inside the Multiscreen folder without the need for a subfolder to match the way new tests are added.
>> 
>> I prefer leaving the test at its original location. It's not a new test, it has a history in CI. Although, if everyone else thinks the test should be moved up, it's okay with me.
>> 
>> Previously, each test had its own folder. Now, we tend to use flatter structure.
>
>> > > Can we move the test file to one directory back as we are doing it in swing test fix. Means moving the test to Multscreen folder, instead of MultiScreenLocationTest.....?
>> > 
>> > 
>> > I second this. The test can sit inside the Multiscreen folder without the need for a subfolder to match the way new tests are added.
>> 
>> I prefer leaving the test at its original location. It's not a new test, it has a history in CI. Although, if everyone else thinks the test should be moved up, it's okay with me.
>> 
>> Previously, each test had its own folder. Now, we tend to use flatter structure.
> 
> If that's the case, I have nothing else against keeping it in its current location. I had the impression to update tests (such as syntax) as they're updated, but I can understand why updating its location may be useful.

@DamonGuy @jayathirthrao can you double check which part of the test fails? Does the Robot.mouseMove, Robot.getPixelColor, or Robot.getScreenCapture fail on your machine?

-------------

PR: https://git.openjdk.org/jdk/pull/10363


From dnguyen at openjdk.org  Tue Jan 24 23:38:23 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 23:38:23 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v4]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <T2H6mU3enuaNrLKae6YLvpA313QW2F1gfnXOzKhYP20=.d188ea58-f00e-4782-a508-ba25ed9f8819@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Remove trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/40291c61..fc32c37f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116


From prr at openjdk.org  Tue Jan 24 23:39:38 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Jan 2023 23:39:38 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url)
Message-ID: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>

SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
So deprecating - for removal - and adding warnings now in the docs is appropriate.

-------------

Commit messages:
 - 8300891
 - 8300891

Changes: https://git.openjdk.org/jdk/pull/12175/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12175&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300891
  Stats: 18 lines in 2 files changed: 18 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12175.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12175/head:pull/12175

PR: https://git.openjdk.org/jdk/pull/12175


From dnguyen at openjdk.org  Tue Jan 24 23:56:23 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 23:56:23 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert culture attribute

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/fc32c37f..616b2502

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=03-04

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Tue Jan 24 23:59:13 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 23:59:13 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <NHJe4Mt27DnzPaNGgGPmBegrpITlHxclp91qKggg9Xg=.899a3122-736b-48d9-a564-f629ad1e3096@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
 <NHJe4Mt27DnzPaNGgGPmBegrpITlHxclp91qKggg9Xg=.899a3122-736b-48d9-a564-f629ad1e3096@github.com>
Message-ID: <tro5Qie7pi8hcU2dfXbz7Ew2P5_UBRDcEhohq7MBBmc=.ccef1231-0bb4-457d-8f3c-78878c6e98bb@github.com>

On Tue, 24 Jan 2023 23:02:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change localization codes. Add CNY back
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_ja.properties line 62:
> 
>> 60: dedup-legal-notices.usage=\  --dedup-legal-notices [error-if-not-same-content]\n                            \u3059\u3079\u3066\u306E\u6CD5\u5F8B\u4E0A\u306E\u6CE8\u610F\u70B9\u306E\u91CD\u8907\u3092\u9664\u5916\u3057\u307E\u3059\u3002\n                            error-if-not-same-content\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u3001\n                            \u540C\u3058\u30D5\u30A1\u30A4\u30EB\u540D\u306E2\u3064\u306E\u30D5\u30A1\u30A4\u30EB\u304C\u7570\u306A\u3063\u3066\u3044\u308B\u3068\n                            \u30A8\u30E9\u30FC\u306B\u306A\u308A\u307E\u3059\u3002
>> 61: 
>> 62: exclude-files.argument=\u9664\u5916\u3059\u308B\u30D5\u30A1\u30A4\u30EB\u306E<pattern-list> 
> 
> It seems like the translation process added a space here, but it does not appear in the original. This should be removed.

Removed both instances of the extra trailing whitespace.

> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 194:
> 
>> 192: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
>> 193: 
>> 194: main.plugin.category=\u7C7B\u522B 
> 
> Same as above.

Addressed as above

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Tue Jan 24 23:59:17 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 23:59:17 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <SYT5AGvWO_Miz8XToU091Kyt7GKfYd167UmiGFLjy6Q=.963f58d4-d913-4ab4-abd3-8bb9c10ae16a@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
 <SYT5AGvWO_Miz8XToU091Kyt7GKfYd167UmiGFLjy6Q=.963f58d4-d913-4ab4-abd3-8bb9c10ae16a@github.com>
Message-ID: <wT1oblMLJ8pV6MGHIXybIcNIp71p6Gm4AT0VQgbfTzA=.06b8ac34-8d10-4e71-a596-b64f856c6b27@github.com>

On Tue, 24 Jan 2023 22:55:43 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change German help of jar command
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:
> 
>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>> 2: <WixLocalization Culture="de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">
> 
> Please revert the value of the `Culture` attribute.

I resolved this for the German, Japanese, and Chinese files in the latest commit.

> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 2:
> 
>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>> 2: <WixLocalization Culture="ja" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="932">
> 
> Please revert the value of the `Culture` attribute.

Resolved in recent commit

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Tue Jan 24 23:59:19 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 23:59:19 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <53tinlttCmtNrOBaz7F54bKSeftrurnsr9OVoQzzjC8=.191b9195-e775-4b4b-8811-d34789cec36e@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
 <53tinlttCmtNrOBaz7F54bKSeftrurnsr9OVoQzzjC8=.191b9195-e775-4b4b-8811-d34789cec36e@github.com>
Message-ID: <oM9Wt1fwilca-26aYPtGk-oarvJai1SJ6UgYbfw2Yao=.c0ab676d-eeb8-4c8b-9219-20bd58c4b32c@github.com>

On Tue, 24 Jan 2023 23:16:02 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change localization codes. Add CNY back
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_zh_CN.wxl line 2:
> 
>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>> 2: <WixLocalization Culture="zh-CN" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="936">
> 
> Please revert the value of the Culture attribute.

Resolved in recent commit

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From asemenyuk at openjdk.org  Wed Jan 25 00:12:09 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 25 Jan 2023 00:12:09 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <HxDebTNqUdnnPbK_vZ7sFzNng3LygKgZCCajLqQYoKY=.08357b3d-91d8-4871-9c14-f73053d8a7af@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

jpackage changes look good

-------------

Marked as reviewed by asemenyuk (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116


From serb at openjdk.org  Wed Jan 25 00:16:04 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 25 Jan 2023 00:16:04 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url)
In-Reply-To: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
Message-ID: <xdd1noewmTkvb3f-QjNR5vgq4ax5kEo6Lt6a1fEU0I4=.cdb271eb-70eb-4b7c-b7d4-cf5db24cecc9@github.com>

On Tue, 24 Jan 2023 23:29:58 GMT, Phil Race <prr at openjdk.org> wrote:

> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
> So deprecating - for removal - and adding warnings now in the docs is appropriate.

I do not think that this method should/must be used by custom L&F only, it is a way to provide custom styles for an existing L&f including Nimbus like discussed here:
https://stackoverflow.com/questions/11564597/how-to-use-synthlookandfeel-with-xml-file-where-xml-file-path-will-load-the-fil
There is a way to check the permission - security manager, ohh we deprecated it as well, time to rethink that? or do we plan to delete all methods which use URL, or add custom properties here and there to check access?

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From jlu at openjdk.org  Wed Jan 25 01:11:15 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jan 2023 01:11:15 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <zEwbMCW5Eq8q0rv8_F8m2iddDj6z-QdBCfiT8w93Di0=.b0991198-41b8-4204-aafe-32bedd2974f7@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

Marked as reviewed by jlu (Author).

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From prr at openjdk.org  Wed Jan 25 01:50:06 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Jan 2023 01:50:06 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url)
In-Reply-To: <xdd1noewmTkvb3f-QjNR5vgq4ax5kEo6Lt6a1fEU0I4=.cdb271eb-70eb-4b7c-b7d4-cf5db24cecc9@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <xdd1noewmTkvb3f-QjNR5vgq4ax5kEo6Lt6a1fEU0I4=.cdb271eb-70eb-4b7c-b7d4-cf5db24cecc9@github.com>
Message-ID: <a7_9RQOd4ze3LkQGZlC5hyXbcBOjhQch9Y7AqSwUBw4=.c249a1c1-e929-4993-8c84-2e4bb6dffe18@github.com>

On Wed, 25 Jan 2023 00:13:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I do not think that this method should/must be used by custom L&F only, it is a way to provide custom styles for an existing L&f including Nimbus like discussed here:
> https://stackoverflow.com/questions/11564597/how-to-use-synthlookandfeel-with-xml-file-where-xml-file-path-will-load-the-fil
> There is a way to check the permission - security manager, ohh we deprecated it as well, time to rethink that? or do we plan to delete all methods which use URL, or add custom properties here and there to check access?

Who knows, we may deprecate more methods when there's a good reason,
but this one regardless of whether it is the sole source of styles for a Synth L&F or customisation is a prime candidate for deprecation and subsequent removal.

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From duke at openjdk.org  Wed Jan 25 01:52:13 2023
From: duke at openjdk.org (duke)
Date: Wed, 25 Jan 2023 01:52:13 GMT
Subject: Withdrawn: 8295248: JEditorPane HTML form with multi-selection broke
 data after resetting
In-Reply-To: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
References: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
Message-ID: <56sCaaMLzD_g_ZIFFYaJbKVzdomThqJ4zDNcOUUBkcI=.768fde16-a0e1-4be7-b5f2-74a1cc5cc9f9@github.com>

On Thu, 13 Oct 2022 01:48:45 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> When JEditorPane shown HTML form with multi-selection, the reset operation broke its data.
> 
> The sample testcase were attached in JBS. The recreate steps are below:
> 1. The sample shows a multi-selection form with 5 items.
> 2. Select the 4th item.
> 3. Press the reset button.
> Actual: The 4th item is still selected.
> Expect: No item should be selected. Resetting operation may move to the initial state. The sample doesn't use 'selected' property in each option tag.
> 4. Just after the step 3, move the focus to outside of the application and back.
> Actual: The 2nd item is selected. It means inside data indicates so.
> Expect: No item is selected.
> 
> There are two issues. The current method `OptionListModel.removeIndexInterval()` removed the indexed item, and shifted the rest. Then, selection values were corrupted.
> I think the clear selection method `OptionListModel.clearSelection()` is suitable here.
> 
> Test: jdk_desktop on macOS (x64, Monterey), Linux (x64, RHEL8), and Windows (x64, 2012R2).
>       No regression found

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10685


From duke at openjdk.org  Wed Jan 25 02:00:06 2023
From: duke at openjdk.org (ScientificWare)
Date: Wed, 25 Jan 2023 02:00:06 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v4]
In-Reply-To: <V_RDZRd3lBHSD6XCLj_TM4-wxZGXZw0y7R7QPneYNuY=.d2722225-fae2-47d1-8545-52dee5949d3b@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
 <V_RDZRd3lBHSD6XCLj_TM4-wxZGXZw0y7R7QPneYNuY=.d2722225-fae2-47d1-8545-52dee5949d3b@github.com>
Message-ID: <qHTJK6-ryxxZ7gyL9zKoGzAFJMyVM_uHWiFI_bNd7HY=.be5e281c-6e4f-40ea-9e9d-52af2ad57493@github.com>

On Wed, 28 Dec 2022 00:10:53 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8296661)
>> 
>> This is tracked in JBS as 
>> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.openjdk.java.net/browse/JDK-8296661)
>> 
>> I suspect a typo in the documentation comments.
>> 
>> Designed from : [ScientificWare JDK-8296661 : Typo Found In CSSParser.java](https://github.com/scientificware/jdk/issues/18)
>
> ScientificWare has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update Copyright.
>    
>    Change date.
>  - Suggested improvements.
>    
>    - Add missing {@code} tags and update <code> tag with {@code} tag.
>    - Add a paragraph to improve readability

Please, don't close this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/10975


From duke at openjdk.org  Wed Jan 25 03:47:08 2023
From: duke at openjdk.org (Nikita Provotorov)
Date: Wed, 25 Jan 2023 03:47:08 GMT
Subject: RFR: 8282217: Key events (key char and key code) changed for Swiss
 keyboard [v2]
In-Reply-To: <wDc27Q7Dva-G4BaW8mNU1ytaYrDE65zL5MFP3JeEMY4=.d12138b0-0092-4a5d-833e-ec6eb7b6d8ad@github.com>
References: <N9XfS6cL8s1G98UAiEr7ZvgzQB-HX6qKGptKZe7d810=.1f5932c5-fd00-4fe8-9c0b-99f2fa71d880@github.com>
 <wDc27Q7Dva-G4BaW8mNU1ytaYrDE65zL5MFP3JeEMY4=.d12138b0-0092-4a5d-833e-ec6eb7b6d8ad@github.com>
Message-ID: <piu-V-YCChg4lWBwaIr5LoRZCcMq3Y9eMipUnRhPhJs=.45ed2821-3b64-4b0e-a02f-7b9a0f625dd8@github.com>

On Tue, 24 Jan 2023 20:14:20 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Removed check for MapVirtualKeyEx return value causing some keys to become undefined
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   readded check for dead key leading bit, added separate check for group separator

Changes requested by NikitkoCent at github.com (no known OpenJDK username).

src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 3620:

> 3618:     int converted = 1;
> 3619:     UINT ch = ::MapVirtualKeyEx(wkey, 2, GetKeyboardLayout());
> 3620:     if (ch & 0x80000000 && ch != 0x800000A8) {

1. It doesn't work for third key press in case of key's pressing 3 times in a row
2. Adding the workaround here is a quite dangerous because it affects the state of the `deadKeyActive` flag. I think it could break some exotic cases, e.g. when the char is used as a [chained dead key](https://en.wikipedia.org/wiki/Dead_key#Chained_dead_keys).

Actually I don't believe that adjusting logic of reporting keyChars for KEY_PRESSED events is the right way. The specification clearly says
> the result of the getKeyChar method is guaranteed to be meaningful only for KEY_TYPED events

So clients can't depend on that IMHO.

-------------

PR: https://git.openjdk.org/jdk/pull/11887


From duke at openjdk.org  Wed Jan 25 04:11:05 2023
From: duke at openjdk.org (SWinxy)
Date: Wed, 25 Jan 2023 04:11:05 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v4]
In-Reply-To: <XQc1zO2_1zdGa9qZ7uI0V6EzSwf4CWw7hl2B4-d8Enc=.c2a9f7e8-03f8-4b02-b823-6385da2968b0@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
 <zbvDGc4EHbOQfvq8srOEeTwlyfraCuDbRYN0jXDo7RE=.dfa036b5-bebe-4d7c-af1a-ab8328184328@github.com>
 <XQc1zO2_1zdGa9qZ7uI0V6EzSwf4CWw7hl2B4-d8Enc=.c2a9f7e8-03f8-4b02-b823-6385da2968b0@github.com>
Message-ID: <qkLl0-C47p2cUZmWDOOgIL1HSbpWFqOAdEHTgj1QN5A=.c6745d19-297e-4c1b-81aa-f8262b3a6337@github.com>

On Mon, 12 Dec 2022 13:06:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Looks good to me.
>> 
>> In the description above: ??invoked one per property??, it shoud be ?once?.
>> 
>> I think there's room for improvement. However, this is an internal-only class.
>
>> I think there's room for improvement. However, this is an internal-only class.
> 
> This is what I have in mind. The list of callbacks is inconsistent in how the method and conditions when it's called are listed. One of the list items has no ending punctuation. Some portions of text should use `<code>` or `{@code}`, or even [`<samp>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/samp).
> 
> I think `<p>` should be added before this sentence, _?If an error results in parsing, a RuntimeException will be thrown.?_ The sentence itself requires re-writing: ?If parsing results in an error??
> 
> Both `RuntimeException` and `toLowerCase` below should be in `{@code}`.
> 
> The usage of `<code>` could be updated to `{@code}` which is the recommended way.
> 
> What do you think?

I think a Reviewer needs to re-review before it asks for sponsoring. @aivanov-jdk: re-approve changes?

-------------

PR: https://git.openjdk.org/jdk/pull/10975


From psadhukhan at openjdk.org  Wed Jan 25 05:51:11 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 25 Jan 2023 05:51:11 GMT
Subject: Integrated: 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal
 Frame throws a NPE.
In-Reply-To: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
References: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
Message-ID: <_KCuRe61i-iOOrHhScqqg8iO_pO_0NsLLSWijrTBifU=.0d2e105d-a9dd-45dd-9a0d-02f0f436d143@github.com>

On Fri, 9 Dec 2022 08:06:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In Swingset2 JInternalFrame demo, focusing on any internalframes and pressing Ctrl+F7 and then any of up/down/left/arrow key to move the internal frames results in NPE in NimbusL&F.
> It is because `JComponent.processKeyBinding() `calls `SwingUtilities.notifyAction` which calls `BasicDesktopPaneUI.actionPerformed` where it gets `Desktop.minOnScreenInsets` property to get the Insets and then uses insets.top/bottom/left/right value to move the internalframe but this property is not defined for Nimbus so deferencing Insets object results in NPE.
> 
> Fix is added to create a 0 insets incase some L&F do not define` Desktop.minOnScreenInsets` property.
> No regression test is added as it can be easily checked by SwingSet2 JInternalFrame demo.

This pull request has now been integrated.

Changeset: 7465de45
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7465de453afac9499582cb8c7573bcdc988f623b
Stats:     138 lines in 2 files changed: 138 ins; 0 del; 0 mod

6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame throws a NPE.

Reviewed-by: abhiscxk, serb

-------------

PR: https://git.openjdk.org/jdk/pull/11605


From psadhukhan at openjdk.org  Wed Jan 25 06:48:33 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 25 Jan 2023 06:48:33 GMT
Subject: RFR: 8297454: javax/swing/JComponent/7154030/bug7154030.java failed
 with "Exception: Failed to show opaque button"
Message-ID: <nIuP21ewUd0nALclypyH1ULkFk_cAq5q34LIxmCloUs=.a7326479-4586-4a2f-bb38-15d572a4512d@github.com>

Test intermittently failed in CI macos system owing to robot screencapture failing to compare the images.
Seems like from artifacts, that composite image created by robot contains mouse cursor, which when compared are not giving exact pixel color. This has occurred in the past also for some tests for which we have made the mouseMove to move mouse cursor outside the area being captured for pixel comparison.
Similar fix is done whereby mouse is moved to outside the captured area. Several iterations in CI are ok.

-------------

Commit messages:
 - 8297454: javax/swing/JComponent/7154030/bug7154030.java failed with Exception: Failed to show opaque button

Changes: https://git.openjdk.org/jdk/pull/12179/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12179&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297454
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12179.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12179/head:pull/12179

PR: https://git.openjdk.org/jdk/pull/12179


From psadhukhan at openjdk.org  Wed Jan 25 06:48:33 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 25 Jan 2023 06:48:33 GMT
Subject: RFR: 8297454: javax/swing/JComponent/7154030/bug7154030.java
 failed with "Exception: Failed to show opaque button"
In-Reply-To: <nIuP21ewUd0nALclypyH1ULkFk_cAq5q34LIxmCloUs=.a7326479-4586-4a2f-bb38-15d572a4512d@github.com>
References: <nIuP21ewUd0nALclypyH1ULkFk_cAq5q34LIxmCloUs=.a7326479-4586-4a2f-bb38-15d572a4512d@github.com>
Message-ID: <c-9ExvlE74lm2_5HyrwfUyHhjlMEiKUovrc0nHjghWQ=.6bd6e7f9-2b68-4199-b0ba-42dfd902faf1@github.com>

On Wed, 25 Jan 2023 06:41:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test intermittently failed in CI macos system owing to robot screencapture failing to compare the images.
> Seems like from artifacts, that composite image created by robot contains mouse cursor, which when compared are not giving exact pixel color. This has occurred in the past also for some tests for which we have made the mouseMove to move mouse cursor outside the area being captured for pixel comparison.
> Similar fix is done whereby mouse is moved to outside the captured area. Several iterations in CI are ok.

@azuev-java can you please review?

-------------

PR: https://git.openjdk.org/jdk/pull/12179


From psadhukhan at openjdk.org  Wed Jan 25 06:53:43 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 25 Jan 2023 06:53:43 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
Message-ID: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>

Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
Fix is made to reset the font if it is set by L&F.

-------------

Commit messages:
 - 6753661: JFileChooser font not reset after Look & Feel change

Changes: https://git.openjdk.org/jdk/pull/12180/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12180&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6753661
  Stats: 55 lines in 2 files changed: 55 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12180.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12180/head:pull/12180

PR: https://git.openjdk.org/jdk/pull/12180


From duke at openjdk.org  Wed Jan 25 08:20:13 2023
From: duke at openjdk.org (danielpeintner)
Date: Wed, 25 Jan 2023 08:20:13 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
Message-ID: <TsM2mpquBl2wvitATox3_QNHuSrQLhZN0MFsaaINyHg=.41bef814-3f17-402b-be0d-a1797114bbee@github.com>

On Tue, 24 Jan 2023 22:12:26 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change German help of jar command

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 111:

> 109: main.help.opt.main.update=\  -u, --update               Ein vorhandenes JAR-Archiv aktualisieren
> 110: main.help.opt.main.extract=\  -x, --extract              Benannte (oder alle) Dateien aus dem Archiv extrahieren
> 111: main.help.opt.main.describe-module=\  -d, --describe-module      Gibt den Moduldeskriptor oder automatischen Modulnamen aus

Just because I stumbled over this commit. I think the line should be translated as follows:

`Gibt die Modulbeschreibung oder den automatischen Modulnamen aus`

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From psadhukhan at openjdk.org  Wed Jan 25 08:48:51 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 25 Jan 2023 08:48:51 GMT
Subject: RFR: 8299713: Test javax/swing/JTableHeader/6889007/bug6889007.java
 failed: Wrong type of cursor
Message-ID: <jCkdfVb8ZEVUlr6xDdIqYSPDo3cFJKwtOzETYdgwqQU=.42068408-50e6-4d56-8167-f76b44242db7@github.com>

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.

-------------

Commit messages:
 - 8299713: Test javax/swing/JTableHeader/6889007/bug6889007.java failed: Wrong type of cursor
 - 8299713: Test javax/swing/JTableHeader/6889007/bug6889007.java failed: Wrong type of cursor

Changes: https://git.openjdk.org/jdk/pull/12181/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12181&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299713
  Stats: 64 lines in 1 file changed: 40 ins; 5 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/12181.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12181/head:pull/12181

PR: https://git.openjdk.org/jdk/pull/12181


From duke at openjdk.org  Wed Jan 25 13:22:31 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 25 Jan 2023 13:22:31 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v17]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <hF3_a7jZr5PrfWlGeu3r8585eaCKP1fLSNN0xhOGpzQ=.62524ef2-4726-4b87-bde8-3181bd8d70d3@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:

  Skip tests if required font is absent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/4798/files
  - new: https://git.openjdk.org/jdk/pull/4798/files/4c078054..4d4fadb4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=15-16

  Stats: 28 lines in 4 files changed: 23 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/4798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/4798/head:pull/4798

PR: https://git.openjdk.org/jdk/pull/4798


From lancea at openjdk.org  Wed Jan 25 13:45:21 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 25 Jan 2023 13:45:21 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <DhnLBlhufb7h62qL0BwYg-_kg8ttfCWuViNBhrYhAcs=.88b29cf5-12bd-4cac-9d43-b0b123d0c1b4@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From ihse at openjdk.org  Wed Jan 25 13:56:21 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 25 Jan 2023 13:56:21 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <-Mjbn1ko2InJOzXLccieEzU8h4bypdm9vTzHdmtA-JQ=.2e1f4d59-e30e-434a-8e62-25777adb3a07@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

I skimmed through this, basically looking for trailing white space changes only, and it generally looks okay.

Note that some of these trailing whitespace fixes has been independently address in mainline. Forward-porting this might involve some (virtual) conflicts.

It is also impossible to see in the Github interface if you are introducing *new* trailing white spaces in the added texts. I hope you are not, and that you have verified this.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116


From tr at openjdk.org  Wed Jan 25 14:27:04 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 25 Jan 2023 14:27:04 GMT
Subject: RFR: 8300405: Screen capture for test
 JFileChooserSetLocationTest.java, failure case [v2]
In-Reply-To: <y1mXha8588A2Q5COj5KR405oPvIXnw6mj6a999x-gKU=.95b9b5be-08bf-43b8-9b9e-641bf037c390@github.com>
References: <H9i4szvE-s7cWX1cu8bkx6nLa3yvB44bftLmYbbfhvM=.a5ae761a-cfe3-4a71-80b2-88bbb6ae7858@github.com>
 <0NOxQ1_CSyxQUp8B9fHVTWB2336tMohLsAVeNGbkCsY=.6ffbabef-d409-41ec-b777-7de6fa5b2a80@github.com>
 <iWjXSjAapcQc8htKJrHeJS2ETnyNwW0ma7u30eZrsR4=.5e3433f2-2b59-4bf0-8d80-530507549280@github.com>
 <y1mXha8588A2Q5COj5KR405oPvIXnw6mj6a999x-gKU=.95b9b5be-08bf-43b8-9b9e-641bf037c390@github.com>
Message-ID: <hu9QSn4qB1TeyWuv04ByJZce5JnZcFH2zEuZTwGT2hQ=.9a98216a-a928-4a36-a493-a48eac7ef377@github.com>

On Fri, 20 Jan 2023 15:10:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> GraphicsConfiguration gc = GraphicsEnvironment.
>>                          getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();
>>                 Rectangle gcBounds = gc.getBounds();
>> 
>> This way?
>
> yes.

Updated.

-------------

PR: https://git.openjdk.org/jdk/pull/12060


From tr at openjdk.org  Wed Jan 25 14:32:35 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 25 Jan 2023 14:32:35 GMT
Subject: RFR: 8300549: JFileChooser Approve button tooltip is null in Aqua L&F
 in CUSTOM_DIALOG mode
Message-ID: <IPLzXe7hJxn5KukI-eFxqO1CJNDO_g70pUBOlwLewIA=.68dd5394-541a-4096-8dce-99f2b6156b0d@github.com>

_JFilechooser_ returns _null_ for Approve button tool tip in `CUSTOM_DIALOG` mode (`getToolTipText()`). The fallback text has been set to "Choose" text. Observation found in validating the test of PR - #11901.

-------------

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/12198/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12198&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300549
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12198.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12198/head:pull/12198

PR: https://git.openjdk.org/jdk/pull/12198


From angorya at openjdk.org  Wed Jan 25 16:15:07 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 25 Jan 2023 16:15:07 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v4]
In-Reply-To: <V_RDZRd3lBHSD6XCLj_TM4-wxZGXZw0y7R7QPneYNuY=.d2722225-fae2-47d1-8545-52dee5949d3b@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
 <V_RDZRd3lBHSD6XCLj_TM4-wxZGXZw0y7R7QPneYNuY=.d2722225-fae2-47d1-8545-52dee5949d3b@github.com>
Message-ID: <cklPvHsQ2zf4Edwj8lbqiaMIvxuVLsmzD2fhUgTrCvM=.e02d3b3a-7326-4de7-9eb2-bd71a79d8072@github.com>

On Wed, 28 Dec 2022 00:10:53 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8296661)
>> 
>> This is tracked in JBS as 
>> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.openjdk.java.net/browse/JDK-8296661)
>> 
>> I suspect a typo in the documentation comments.
>> 
>> Designed from : [ScientificWare JDK-8296661 : Typo Found In CSSParser.java](https://github.com/scientificware/jdk/issues/18)
>
> ScientificWare has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update Copyright.
>    
>    Change date.
>  - Suggested improvements.
>    
>    - Add missing {@code} tags and update <code> tag with {@code} tag.
>    - Add a paragraph to improve readability

> Pre-submit tests - linux-x86 / test - Test (tier1) Failing after 67m ? 1/9 failed

do we know why this test is failing?

src/java.desktop/share/classes/javax/swing/text/html/CSSParser.java line 2:

> 1: /*
> 2:  * Copyright (c) 1999, 2022, Oracle and/or its affiliates. All rights reserved.

should it be 2023 now?

-------------

PR: https://git.openjdk.org/jdk/pull/10975


From naoto at openjdk.org  Wed Jan 25 16:55:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Jan 2023 16:55:04 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <cAC0d_Qt7wDZq7kMDzQPm2QO8NrgIF5XMMvxq4Bhcc4=.131687a3-5000-4bee-af43-05d577b19748@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116


From duke at openjdk.org  Wed Jan 25 16:56:37 2023
From: duke at openjdk.org (SWinxy)
Date: Wed, 25 Jan 2023 16:56:37 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v4]
In-Reply-To: <cklPvHsQ2zf4Edwj8lbqiaMIvxuVLsmzD2fhUgTrCvM=.e02d3b3a-7326-4de7-9eb2-bd71a79d8072@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
 <V_RDZRd3lBHSD6XCLj_TM4-wxZGXZw0y7R7QPneYNuY=.d2722225-fae2-47d1-8545-52dee5949d3b@github.com>
 <cklPvHsQ2zf4Edwj8lbqiaMIvxuVLsmzD2fhUgTrCvM=.e02d3b3a-7326-4de7-9eb2-bd71a79d8072@github.com>
Message-ID: <v7vi4wm2N9cX0-kSC7xfG_AfKWiMosXIirgwlKpcGec=.4e3a7adc-4ded-4b8c-8917-7d15f1f03539@github.com>

On Wed, 25 Jan 2023 16:13:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> do we know why this test is failing?

Doesn't matter; it's javadoc changes only. Pre-submit tests randomly fail sometimes for no good reason.

-------------

PR: https://git.openjdk.org/jdk/pull/10975


From weijun at openjdk.org  Wed Jan 25 17:36:38 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 25 Jan 2023 17:36:38 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <_THK1t7SrTRqoW0o0gfgmCo1Ea1WfgdfeB7jNJDKUKk=.05512373-8cb2-41d3-a71f-589075240bb7@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties line 32:

> 30: err.bad.constant.pool=\u8BFB\u53D6{0}\u7684\u5E38\u91CF\u6C60\u65F6\u51FA\u9519: {1}
> 31: err.class.not.found=\u627E\u4E0D\u5230\u7C7B: {0}
> 32: err.crash=\u51FA\u73B0\u4E25\u91CD\u7684\u5185\u90E8\u9519\u8BEF\uFF1A{0}\n\u8BF7\u586B\u5199 Bug \u62A5\u544A\uFF0C\u5E76\u5305\u62EC\u4EE5\u4E0B\u4FE1\u606F\uFF1A\n{1}

While personally I like to see Chinese-style punctuation marks (Ex: `?`) used in Chinese contexts instead of their English-style ones (Ex: `:`), it's only updated on this single line and all the others are still using the English-style.

There should be a general rule on which style we should use throughout all display messages.

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Wed Jan 25 17:47:19 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 17:47:19 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v6]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <X62CFfqZcV_yEfImnVmu3ZoHI5P2xChVA-ky8AgsYBA=.07cc648b-7d60-4188-89d9-c6254d2ce023@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert translated punctuation

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/616b2502..4222df9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Wed Jan 25 17:51:20 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 17:51:20 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v7]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert one more punctuation

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/4222df9a..9a5b45a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116


From weijun at openjdk.org  Wed Jan 25 17:52:21 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 25 Jan 2023 17:52:21 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 113:

> 111: doclet.inheritDocWithinInappropriateTag=\u4E0D\u80FD\u5728\u6B64\u6807\u8BB0\u4E2D\u4F7F\u7528 @inheritDoc
> 112: doclet.inheritDocNoDoc=\u88AB\u8986\u76D6\u7684\u65B9\u6CD5\u4E0D\u8BB0\u5F55\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B {0}
> 113: doclet.throwsInheritDocUnsupported=\u4E0D\u662F\u7531\u65B9\u6CD5\u58F0\u660E\u7684 exception-type \u7C7B\u578B\u53C2\u6570\u4E0D\u652F\u6301 @inheritDoc\uFF1B\u76F4\u63A5\u8BB0\u5F55\u6B64\u7C7B\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B

Should `exception-type` be translated?

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Wed Jan 25 18:03:54 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 18:03:54 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
 <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
Message-ID: <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>

On Wed, 25 Jan 2023 17:49:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert culture attribute
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 113:
> 
>> 111: doclet.inheritDocWithinInappropriateTag=\u4E0D\u80FD\u5728\u6B64\u6807\u8BB0\u4E2D\u4F7F\u7528 @inheritDoc
>> 112: doclet.inheritDocNoDoc=\u88AB\u8986\u76D6\u7684\u65B9\u6CD5\u4E0D\u8BB0\u5F55\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B {0}
>> 113: doclet.throwsInheritDocUnsupported=\u4E0D\u662F\u7531\u65B9\u6CD5\u58F0\u660E\u7684 exception-type \u7C7B\u578B\u53C2\u6570\u4E0D\u652F\u6301 @inheritDoc\uFF1B\u76F4\u63A5\u8BB0\u5F55\u6B64\u7C7B\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B
> 
> Should `exception-type` be translated?

The translation tool didn't seem to translate this. Either because it couldn't or because it somehow missed it. I'm not sure which, but I'm open to replacing this with a translation suggestion you have. Or I can leave it as is.

> src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties line 32:
> 
>> 30: err.bad.constant.pool=\u8BFB\u53D6{0}\u7684\u5E38\u91CF\u6C60\u65F6\u51FA\u9519: {1}
>> 31: err.class.not.found=\u627E\u4E0D\u5230\u7C7B: {0}
>> 32: err.crash=\u51FA\u73B0\u4E25\u91CD\u7684\u5185\u90E8\u9519\u8BEF\uFF1A{0}\n\u8BF7\u586B\u5199 Bug \u62A5\u544A\uFF0C\u5E76\u5305\u62EC\u4EE5\u4E0B\u4FE1\u606F\uFF1A\n{1}
> 
> While personally I like to see Chinese-style punctuation marks (Ex: `?`) used in Chinese contexts instead of their English-style ones (Ex: `:`), it's only updated on this single line and all the others are still using the English-style.
> 
> There should be a general rule on which style we should use throughout all display messages.

Updated the punctuation (colons and comma) to be more consistent throughout the file.

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From weijun at openjdk.org  Wed Jan 25 18:03:55 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 25 Jan 2023 18:03:55 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
 <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
 <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>
Message-ID: <nN1C5POK0aTeX1s9_NUkBMmYTcQgzEJFQwHs42rn_og=.e1029cac-c82e-423c-a4da-d1c99dd8eec4@github.com>

On Wed, 25 Jan 2023 17:56:15 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 113:
>> 
>>> 111: doclet.inheritDocWithinInappropriateTag=\u4E0D\u80FD\u5728\u6B64\u6807\u8BB0\u4E2D\u4F7F\u7528 @inheritDoc
>>> 112: doclet.inheritDocNoDoc=\u88AB\u8986\u76D6\u7684\u65B9\u6CD5\u4E0D\u8BB0\u5F55\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B {0}
>>> 113: doclet.throwsInheritDocUnsupported=\u4E0D\u662F\u7531\u65B9\u6CD5\u58F0\u660E\u7684 exception-type \u7C7B\u578B\u53C2\u6570\u4E0D\u652F\u6301 @inheritDoc\uFF1B\u76F4\u63A5\u8BB0\u5F55\u6B64\u7C7B\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B
>> 
>> Should `exception-type` be translated?
>
> The translation tool didn't seem to translate this. Either because it couldn't or because it somehow missed it. I'm not sure which, but I'm open to replacing this with a translation suggestion you have. Or I can leave it as is.

I'm not sure either. You can ask a javadoc expert whether this is a proper noun or just plain English. I noticed it's also not translated in the Japanese version but the German version has translated it.

>> src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties line 32:
>> 
>>> 30: err.bad.constant.pool=\u8BFB\u53D6{0}\u7684\u5E38\u91CF\u6C60\u65F6\u51FA\u9519: {1}
>>> 31: err.class.not.found=\u627E\u4E0D\u5230\u7C7B: {0}
>>> 32: err.crash=\u51FA\u73B0\u4E25\u91CD\u7684\u5185\u90E8\u9519\u8BEF\uFF1A{0}\n\u8BF7\u586B\u5199 Bug \u62A5\u544A\uFF0C\u5E76\u5305\u62EC\u4EE5\u4E0B\u4FE1\u606F\uFF1A\n{1}
>> 
>> While personally I like to see Chinese-style punctuation marks (Ex: `?`) used in Chinese contexts instead of their English-style ones (Ex: `:`), it's only updated on this single line and all the others are still using the English-style.
>> 
>> There should be a general rule on which style we should use throughout all display messages.
>
> Updated the punctuation (colons and comma) to be more consistent throughout the file.

Looks good now.

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From jjg at openjdk.org  Wed Jan 25 18:24:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 25 Jan 2023 18:24:55 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v7]
In-Reply-To: <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com>
Message-ID: <J-ty6TMfR4ldx_S-L65JWYllWC1ZHnF_ongCEJBxtxI=.aca2e3d7-6b87-4bd0-ab84-ca75ee3ce007@github.com>

On Wed, 25 Jan 2023 17:51:20 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert one more punctuation

I don't see anything absurdly wrong in the jdk.compiler files.

-------------

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116


From prr at openjdk.org  Wed Jan 25 18:33:48 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Jan 2023 18:33:48 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v4]
In-Reply-To: <V_RDZRd3lBHSD6XCLj_TM4-wxZGXZw0y7R7QPneYNuY=.d2722225-fae2-47d1-8545-52dee5949d3b@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
 <V_RDZRd3lBHSD6XCLj_TM4-wxZGXZw0y7R7QPneYNuY=.d2722225-fae2-47d1-8545-52dee5949d3b@github.com>
Message-ID: <jkokZCWaHphpzrbg5L6MWucJMhhlDR_Wl4Aohrrw6TY=.08257ff0-d3fb-4197-bbdb-ff4fa05f7507@github.com>

On Wed, 28 Dec 2022 00:10:53 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8296661)
>> 
>> This is tracked in JBS as 
>> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.openjdk.java.net/browse/JDK-8296661)
>> 
>> I suspect a typo in the documentation comments.
>> 
>> Designed from : [ScientificWare JDK-8296661 : Typo Found In CSSParser.java](https://github.com/scientificware/jdk/issues/18)
>
> ScientificWare has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update Copyright.
>    
>    Change date.
>  - Suggested improvements.
>    
>    - Add missing {@code} tags and update <code> tag with {@code} tag.
>    - Add a paragraph to improve readability

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10975


From duke at openjdk.org  Wed Jan 25 18:43:19 2023
From: duke at openjdk.org (ScientificWare)
Date: Wed, 25 Jan 2023 18:43:19 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v5]
In-Reply-To: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
Message-ID: <KbKZO5WTaW2LBFDRc7ovaXkH3H8TWzKeB4J-0COFcGU=.e13dd7c0-dc4d-4a24-ad28-22975ac34e43@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8296661)
> 
> This is tracked in JBS as 
> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.openjdk.java.net/browse/JDK-8296661)
> 
> I suspect a typo in the documentation comments.
> 
> Designed from : [ScientificWare JDK-8296661 : Typo Found In CSSParser.java](https://github.com/scientificware/jdk/issues/18)

ScientificWare has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year
  
  The year in the copyright headers should be updated to 2023

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10975/files
  - new: https://git.openjdk.org/jdk/pull/10975/files/3a6eac4c..d11d7151

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10975&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10975&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10975.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10975/head:pull/10975

PR: https://git.openjdk.org/jdk/pull/10975


From prr at openjdk.org  Wed Jan 25 18:43:19 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Jan 2023 18:43:19 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v5]
In-Reply-To: <XQc1zO2_1zdGa9qZ7uI0V6EzSwf4CWw7hl2B4-d8Enc=.c2a9f7e8-03f8-4b02-b823-6385da2968b0@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
 <zbvDGc4EHbOQfvq8srOEeTwlyfraCuDbRYN0jXDo7RE=.dfa036b5-bebe-4d7c-af1a-ab8328184328@github.com>
 <XQc1zO2_1zdGa9qZ7uI0V6EzSwf4CWw7hl2B4-d8Enc=.c2a9f7e8-03f8-4b02-b823-6385da2968b0@github.com>
Message-ID: <aX2zebHRFf_FNz1duUg5HUK8ktK8F4qd_udxsj2SztY=.36b2b7c7-bc90-45b4-9ca4-ab0e546df6f6@github.com>

On Mon, 12 Dec 2022 13:06:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Looks good to me.
>> 
>> In the description above: ??invoked one per property??, it shoud be ?once?.
>> 
>> I think there's room for improvement. However, this is an internal-only class.
>
>> I think there's room for improvement. However, this is an internal-only class.
> 
> This is what I have in mind. The list of callbacks is inconsistent in how the method and conditions when it's called are listed. One of the list items has no ending punctuation. Some portions of text should use `<code>` or `{@code}`, or even [`<samp>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/samp).
> 
> I think `<p>` should be added before this sentence, _?If an error results in parsing, a RuntimeException will be thrown.?_ The sentence itself requires re-writing: ?If parsing results in an error??
> 
> Both `RuntimeException` and `toLowerCase` below should be in `{@code}`.
> 
> The usage of `<code>` could be updated to `{@code}` which is the recommended way.
> 
> What do you think?

> I think a Reviewer needs to re-review before it asks for sponsoring. @aivanov-jdk: re-approve changes?

No .. I think that the person who owns the PR needs to re-do the /integrate and that is what will make the sponsor label re-appear.

-------------

PR: https://git.openjdk.org/jdk/pull/10975


From prr at openjdk.org  Wed Jan 25 18:44:49 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Jan 2023 18:44:49 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v17]
In-Reply-To: <hF3_a7jZr5PrfWlGeu3r8585eaCKP1fLSNN0xhOGpzQ=.62524ef2-4726-4b87-bde8-3181bd8d70d3@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <hF3_a7jZr5PrfWlGeu3r8585eaCKP1fLSNN0xhOGpzQ=.62524ef2-4726-4b87-bde8-3181bd8d70d3@github.com>
Message-ID: <3JQGjb1CawgL8ov_zMsEB2Q6DcgQa2kchkjec85mAZM=.7d6eea32-0f50-43f7-88c3-b28572c47d6a@github.com>

On Wed, 25 Jan 2023 13:22:31 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 incrementally with one additional commit since the last revision:
> 
>   Skip tests if required font is absent

src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java line 92:

> 90: 
> 91:     private static int unicodeToUnits(int unicode, int dstOffset, char[] dst) {
> 92:         if (unicode >= 0x10000) {

Why can't you use public API that already does this ? [ ](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Character.html#toChars(int,char%5B%5D,int)) ?

src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java line 104:

> 102: 
> 103:     public int charToVariationGlyph(int unicode, int variationSelector) {
> 104:         if (variationSelector == 0) return charToGlyph(unicode);

We always use braces around the body, even for one line.

-------------

PR: https://git.openjdk.org/jdk/pull/4798


From weijun at openjdk.org  Wed Jan 25 18:58:57 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 25 Jan 2023 18:58:57 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v7]
In-Reply-To: <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com>
Message-ID: <v7uEXriAXWk-hzpE3-k1fiiPitnlhkkN1gkTMXFQ9Yg=.951f83bf-79b3-4270-981f-140e84b68fb9@github.com>

On Wed, 25 Jan 2023 17:51:20 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert one more punctuation

zh_cn translations look fine. Thanks.

-------------

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116


From angorya at openjdk.org  Wed Jan 25 19:00:48 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 25 Jan 2023 19:00:48 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v5]
In-Reply-To: <KbKZO5WTaW2LBFDRc7ovaXkH3H8TWzKeB4J-0COFcGU=.e13dd7c0-dc4d-4a24-ad28-22975ac34e43@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
 <KbKZO5WTaW2LBFDRc7ovaXkH3H8TWzKeB4J-0COFcGU=.e13dd7c0-dc4d-4a24-ad28-22975ac34e43@github.com>
Message-ID: <xGwZ1L42q9G8uQMVsQubeZS9V7Ta_OgfXpr9XQaMsTU=.c7569111-efe5-4f3f-a6fb-cd30a30f5190@github.com>

On Wed, 25 Jan 2023 18:43:19 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8296661)
>> 
>> This is tracked in JBS as 
>> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.openjdk.java.net/browse/JDK-8296661)
>> 
>> I suspect a typo in the documentation comments.
>> 
>> Designed from : [ScientificWare JDK-8296661 : Typo Found In CSSParser.java](https://github.com/scientificware/jdk/issues/18)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year
>   
>   The year in the copyright headers should be updated to 2023

excellent

-------------

Marked as reviewed by angorya (no project role).

PR: https://git.openjdk.org/jdk/pull/10975


From pminborg at openjdk.org  Wed Jan 25 19:05:29 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 25 Jan 2023 19:05:29 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input | Output)Impl
 classes
Message-ID: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>

This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.

-------------

Commit messages:
 - Remove comments
 - Add little endian performance improvements
 - Use jdk.internal.util.ByteArray for pack/unpack

Changes: https://git.openjdk.org/jdk/pull/12204/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12204&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300235
  Stats: 279 lines in 5 files changed: 8 ins; 144 del; 127 mod
  Patch: https://git.openjdk.org/jdk/pull/12204.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12204/head:pull/12204

PR: https://git.openjdk.org/jdk/pull/12204


From pminborg at openjdk.org  Wed Jan 25 19:05:30 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 25 Jan 2023 19:05:30 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input | Output)Impl
 classes
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <buJ4qTEY6IvOIRZS0UXGg9dJenhMRnyP805OddlzhfM=.806d1e13-c651-42b2-b886-396382fe7253@github.com>

On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.

src/java.base/share/classes/module-info.java line 275:

> 273:     exports jdk.internal.util.random to
> 274:         jdk.random;
> 275:     exports jdk.internal.util to

Added coupling I am afraid.

-------------

PR: https://git.openjdk.org/jdk/pull/12204


From aivanov at openjdk.org  Wed Jan 25 19:18:46 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Jan 2023 19:18:46 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v5]
In-Reply-To: <KbKZO5WTaW2LBFDRc7ovaXkH3H8TWzKeB4J-0COFcGU=.e13dd7c0-dc4d-4a24-ad28-22975ac34e43@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
 <KbKZO5WTaW2LBFDRc7ovaXkH3H8TWzKeB4J-0COFcGU=.e13dd7c0-dc4d-4a24-ad28-22975ac34e43@github.com>
Message-ID: <mFgj-YMTRwrU0T2p1neFBurLqs9g5OZ7Y9sY65oAA0U=.c107c1ed-abff-4e0e-98ef-36326217f358@github.com>

On Wed, 25 Jan 2023 18:43:19 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8296661)
>> 
>> This is tracked in JBS as 
>> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.openjdk.java.net/browse/JDK-8296661)
>> 
>> I suspect a typo in the documentation comments.
>> 
>> Designed from : [ScientificWare JDK-8296661 : Typo Found In CSSParser.java](https://github.com/scientificware/jdk/issues/18)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year
>   
>   The year in the copyright headers should be updated to 2023

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10975


From duke at openjdk.org  Wed Jan 25 19:23:53 2023
From: duke at openjdk.org (ScientificWare)
Date: Wed, 25 Jan 2023 19:23:53 GMT
Subject: Integrated: JDK-8296661 : Typo Found In CSSParser.java
In-Reply-To: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
Message-ID: <2BW9r2udFIXtX1n7sGp-woR4k7cmKXltEOUTsXaFWns=.445c1864-01d5-434b-9078-22e4f8f9a30a@github.com>

On Fri, 4 Nov 2022 01:56:05 GMT, ScientificWare <duke at openjdk.org> wrote:

> This is referenced in Java Bug Database as
> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8296661)
> 
> This is tracked in JBS as 
> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.openjdk.java.net/browse/JDK-8296661)
> 
> I suspect a typo in the documentation comments.
> 
> Designed from : [ScientificWare JDK-8296661 : Typo Found In CSSParser.java](https://github.com/scientificware/jdk/issues/18)

This pull request has now been integrated.

Changeset: 9f0887e2
Author:    ScientificWare <info at scientificware.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f0887e2056c3c535eb5a5df2c945d77d1290ce7
Stats:     22 lines in 1 file changed: 2 ins; 1 del; 19 mod

8296661: Typo Found In CSSParser.java

Reviewed-by: angorya, aivanov, prr

-------------

PR: https://git.openjdk.org/jdk/pull/10975


From aivanov at openjdk.org  Wed Jan 25 19:32:52 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Jan 2023 19:32:52 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v5]
In-Reply-To: <XQc1zO2_1zdGa9qZ7uI0V6EzSwf4CWw7hl2B4-d8Enc=.c2a9f7e8-03f8-4b02-b823-6385da2968b0@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
 <zbvDGc4EHbOQfvq8srOEeTwlyfraCuDbRYN0jXDo7RE=.dfa036b5-bebe-4d7c-af1a-ab8328184328@github.com>
 <XQc1zO2_1zdGa9qZ7uI0V6EzSwf4CWw7hl2B4-d8Enc=.c2a9f7e8-03f8-4b02-b823-6385da2968b0@github.com>
Message-ID: <Au2e_Gkk8tdryeZ3_abyELHKkjdm5TDvBCCkadYhpdQ=.b5c5e876-7a30-45d7-957b-dbe72f5ef71d@github.com>

On Mon, 12 Dec 2022 13:06:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Looks good to me.
>> 
>> In the description above: ??invoked one per property??, it shoud be ?once?.
>> 
>> I think there's room for improvement. However, this is an internal-only class.
>
>> I think there's room for improvement. However, this is an internal-only class.
> 
> This is what I have in mind. The list of callbacks is inconsistent in how the method and conditions when it's called are listed. One of the list items has no ending punctuation. Some portions of text should use `<code>` or `{@code}`, or even [`<samp>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/samp).
> 
> I think `<p>` should be added before this sentence, _?If an error results in parsing, a RuntimeException will be thrown.?_ The sentence itself requires re-writing: ?If parsing results in an error??
> 
> Both `RuntimeException` and `toLowerCase` below should be in `{@code}`.
> 
> The usage of `<code>` could be updated to `{@code}` which is the recommended way.
> 
> What do you think?

> @aivanov-jdk Done.

Sorry, @scientificware, I missed the update.

After making changes, you have to issue `integrate` command again.

In fact, I didn't mean to include [the changes I suggested](https://github.com/openjdk/jdk/pull/10975#issuecomment-1346460131) in this PR.

I still think there's room for improvement, however, it's not visible publicly. The list is inconsistent:

_?The delegate is notified of the following events:?_ ? one would expect a list of events. Instead, each list item starts differently. If I may suggest, starting each item with a callback method followed by the condition when it's called and additional details will present a more consistent documentation. The introduction sentence before the list may also be updated.

-------------

PR: https://git.openjdk.org/jdk/pull/10975


From prappo at openjdk.org  Wed Jan 25 20:06:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 25 Jan 2023 20:06:53 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <nN1C5POK0aTeX1s9_NUkBMmYTcQgzEJFQwHs42rn_og=.e1029cac-c82e-423c-a4da-d1c99dd8eec4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
 <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
 <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>
 <nN1C5POK0aTeX1s9_NUkBMmYTcQgzEJFQwHs42rn_og=.e1029cac-c82e-423c-a4da-d1c99dd8eec4@github.com>
Message-ID: <HmtuZgI4Gn2cXWC_wVOVAjPD0DdjSnOa4OENGo9ofsU=.aa00f17c-703d-494d-9594-9f6f084be286@github.com>

On Wed, 25 Jan 2023 18:00:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The translation tool didn't seem to translate this. Either because it couldn't or because it somehow missed it. I'm not sure which, but I'm open to replacing this with a translation suggestion you have. Or I can leave it as is.
>
> I'm not sure either. You can ask a javadoc expert whether this is a proper noun or just plain English. I noticed it's also not translated in the Japanese version but the German version has translated it.

It's not a noun. It's an adjective that I had to synthesize for extra clarity and closeness to Java Language Specification (JLS). The English version of that entry is as follows:

    doclet.throwsInheritDocUnsupported=@inheritDoc is not supported for exception-type type parameters \
    that are not declared by a method; document such exception types directly

JLS _8.4.6. Method Throws_ defines BNF which conveniently labels elements, a list of which may appear in the `throws` clause, as `ExceptionType`. To make it more English-like and separate two otherwise consecutive occurrences of "type" in that sentence, I split the words with a hyphen and lower-cased them: exception-type.

@jonathan-gibbons thoughts?

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From duke at openjdk.org  Wed Jan 25 20:26:52 2023
From: duke at openjdk.org (ScientificWare)
Date: Wed, 25 Jan 2023 20:26:52 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v5]
In-Reply-To: <Au2e_Gkk8tdryeZ3_abyELHKkjdm5TDvBCCkadYhpdQ=.b5c5e876-7a30-45d7-957b-dbe72f5ef71d@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
 <zbvDGc4EHbOQfvq8srOEeTwlyfraCuDbRYN0jXDo7RE=.dfa036b5-bebe-4d7c-af1a-ab8328184328@github.com>
 <XQc1zO2_1zdGa9qZ7uI0V6EzSwf4CWw7hl2B4-d8Enc=.c2a9f7e8-03f8-4b02-b823-6385da2968b0@github.com>
 <Au2e_Gkk8tdryeZ3_abyELHKkjdm5TDvBCCkadYhpdQ=.b5c5e876-7a30-45d7-957b-dbe72f5ef71d@github.com>
Message-ID: <fL57L9udkYhFSD6CUgZdJrPPYkSLkP9kX1Xfy9LrEto=.0e59cc0e-9ec4-4683-8f6c-a4e009374427@github.com>

On Wed, 25 Jan 2023 19:29:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> I think there's room for improvement. However, this is an internal-only class.
>> 
>> This is what I have in mind. The list of callbacks is inconsistent in how the method and conditions when it's called are listed. One of the list items has no ending punctuation. Some portions of text should use `<code>` or `{@code}`, or even [`<samp>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/samp).
>> 
>> I think `<p>` should be added before this sentence, _?If an error results in parsing, a RuntimeException will be thrown.?_ The sentence itself requires re-writing: ?If parsing results in an error??
>> 
>> Both `RuntimeException` and `toLowerCase` below should be in `{@code}`.
>> 
>> The usage of `<code>` could be updated to `{@code}` which is the recommended way.
>> 
>> What do you think?
>
>> @aivanov-jdk Done.
> 
> Sorry, @scientificware, I missed the update.
> 
> After making changes, you have to issue `integrate` command again.
> 
> In fact, I didn't mean to include [the changes I suggested](https://github.com/openjdk/jdk/pull/10975#issuecomment-1346460131) in this PR.
> 
> I still think there's room for improvement, however, it's not visible publicly. The list is inconsistent:
> 
> _?The delegate is notified of the following events:?_ ? one would expect a list of events. Instead, each list item starts differently. If I may suggest, starting each item with a callback method followed by the condition when it's called and additional details will present a more consistent documentation. The introduction sentence before the list may also be updated.

@aivanov-jdk Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10975


From aivanov at openjdk.org  Wed Jan 25 20:28:48 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Jan 2023 20:28:48 GMT
Subject: RFR: 8300549: JFileChooser Approve button tooltip is null in Aqua
 L&F in CUSTOM_DIALOG mode
In-Reply-To: <IPLzXe7hJxn5KukI-eFxqO1CJNDO_g70pUBOlwLewIA=.68dd5394-541a-4096-8dce-99f2b6156b0d@github.com>
References: <IPLzXe7hJxn5KukI-eFxqO1CJNDO_g70pUBOlwLewIA=.68dd5394-541a-4096-8dce-99f2b6156b0d@github.com>
Message-ID: <RDnuNKckltw2aRuwLg94LV-sXNyPC3bG2JSrI81XKBM=.2c7a25e5-0729-46da-a2ec-8093dc32be60@github.com>

On Wed, 25 Jan 2023 14:24:41 GMT, Tejesh R <tr at openjdk.org> wrote:

> _JFilechooser_ returns _null_ for Approve button tool tip in `CUSTOM_DIALOG` mode (`getToolTipText()`). The fallback text has been set to "Choose" text. Observation found in validating the test of PR - #11901.

Changes requested by aivanov (Reviewer).

src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java line 329:

> 327:         newFolderButtonText = getString("FileChooser.newFolderButtonText", "New");
> 328:         newFolderTitleText = getString("FileChooser.newFolderTitleText", "New Folder");
> 329:         chooseButtonToolTipText = getString("FileChooser.chooseButtonToolTipText", "Choose");

I suggest having `chooseButtonText` and `chooseButtonToolTipText` next to each other.

The tooltip should be `"Choose selected file"` to be consistent with tooltips for Open and Save buttons.

I also suggest adding `FileChooser.chooseButtonToolTipText` property into `aqua.properties` so that it can be properly localised.

src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java line 2059:

> 2057:         // No fallback
> 2058:         String getApproveButtonToolTipText(final JFileChooser fc) {
> 2059:             return getApproveButtonToolTipText(fc,chooseButtonToolTipText);

Suggestion:

            return getApproveButtonToolTipText(fc, chooseButtonToolTipText);

There was a space after the comma as it should be, let's preserve it there.

-------------

PR: https://git.openjdk.org/jdk/pull/12198


From serb at openjdk.org  Wed Jan 25 20:59:07 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 25 Jan 2023 20:59:07 GMT
Subject: RFR: 8300405: Screen capture for test
 JFileChooserSetLocationTest.java, failure case [v2]
In-Reply-To: <HHcSH53itQETCl4xJBXi55BPZos9GcKAM4RXvhtOlnE=.01446a81-dca2-4f2f-b05e-1ef91d0cb077@github.com>
References: <H9i4szvE-s7cWX1cu8bkx6nLa3yvB44bftLmYbbfhvM=.a5ae761a-cfe3-4a71-80b2-88bbb6ae7858@github.com>
 <HHcSH53itQETCl4xJBXi55BPZos9GcKAM4RXvhtOlnE=.01446a81-dca2-4f2f-b05e-1ef91d0cb077@github.com>
Message-ID: <hPTne8jXtJDihTVCpulJOCve_16Ce5YFezYVr2laF9A=.681b0859-6c05-4d93-9893-d60860fbb09b@github.com>

On Mon, 23 Jan 2023 05:19:05 GMT, Tejesh R <tr at openjdk.org> wrote:

>> This is a diagnostic update related to [JDK-8295804](https://bugs.openjdk.org/browse/JDK-8295804). The issue was not reproducible and was showing up in particular machines (Where the machines are down now). So adding a screen capture to `BufferedImage` in case of failure so that it will help in analysis when the issue comes up in future.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated screen capture bounds

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12060


From aivanov at openjdk.org  Wed Jan 25 21:00:57 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Jan 2023 21:00:57 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v2]
In-Reply-To: <_F66GasxdremocPjHV9uOyJLZQy83LD3KZ7FJFgtPU4=.f8e837d5-8ebc-4f10-8849-47334cb213d9@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
 <_F66GasxdremocPjHV9uOyJLZQy83LD3KZ7FJFgtPU4=.f8e837d5-8ebc-4f10-8849-47334cb213d9@github.com>
Message-ID: <_ghd81JZBoqpumCfJYCRJBx2If1fVThQ3Djv7l4NSjg=.e73fdc48-6100-4a73-8cb2-8fe2df6c0d40@github.com>

On Tue, 24 Jan 2023 23:23:32 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Fixed test bug where mouse location was being calculated before robot mouseMove operation was complete
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - re-test
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8292588/MultiScreenLocationTest
>  - added robot wait to prevent mouse position from being calculated before robot finishes mouseMove

The suggested change does fix the mouse pointer issue.

However, the test still fails for me:

Exception in thread "main" java.lang.RuntimeException: Robot.getPixelColor test failed on Screen #1!
	at MultiScreenLocationTest.main(MultiScreenLocationTest.java:98)


Is it possible to add diagnostic information?

If `moveMove` fails, one may want to see what the coordinates are, what the expected coordinates are and what the bounds of the current screen are.

If `getPixelColor` fails, what is the color of the pixel and what is the expected color?

These changes will be helpful for you while you debugging and updating the test as well as for anyone who has to deal with the test later.

-------------

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10363


From serb at openjdk.org  Wed Jan 25 21:02:00 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 25 Jan 2023 21:02:00 GMT
Subject: RFR: 8297454: javax/swing/JComponent/7154030/bug7154030.java
 failed with "Exception: Failed to show opaque button"
In-Reply-To: <nIuP21ewUd0nALclypyH1ULkFk_cAq5q34LIxmCloUs=.a7326479-4586-4a2f-bb38-15d572a4512d@github.com>
References: <nIuP21ewUd0nALclypyH1ULkFk_cAq5q34LIxmCloUs=.a7326479-4586-4a2f-bb38-15d572a4512d@github.com>
Message-ID: <clLIZcxpLzA_QaHIf9l761Tfh6XaoYdNl4v9XYeQNj0=.1736c0ed-708a-4200-be81-db50d3d03491@github.com>

On Wed, 25 Jan 2023 06:41:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test intermittently failed in CI macos system owing to robot screencapture failing to compare the images.
> Seems like from artifacts, that composite image created by robot contains mouse cursor, which when compared are not giving exact pixel color. This has occurred in the past also for some tests for which we have made the mouseMove to move mouse cursor outside the area being captured for pixel comparison.
> Similar fix is done whereby mouse is moved to outside the captured area. Several iterations in CI are ok.

@prrace I remember we report that cursor issue to the Apple, did we get any feedback?

-------------

PR: https://git.openjdk.org/jdk/pull/12179


From serb at openjdk.org  Wed Jan 25 21:02:38 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 25 Jan 2023 21:02:38 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
In-Reply-To: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
Message-ID: <qQLH7ycgtZKf0hfheHKwJaAqYXlwV9zI9xaVG0QgG2k=.75b7f285-74dc-4777-98da-81948eb4cde7@github.com>

On Wed, 25 Jan 2023 06:45:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
> Fix is made to reset the font if it is set by L&F.

test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 36:

> 34: public class JFileChooserFontReset {
> 35:     public static void main(String args[]) throws Exception {
> 36:         UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");

Is it possible to test all installed L&F on the system?

-------------

PR: https://git.openjdk.org/jdk/pull/12180


From phh at openjdk.org  Wed Jan 25 21:13:20 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 25 Jan 2023 21:13:20 GMT
Subject: RFR: 8238170: BeanContextSupport remove and propertyChange can
 deadlock
In-Reply-To: <qS_fxqeO2UlPD7Tqkc7Iqe4vYVBn0Az4B328s7uVw_k=.5560c0f8-33e0-4fb5-bd25-08220ff8a8e3@github.com>
References: <qS_fxqeO2UlPD7Tqkc7Iqe4vYVBn0Az4B328s7uVw_k=.5560c0f8-33e0-4fb5-bd25-08220ff8a8e3@github.com>
Message-ID: <dof9mAdFyie4qF5NpbUnfNvNVUABD5W_e1tF49xQ4tM=.28b55524-4a5e-4289-a490-c01099537f19@github.com>

On Tue, 24 Jan 2023 03:15:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Two methods in the BeanContextSupport class use two locks in a different order, which can cause a deadlock. 
> 
> Here is the first order: (1) first acquire BeanContext.globalHierarchyLock and then children:
> 
>     enter public method remove(Object) at line 484
>     call remove(Object, boolean) at line 485
>     acquire synchronization on BeanContext.globalHierarchyLock at line 502
>     acquire synchronization on children at line 534
> 
> Here is the second order: (2) first acquire children and then BeanContext.globalHierarchyLock:
> 
>     enter public method propertyChange() at line 1110
>     acquire synchronization on children at line 1114
>     call remove(Object, boolean) at line 1121
>     acquire synchronization on BeanContext.globalHierarchyLock at line 502 
> 
> The fix added the "BeanContext.globalHierarchyLock" before the usage of the "children" lock in the propertyChange method.

Lgtm.

Pre-submit 32-bit linux build errors appear unrelated.

-------------

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12158


From dnguyen at openjdk.org  Wed Jan 25 22:02:45 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 22:02:45 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v8]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <AB1V6yMmmoy0zYaY-mNjq4QPc8MTvQO4t8BCsUs0EFA=.40f66568-b479-45c6-8126-1e0d8b375bf9@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Update German translation

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/9a5b45a2..35829a25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116


From aivanov at openjdk.org  Wed Jan 25 22:16:29 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Jan 2023 22:16:29 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v23]
In-Reply-To: <muHGFzojNURqpUi7mtVX8c48gXietTq4Jha_mEEET7M=.942543f9-d3ba-47be-b3cc-3be1326feb42@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
 <muHGFzojNURqpUi7mtVX8c48gXietTq4Jha_mEEET7M=.942543f9-d3ba-47be-b3cc-3be1326feb42@github.com>
Message-ID: <R9GPOwfz4P_7tN1eqg-1vViRTDti-A53lx_Hf9sOIjY=.4bd5da4e-997e-4986-be2d-876e6ba5246b@github.com>

On Sat, 21 Jan 2023 18:15:43 GMT, ScientificWare <duke at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>    Moves jtreg tags to the class declaration
>>   
>>   Comment with tags isn't collapsed when viewed in an IDE if it's placed before the class declaration.
>
> Still waiting a review.

@scientificware could you put your suggested text into the code change? I mean incorporate into the PR itself.

Is it necessary to have the _long_ sample code?

> @aivanov-jdk Can we dissociate the release of the code from the stringToColor specification update ? I'm not ready with [rgb implementation](https://bugs.openjdk.org/browse/JDK-8294090) as described in this specifications.

If the other part isn't ready yet, let's skip it for now. Once ready, you'll update the javadoc accordingly.

-------------

PR: https://git.openjdk.org/jdk/pull/9825


From dnguyen at openjdk.org  Wed Jan 25 22:19:34 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 22:19:34 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <TsM2mpquBl2wvitATox3_QNHuSrQLhZN0MFsaaINyHg=.41bef814-3f17-402b-be0d-a1797114bbee@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <TsM2mpquBl2wvitATox3_QNHuSrQLhZN0MFsaaINyHg=.41bef814-3f17-402b-be0d-a1797114bbee@github.com>
Message-ID: <XTYcX2V5gNfgnD4UmjFcya6DL2xEA1xmZha3_37alEU=.ab625ad0-c40c-48e1-b759-337ca44d2b98@github.com>

On Wed, 25 Jan 2023 08:17:26 GMT, danielpeintner <duke at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change German help of jar command
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 111:
> 
>> 109: main.help.opt.main.update=\  -u, --update               Ein vorhandenes JAR-Archiv aktualisieren
>> 110: main.help.opt.main.extract=\  -x, --extract              Benannte (oder alle) Dateien aus dem Archiv extrahieren
>> 111: main.help.opt.main.describe-module=\  -d, --describe-module      Gibt den Moduldeskriptor oder automatischen Modulnamen aus
> 
> Just because I stumbled over this commit. I think the line should be translated as follows:
> 
> `Gibt die Modulbeschreibung oder den automatischen Modulnamen aus`

Resolved

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From prr at openjdk.org  Wed Jan 25 22:29:01 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Jan 2023 22:29:01 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v17]
In-Reply-To: <hF3_a7jZr5PrfWlGeu3r8585eaCKP1fLSNN0xhOGpzQ=.62524ef2-4726-4b87-bde8-3181bd8d70d3@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <hF3_a7jZr5PrfWlGeu3r8585eaCKP1fLSNN0xhOGpzQ=.62524ef2-4726-4b87-bde8-3181bd8d70d3@github.com>
Message-ID: <Npyurj464yUzAL4oRQ4dUpIUX5ch_pHPZQMBKI0jBXg=.b02c5ceb-fb06-4a2a-aa42-fdebddd106ea@github.com>

On Wed, 25 Jan 2023 13:22:31 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 incrementally with one additional commit since the last revision:
> 
>   Skip tests if required font is absent

src/java.desktop/share/classes/sun/font/CMap.java line 1173:

> 1171: 
> 1172:     char getVariationGlyph(int charCode, int variationSelector) {
> 1173:         if (variationSelector == 0) return getGlyph(charCode);

another place for braces

src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java line 142:

> 140:     @Override
> 141:     public int charToVariationGlyph(int unicode, int variationSelector) {
> 142:         if (variationSelector == 0) return charToGlyph(unicode);

more missing braces. I'm going to stop pointing these out, please just find and fix any others

src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 52:

> 50: // to build on older Linuxes, this is not a big problem,
> 51: // as Linux uses bitmap emoji anyway.
> 52: #if defined(_WIN32) || defined(__APPLE__)

Do we really have to disable coloured outlines because of what's available at build time ? Why can't we dynamically locate all the needed symbols at runtime ?

-------------

PR: https://git.openjdk.org/jdk/pull/4798


From prr at openjdk.org  Wed Jan 25 22:29:03 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Jan 2023 22:29:03 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <h_Vs9kfODi5IryiAFTciwLM0ffqZ1qbDLi8DRQLgzVM=.e791cedd-e9e7-42d0-bf13-e84ae575ba99@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
 <bObcfMVaxCToOJcBgQ3TCPodNKgod65b2HohMsuNk9s=.bae92483-f3a2-4adf-bd71-3056ab59335e@github.com>
 <MSv3RbxPjfHQlAq4zu1uzs0Dc83rn5YDBuEXqI5uem4=.aef6fad5-3efd-4c72-9c2a-f97fe3aadabf@github.com>
 <R4t6-20S1hd8H71xGYByLoVWvmyqACdLB_2DUkbYhJw=.02c42d5c-e427-40d7-b1eb-2431dc349a85@github.com>
 <uSiS9dILM4zD8K1BZXguxHIMuK3DfEBqv_Yup3aVRIw=.ff39717c-2d8b-4e95-a8dd-43546cbd39c2@github.com>
 <h_Vs9kfODi5IryiAFTciwLM0ffqZ1qbDLi8DRQLgzVM=.e791cedd-e9e7-42d0-bf13-e84ae575ba99@github.com>
Message-ID: <EMH95VHsnMqtw745hPSmuUoF7FUxdt3mZiZCBeV_Efs=.22e8f069-9adb-4558-b532-eb4c86fa123a@github.com>

On Mon, 19 Dec 2022 23:41:40 GMT, Phil Race <prr at openjdk.org> wrote:

>> Thank you.
>
> Pushed under bug https://bugs.openjdk.org/browse/JDK-8298974

You need to remove this from your change and resync to get the JDK's copy

-------------

PR: https://git.openjdk.org/jdk/pull/4798


From jjg at openjdk.org  Wed Jan 25 22:41:34 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 25 Jan 2023 22:41:34 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <HmtuZgI4Gn2cXWC_wVOVAjPD0DdjSnOa4OENGo9ofsU=.aa00f17c-703d-494d-9594-9f6f084be286@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
 <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
 <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>
 <nN1C5POK0aTeX1s9_NUkBMmYTcQgzEJFQwHs42rn_og=.e1029cac-c82e-423c-a4da-d1c99dd8eec4@github.com>
 <HmtuZgI4Gn2cXWC_wVOVAjPD0DdjSnOa4OENGo9ofsU=.aa00f17c-703d-494d-9594-9f6f084be286@github.com>
Message-ID: <SguhDj7riiU8cDGLybLwdwjSQbHGgLUsDhGBVeHk5L4=.df78d310-21cb-422c-b588-6e3b0a060709@github.com>

On Wed, 25 Jan 2023 20:03:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I'm not sure either. You can ask a javadoc expert whether this is a proper noun or just plain English. I noticed it's also not translated in the Japanese version but the German version has translated it.
>
> It's not a noun. It's an adjective that I had to synthesize for extra clarity and closeness to Java Language Specification (JLS). The English version of that entry is as follows:
> 
>     doclet.throwsInheritDocUnsupported=@inheritDoc is not supported for exception-type type parameters \
>     that are not declared by a method; document such exception types directly
> 
> JLS _8.4.6. Method Throws_ defines BNF which conveniently labels elements, a list of which may appear in the `throws` clause, as `ExceptionType`. To make it more English-like and separate two otherwise consecutive occurrences of "type" in that sentence, I split the words with a hyphen and lower-cased them: exception-type.
> 
> @jonathan-gibbons thoughts?

While the text is technically correct, it may not be as clear as it could be to all folk that will read this message for whom English is not their primary language.

I would suggest translating the phrase as if it were something like

@inheritDoc is not supported for type parameters that are exception types and not declared by a method


and secondarily, changing the English resource to something like that as well.

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Wed Jan 25 22:56:59 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 22:56:59 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v9]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <VeAjGWpLXL0FNT25iwGS5NsmzRe4Navl_LNepqMKSNg=.23960b10-c6cb-4893-93f8-cbc2f8a8297c@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Replace exception-type

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/35829a25..53a86ef2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116


From dnguyen at openjdk.org  Wed Jan 25 22:56:59 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 22:56:59 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <SguhDj7riiU8cDGLybLwdwjSQbHGgLUsDhGBVeHk5L4=.df78d310-21cb-422c-b588-6e3b0a060709@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
 <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
 <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>
 <nN1C5POK0aTeX1s9_NUkBMmYTcQgzEJFQwHs42rn_og=.e1029cac-c82e-423c-a4da-d1c99dd8eec4@github.com>
 <HmtuZgI4Gn2cXWC_wVOVAjPD0DdjSnOa4OENGo9ofsU=.aa00f17c-703d-494d-9594-9f6f084be286@github.com>
 <SguhDj7riiU8cDGLybLwdwjSQbHGgLUsDhGBVeHk5L4=.df78d310-21cb-422c-b588-6e3b0a060709@github.com>
Message-ID: <qWC3dfg9l9N5Om85X97AxhnYgQJCQEYtxknwqG0MeY0=.417d15ec-c2d8-424e-97dc-867c4f753e9a@github.com>

On Wed, 25 Jan 2023 22:38:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> It's not a noun. It's an adjective that I had to synthesize for extra clarity and closeness to Java Language Specification (JLS). The English version of that entry is as follows:
>> 
>>     doclet.throwsInheritDocUnsupported=@inheritDoc is not supported for exception-type type parameters \
>>     that are not declared by a method; document such exception types directly
>> 
>> JLS _8.4.6. Method Throws_ defines BNF which conveniently labels elements, a list of which may appear in the `throws` clause, as `ExceptionType`. To make it more English-like and separate two otherwise consecutive occurrences of "type" in that sentence, I split the words with a hyphen and lower-cased them: exception-type.
>> 
>> @jonathan-gibbons thoughts?
>
> While the text is technically correct, it may not be as clear as it could be to all folk that will read this message for whom English is not their primary language.
> 
> I would suggest translating the phrase as if it were something like
> 
> @inheritDoc is not supported for type parameters that are exception types and not declared by a method
> 
> 
> and secondarily, changing the English resource to something like that as well.

Updated this line with `exception-type` translated. Hopefully this will be addressed in future drops with changes to the translation tool after some bug fixes.

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From bpb at openjdk.org  Wed Jan 25 22:57:16 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 25 Jan 2023 22:57:16 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input | Output)Impl
 classes
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <ESkA2xuv6_kG96jZQg0s_KZjmC-Q1ATIQMfIJaENzCY=.8d6d1457-928c-4a8e-9029-db5911f429e7@github.com>

On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

Looks good overall. Did you measure any performance changes in the image streams? (Note that this PR and its corresponding issue are missing "Stream" in the title.)

-------------

PR: https://git.openjdk.org/jdk/pull/12204


From dnguyen at openjdk.org  Wed Jan 25 23:18:26 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 23:18:26 GMT
Subject: Withdrawn: 8300269: The selected item in an editable JComboBox with
 titled border is not visible in Aqua LAF
In-Reply-To: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>
References: <QgVRgpq2IbZ_6mlGevns_XcvH4XE2Sylc30imR7Ltnc=.74da7162-9df1-4a42-a1d3-c3ec70dc0b8a@github.com>
Message-ID: <JQwLTZrGL-j-4ngrrbc3QJp7sihhQgmVWtzrf_kDNIk=.c5d3f226-1697-4e1e-b463-8f7bbf2d475a@github.com>

On Thu, 19 Jan 2023 01:12:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> The fixed height causes the titled border insets to reserve a majority of the height available for the component. This fixed height is meant for the default AquaComboBox usage, so the old default height is more applicable when a border, such as TitledBorder, is set on an Aqua Editable ComboBox.
> 
> A conditional to check for a border is added since this is the default for an AquaComboBox using AquaBorder in AquaComboBoxUI's rectangleForCurrentValue() step. A check for any border rather than an instance of a TitledBorder is used because this issue causes changes in other borders as well (I found it for LineBorder for example). 
> 
> The editable JComboBox is visible with a LineBorder, but the coordinates of the comboBox are aligned with the top of the arrowButton instead of the bottom (which was the case before the previous fix). So, the method now defaults to the behavior before the fix for any editable comboBox pre-fix if a different border is set.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12087


From serb at openjdk.org  Wed Jan 25 23:55:16 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 25 Jan 2023 23:55:16 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url)
In-Reply-To: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
Message-ID: <6ZQu53O6bHzgWHM0YKZOUgGws32Or-VmTu1vIIHjaps=.15fa2e3e-bafe-4ee3-b824-2e801df9364b@github.com>

On Tue, 24 Jan 2023 23:29:58 GMT, Phil Race <prr at openjdk.org> wrote:

> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
> So deprecating - for removal - and adding warnings now in the docs is appropriate.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From serb at openjdk.org  Thu Jan 26 00:04:18 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 26 Jan 2023 00:04:18 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: <Cu6L9mgFGU0gnjX4dZjg-LrVwqeLsp9FBZaS2FvXVpA=.b722e4bf-7ba5-4998-9d2e-5a2536755d05@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.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12181


From achung at openjdk.org  Thu Jan 26 00:19:20 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 26 Jan 2023 00:19:20 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v2]
In-Reply-To: <_ghd81JZBoqpumCfJYCRJBx2If1fVThQ3Djv7l4NSjg=.e73fdc48-6100-4a73-8cb2-8fe2df6c0d40@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
 <_F66GasxdremocPjHV9uOyJLZQy83LD3KZ7FJFgtPU4=.f8e837d5-8ebc-4f10-8849-47334cb213d9@github.com>
 <_ghd81JZBoqpumCfJYCRJBx2If1fVThQ3Djv7l4NSjg=.e73fdc48-6100-4a73-8cb2-8fe2df6c0d40@github.com>
Message-ID: <-S1P8rII2nr7IZWPLVrIRSbmcTdBujDX_5eto_GUUxM=.a2b606ae-8dd9-4942-8f92-b536a8154ff6@github.com>

On Wed, 25 Jan 2023 20:58:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The suggested change does fix the mouse pointer issue.
> 
> However, the test still fails for me:
> 
> ```
> Exception in thread "main" java.lang.RuntimeException: Robot.getPixelColor test failed on Screen #1!
> 	at MultiScreenLocationTest.main(MultiScreenLocationTest.java:98)
> ```
> 
> Is it possible to add diagnostic information?
> 
> If `moveMove` fails, one may want to see what the coordinates are, what the expected coordinates are and what the bounds of the current screen are.
> 
> If `getPixelColor` fails, what is the color of the pixel and what is the expected color?
> 
> These changes will be helpful for you while you debugging and updating the test as well as for anyone who has to deal with the test later.

Sure, I can add that. What fixed the issue for me for the latter two issues was setting the color profile of the second monitor in the system preferences. Under Display > Color I set Display Profile to be sRGB IEC61966-2.1 on the second monitor and the test then passes.

-------------

PR: https://git.openjdk.org/jdk/pull/10363


From duke at openjdk.org  Thu Jan 26 02:16:17 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 26 Jan 2023 02:16:17 GMT
Subject: RFR: 8298385: Some font classes rely on blind casting to implement
 Object.equals()
Message-ID: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>

Some also had two separate methods to check equality, one calling the other. Objects.equals() is used in some places as a replacement for a local copy of the function. In the end, the equals methods become quicker to understand their checks, more condensed, and becomes more in line with other equality methods in the JDK.

-------------

Commit messages:
 - Removal of AttributeValues.equals(Object, Object) did not replace with Object.equals
 - Reinstate public API methods
 - Forgor to update copyright year
 - Other font classes where equals(Object) can be improved
 - Revert variable name changes back to their original (instead of o1), suggested by ExE-Boss
 - Some font classes rely on blind casting to implement Object.equals()

Changes: https://git.openjdk.org/jdk/pull/10416/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10416&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298385
  Stats: 381 lines in 14 files changed: 42 ins; 215 del; 124 mod
  Patch: https://git.openjdk.org/jdk/pull/10416.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10416/head:pull/10416

PR: https://git.openjdk.org/jdk/pull/10416


From duke at openjdk.org  Thu Jan 26 02:16:28 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 26 Jan 2023 02:16:28 GMT
Subject: RFR: 8298385: Some font classes rely on blind casting to implement
 Object.equals()
In-Reply-To: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
References: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
Message-ID: <n2qSTzJLdN3Chspmjg-ojAAjGfu2ji2-CKXht-bjqzk=.2e40cab7-13f0-41a7-99a9-4e0551e8e73b@github.com>

On Sun, 25 Sep 2022 04:01:26 GMT, SWinxy <duke at openjdk.org> wrote:

> Some also had two separate methods to check equality, one calling the other. Objects.equals() is used in some places as a replacement for a local copy of the function. In the end, the equals methods become quicker to understand their checks, more condensed, and becomes more in line with other equality methods in the JDK.

Maybe?keep the?old?variable?names:

src/java.desktop/share/classes/java/awt/font/FontRenderContext.java line 314:

> 312:                         && o1.getFractionalMetricsHint() == getFractionalMetricsHint()
> 313:                         && o1.getTransform().equals(getTransform());
> 314:             }

Suggestion:

        if (o instanceof FontRenderContext rhs) {
            // if neither instance is a subclass, reference values directly.
            if (!rhs.defaulting && !defaulting) {
                return rhs.aaHintValue == aaHintValue
                        && rhs.fmHintValue == fmHintValue
                        && Objects.equals(tx, rhs.tx);
            } else {
                return rhs.getAntiAliasingHint() == getAntiAliasingHint()
                        && rhs.getFractionalMetricsHint() == getFractionalMetricsHint()
                        && rhs.getTransform().equals(getTransform());
            }

src/java.desktop/share/classes/java/awt/font/ImageGraphicAttribute.java line 190:

> 188:                 && getAlignment() == o1.getAlignment()
> 189:                 && fImage.equals(o1.fImage);
> 190: 

Suggestion:

        return this == o || o instanceof ImageGraphicAttribute rhs
                && fOriginX == rhs.fOriginX
                && fOriginY == rhs.fOriginY
                && getAlignment() == rhs.getAlignment()
                && fImage.equals(rhs.fImage);

src/java.desktop/share/classes/java/awt/font/ShapeGraphicAttribute.java line 217:

> 215:                 && fStroke == o1.fStroke
> 216:                 && getAlignment() == o1.getAlignment()
> 217:                 && fShape.equals(o1.fShape);

Suggestion:

        return this == o || o instanceof ShapeGraphicAttribute rhs
                && fStroke == rhs.fStroke
                && getAlignment() == rhs.getAlignment()
                && fShape.equals(rhs.fShape);

src/java.desktop/share/classes/java/awt/font/TransformAttribute.java line 162:

> 160:     public boolean equals(Object o) {
> 161:         return this == o || o instanceof TransformAttribute o1
> 162:                 && transform.equals(o1.transform);

Suggestion:

        return this == o || o instanceof TransformAttribute rhs
                && transform.equals(rhs.transform);

src/java.desktop/share/classes/sun/font/AttributeValues.java line 471:

> 469:                 && Objects.equals(font, o1.font)
> 470:                 && imUnderline == o1.imUnderline
> 471:                 && Objects.equals(imHighlight, o1.imHighlight);

Suggestion:

        return this == o || o instanceof AttributeValues rhs
                && defined == rhs.defined
                && nondefault == rhs.nondefault
                && underline == rhs.underline
                && strikethrough == rhs.strikethrough
                && superscript == rhs.superscript
                && width == rhs.width
                && kerning == rhs.kerning
                && tracking == rhs.tracking
                && ligatures == rhs.ligatures
                && runDirection == rhs.runDirection
                && bidiEmbedding == rhs.bidiEmbedding
                && swapColors == rhs.swapColors
                && Objects.equals(transform, rhs.transform)
                && Objects.equals(foreground, rhs.foreground)
                && Objects.equals(background, rhs.background)
                && Objects.equals(numericShaping, rhs.numericShaping)
                && Objects.equals(justification, rhs.justification)
                && Objects.equals(charReplacement, rhs.charReplacement)
                && size == rhs.size
                && weight == rhs.weight
                && posture == rhs.posture
                && Objects.equals(family, rhs.family)
                && Objects.equals(font, rhs.font)
                && imUnderline == rhs.imUnderline
                && Objects.equals(imHighlight, rhs.imHighlight);

src/java.desktop/share/classes/sun/font/CoreMetrics.java line 87:

> 85:                 && underlineThickness == o1.underlineThickness
> 86:                 && ssOffset == o1.ssOffset
> 87:                 && italicAngle == o1.italicAngle;

Suggestion:

        return this == o || o instanceof CoreMetrics rhs
                && ascent == rhs.ascent
                && descent == rhs.descent
                && leading == rhs.leading
                && baselineIndex == rhs.baselineIndex
                && baselineOffsets[0] == rhs.baselineOffsets[0]
                && baselineOffsets[1] == rhs.baselineOffsets[1]
                && baselineOffsets[2] == rhs.baselineOffsets[2]
                && strikethroughOffset == rhs.strikethroughOffset
                && strikethroughThickness == rhs.strikethroughThickness
                && underlineOffset == rhs.underlineOffset
                && underlineThickness == rhs.underlineThickness
                && ssOffset == rhs.ssOffset
                && italicAngle == rhs.italicAngle;

src/java.desktop/share/classes/sun/font/Decoration.java line 175:

> 173:                     && Objects.equals(fgPaint, o1.fgPaint)
> 174:                     && Objects.equals(bgPaint, o1.bgPaint)
> 175:                     && Objects.equals(imUnderline, o1.imUnderline);

Suggestion:

            return this == o || o instanceof DecorationImpl other
                    && swapColors == other.swapColors
                    && strikethrough == other.strikethrough
                    && Objects.equals(stdUnderline, other.stdUnderline)
                    && Objects.equals(fgPaint, other.fgPaint)
                    && Objects.equals(bgPaint, other.bgPaint)
                    && Objects.equals(imUnderline, other.imUnderline);

src/java.desktop/share/classes/sun/font/FontLineMetrics.java line 103:

> 101: 
> 102:     public boolean equals(Object o) {
> 103:         return this == o || o instanceof FontLineMetrics o1 && Objects.equals(cm, o1.cm);

Suggestion:

        return this == o || o instanceof FontLineMetrics rhs
            && Objects.equals(cm, rhs.cm);

src/java.desktop/share/classes/sun/font/GlyphLayout.java line 141:

> 139:                     && script == o1.script
> 140:                     && lang == o1.lang
> 141:                     && font.equals(o1.font);

Suggestion:

            return this == o || o instanceof LayoutEngineKey rhs
                    && script == rhs.script
                    && lang == rhs.lang
                    && font.equals(rhs.font);

src/java.desktop/share/classes/sun/font/GlyphLayout.java line 278:

> 276:                         && hash == o1.hash
> 277:                         && font.equals(o1.font)
> 278:                         && frc.equals(o1.frc);

Suggestion:

                return this == o || o instanceof SDKey rhs
                        && hash == rhs.hash
                        && font.equals(rhs.font)
                        && frc.equals(rhs.frc);

src/java.desktop/share/classes/sun/font/PhysicalFont.java line 45:

> 43: 
> 44:     public boolean equals(Object o) {
> 45:         return o instanceof PhysicalFont other

The?old?implementation also?checked that?the?runtime?class of?`other` is?the?same as?that?of?`this`:
Suggestion:

        return o instanceof PhysicalFont other
                && other.getClass() == this.getClass()

src/java.desktop/share/classes/sun/font/StandardGlyphVector.java line 694:

> 692:             }
> 693: 
> 694:             return Objects.equals(gti, o1.gti);

Suggestion:

        if (o instanceof StandardGlyphVector other) {
            if (glyphs.length != other.glyphs.length) {
                return false;
            }

            for (int i = 0; i < glyphs.length; ++i) {
                if (glyphs[i] != other.glyphs[i]) {
                    return false;
                }
            }

            if (!font.equals(other.font)) {
                return false;
            }

            if (!frc.equals(other.frc)) {
                return false;
            }

            if ((other.positions == null) != (positions == null)) {
                if (positions == null) {
                    initPositions();
                } else {
                    other.initPositions();
                }
            }

            if (positions != null) {
                for (int i = 0; i < positions.length; ++i) {
                    if (positions[i] != other.positions[i]) {
                        return false;
                    }
                }
            }

            return Objects.equals(gti, other.gti);

-------------

PR: https://git.openjdk.org/jdk/pull/10416


From duke at openjdk.org  Thu Jan 26 02:16:29 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 26 Jan 2023 02:16:29 GMT
Subject: RFR: 8298385: Some font classes rely on blind casting to implement
 Object.equals()
In-Reply-To: <n2qSTzJLdN3Chspmjg-ojAAjGfu2ji2-CKXht-bjqzk=.2e40cab7-13f0-41a7-99a9-4e0551e8e73b@github.com>
References: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
 <n2qSTzJLdN3Chspmjg-ojAAjGfu2ji2-CKXht-bjqzk=.2e40cab7-13f0-41a7-99a9-4e0551e8e73b@github.com>
Message-ID: <3MWrMLpM4lO7gHgFdHm5GD6DCm81GkxS9OdaI0jx_ww=.7da5757b-60da-40e3-b67a-5eba93bcb8d5@github.com>

On Sun, 25 Sep 2022 06:21:43 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Some also had two separate methods to check equality, one calling the other. Objects.equals() is used in some places as a replacement for a local copy of the function. In the end, the equals methods become quicker to understand their checks, more condensed, and becomes more in line with other equality methods in the JDK.
>
> Maybe?keep the?old?variable?names:

@ExE-Boss are you in the JBS? If you are, would you please add a bug report for this PR?

> src/java.desktop/share/classes/sun/font/PhysicalFont.java line 45:
> 
>> 43: 
>> 44:     public boolean equals(Object o) {
>> 45:         return o instanceof PhysicalFont other
> 
> The?old?implementation also?checked that?the?runtime?class of?`other` is?the?same as?that?of?`this`:
> Suggestion:
> 
>         return o instanceof PhysicalFont other
>                 && other.getClass() == this.getClass()

Intentional change. There is only one class that extends PhysicalFont, which also happens to overrides PhysicalFont's equals. So checking via instanceof shouldn't mean any change. Also I think I forgot to add a `o == this ||` to some of them... Tomorrow's problem.

-------------

PR: https://git.openjdk.org/jdk/pull/10416


From duke at openjdk.org  Thu Jan 26 02:16:30 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 26 Jan 2023 02:16:30 GMT
Subject: RFR: 8298385: Some font classes rely on blind casting to implement
 Object.equals()
In-Reply-To: <3MWrMLpM4lO7gHgFdHm5GD6DCm81GkxS9OdaI0jx_ww=.7da5757b-60da-40e3-b67a-5eba93bcb8d5@github.com>
References: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
 <n2qSTzJLdN3Chspmjg-ojAAjGfu2ji2-CKXht-bjqzk=.2e40cab7-13f0-41a7-99a9-4e0551e8e73b@github.com>
 <3MWrMLpM4lO7gHgFdHm5GD6DCm81GkxS9OdaI0jx_ww=.7da5757b-60da-40e3-b67a-5eba93bcb8d5@github.com>
Message-ID: <9iUZXnuBaE-wQW6P0E5d3jeiE0OLuIF9tTNNcviFc54=.fd99efec-1932-411c-b6c6-997fbc6bbce0@github.com>

On Sun, 25 Sep 2022 19:07:51 GMT, SWinxy <duke at openjdk.org> wrote:

>> Maybe?keep the?old?variable?names:
>
> @ExE-Boss are you in the JBS? If you are, would you please add a bug report for this PR?

@SWinxy
> @ExE-Boss are you in the JBS?

No, I?m?not.

> If you are, would you please add a bug report for this PR?

You?can?use https://bugreport.java.com/bugreport/ to?add?it?yourself.

-------------

PR: https://git.openjdk.org/jdk/pull/10416


From jwaters at openjdk.org  Thu Jan 26 02:16:33 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 26 Jan 2023 02:16:33 GMT
Subject: RFR: 8298385: Some font classes rely on blind casting to implement
 Object.equals()
In-Reply-To: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
References: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
Message-ID: <Ck2hu1VlCKshWpsk8vV1czCwCJwtRSMPvpyzXNxrdRE=.9e87c08c-8146-44f5-8c12-b5bea1d1364c@github.com>

On Sun, 25 Sep 2022 04:01:26 GMT, SWinxy <duke at openjdk.org> wrote:

> Some also had two separate methods to check equality, one calling the other. Objects.equals() is used in some places as a replacement for a local copy of the function. In the end, the equals methods become quicker to understand their checks, more condensed, and becomes more in line with other equality methods in the JDK.

Sorry for being so late, here's the corresponding entry: https://bugs.openjdk.org/browse/JDK-8298385

-------------

PR: https://git.openjdk.org/jdk/pull/10416


From duke at openjdk.org  Thu Jan 26 02:16:33 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 26 Jan 2023 02:16:33 GMT
Subject: RFR: 8298385: Some font classes rely on blind casting to implement
 Object.equals()
In-Reply-To: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
References: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
Message-ID: <Pdw49xZQ0YKrcoEKDJOu_J-Gj5bB7r3T5mE8F84rpJw=.21d4c3f4-6a0f-4531-8ddf-b27623f14f68@github.com>

On Sun, 25 Sep 2022 04:01:26 GMT, SWinxy <duke at openjdk.org> wrote:

> Some also had two separate methods to check equality, one calling the other. Objects.equals() is used in some places as a replacement for a local copy of the function. In the end, the equals methods become quicker to understand their checks, more condensed, and becomes more in line with other equality methods in the JDK.

Looks like there are issues with my PR that I haven't noticed. Shoot.

I forgot to re-apply the bug ID when I fixed the issues. Checks fail because of build chain, and GitHub isn't letting me re-run the jobs. Grr.

-------------

PR: https://git.openjdk.org/jdk/pull/10416


From serb at openjdk.org  Thu Jan 26 02:16:35 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 26 Jan 2023 02:16:35 GMT
Subject: RFR: 8298385: Some font classes rely on blind casting to implement
 Object.equals()
In-Reply-To: <Pdw49xZQ0YKrcoEKDJOu_J-Gj5bB7r3T5mE8F84rpJw=.21d4c3f4-6a0f-4531-8ddf-b27623f14f68@github.com>
References: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
 <Pdw49xZQ0YKrcoEKDJOu_J-Gj5bB7r3T5mE8F84rpJw=.21d4c3f4-6a0f-4531-8ddf-b27623f14f68@github.com>
Message-ID: <oH9qg_uC5dti6S14OdBk7V8_eQQN7jtSuv7L-Ph_-AA=.32c6cd35-72a8-42a7-9af6-f702e1090ef7@github.com>

On Thu, 8 Dec 2022 18:20:27 GMT, SWinxy <duke at openjdk.org> wrote:

> Looks like there are issues with my PR that I haven't noticed. Shoot.

While you are working on it you can move the PR to the draft state.

-------------

PR: https://git.openjdk.org/jdk/pull/10416


From serb at openjdk.org  Thu Jan 26 02:16:36 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 26 Jan 2023 02:16:36 GMT
Subject: RFR: 8298385: Some font classes rely on blind casting to implement
 Object.equals()
In-Reply-To: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
References: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
Message-ID: <rnprsF5CcDH2I3sAAiyKbn-c1EJu81WvYTf76MyJoHQ=.0c8338b4-3648-4c49-8fde-472ebf07f263@github.com>

On Sun, 25 Sep 2022 04:01:26 GMT, SWinxy <duke at openjdk.org> wrote:

> Some also had two separate methods to check equality, one calling the other. Objects.equals() is used in some places as a replacement for a local copy of the function. In the end, the equals methods become quicker to understand their checks, more condensed, and becomes more in line with other equality methods in the JDK.

src/java.desktop/share/classes/java/awt/font/FontRenderContext.java line 316:

> 314:      * @since 1.4
> 315:      */
> 316:     public boolean equals(FontRenderContext rhs) {

The public methods in the public classes in the `java/awt/*` package are part of the public API, it is not possible to delete such methods.

-------------

PR: https://git.openjdk.org/jdk/pull/10416


From duke at openjdk.org  Thu Jan 26 02:16:37 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 26 Jan 2023 02:16:37 GMT
Subject: RFR: 8298385: Some font classes rely on blind casting to implement
 Object.equals()
In-Reply-To: <rnprsF5CcDH2I3sAAiyKbn-c1EJu81WvYTf76MyJoHQ=.0c8338b4-3648-4c49-8fde-472ebf07f263@github.com>
References: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
 <rnprsF5CcDH2I3sAAiyKbn-c1EJu81WvYTf76MyJoHQ=.0c8338b4-3648-4c49-8fde-472ebf07f263@github.com>
Message-ID: <6v0Dij_26rawyhtVaIaA_arqkVirwcM3l46OaBS3eVI=.f260e2fb-4afe-49c8-a521-321f6e76cb0a@github.com>

On Fri, 9 Dec 2022 00:35:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Some also had two separate methods to check equality, one calling the other. Objects.equals() is used in some places as a replacement for a local copy of the function. In the end, the equals methods become quicker to understand their checks, more condensed, and becomes more in line with other equality methods in the JDK.
>
> src/java.desktop/share/classes/java/awt/font/FontRenderContext.java line 316:
> 
>> 314:      * @since 1.4
>> 315:      */
>> 316:     public boolean equals(FontRenderContext rhs) {
> 
> The public methods in the public classes in the `java/awt/*` package are part of the public API, it is not possible to delete such methods.

Whoops. Thanks for catching that.

-------------

PR: https://git.openjdk.org/jdk/pull/10416


From pminborg at openjdk.org  Thu Jan 26 09:00:34 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 26 Jan 2023 09:00:34 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <McLp1lkPcd_TuZvOdzfTiPg3ziNarfJxwq6IeiCfUws=.f3f0353f-9927-401a-9e6b-066bb48c5b9a@github.com>

On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

Here are some performance figures (TLDR: about 2% performance increase):

Baseline (J21 master)

     [java] All test results:
     [java] Test(imageio.input.stream.tests.readFully(int[])) averaged 2.0089243986475606E9 bytes/sec
     [java]     with 250x250, photo, byteArray, !useCache
     [java] Test(imageio.input.stream.tests.readLong) averaged 6.087925258517034E8 bytes/sec
     [java]     with 250x250, photo, byteArray, !useCache


Patch

     [java] All test results:
     [java] Test(imageio.input.stream.tests.readFully(int[]) averaged 2.0537614726652384E9 bytes/sec
     [java]     with 250x250, photo, byteArray, !useCache
     [java] Test(imageio.input.stream.tests.readLong) averaged 6.227265050569915E8 bytes/sec
     [java]     with 250x250, photo, byteArray, !useCache


the `readFully(int[])` is a custom benchmark:


                iis.mark();
                int[] array = new int[8];
                do {
                    if (pos + 4*8 > length) {
                        iis.reset();
                        iis.mark();
                        pos = 0;
                    }
                    iis.readFully(array, 0, 8);
                    pos += 4*8;
                } while (--numReps >= 0);


Tests were run on a Mac M1 aarch64 machine.

-------------

PR: https://git.openjdk.org/jdk/pull/12204


From tnakamura at openjdk.org  Thu Jan 26 09:15:47 2023
From: tnakamura at openjdk.org (Toshio Nakamura)
Date: Thu, 26 Jan 2023 09:15:47 GMT
Subject: RFR: 8295248: JEditorPane HTML form with multi-selection broke
 data after resetting [v4]
In-Reply-To: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
References: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
Message-ID: <qT_NTwX4CMvbMlJBs9_RsXiYzZMqYnxz-crKWActSyE=.7012ef4c-0030-42c8-8c06-fc8d3d5ee29f@github.com>

> When JEditorPane shown HTML form with multi-selection, the reset operation broke its data.
> 
> The sample testcase were attached in JBS. The recreate steps are below:
> 1. The sample shows a multi-selection form with 5 items.
> 2. Select the 4th item.
> 3. Press the reset button.
> Actual: The 4th item is still selected.
> Expect: No item should be selected. Resetting operation may move to the initial state. The sample doesn't use 'selected' property in each option tag.
> 4. Just after the step 3, move the focus to outside of the application and back.
> Actual: The 2nd item is selected. It means inside data indicates so.
> Expect: No item is selected.
> 
> There are two issues. The current method `OptionListModel.removeIndexInterval()` removed the indexed item, and shifted the rest. Then, selection values were corrupted.
> I think the clear selection method `OptionListModel.clearSelection()` is suitable here.
> 
> Test: jdk_desktop on macOS (x64, Monterey), Linux (x64, RHEL8), and Windows (x64, 2012R2).
>       No regression found

Toshio Nakamura has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Update Copyright years
 - Merge branch 'master' into 8295248
 - Fixed space
 - Update testcase
 - 8295248: JEditorPane HTML form with multi selection broke drawing after reseting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10685/files
  - new: https://git.openjdk.org/jdk/pull/10685/files/afe379e7..ca10ff83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10685&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10685&range=02-03

  Stats: 433393 lines in 6803 files changed: 215149 ins; 142592 del; 75652 mod
  Patch: https://git.openjdk.org/jdk/pull/10685.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10685/head:pull/10685

PR: https://git.openjdk.org/jdk/pull/10685


From pminborg at openjdk.org  Thu Jan 26 09:15:42 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 26 Jan 2023 09:15:42 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <7FkPoEUd1D8kRSJavY_WWu9JFN1PdXlTprwwZZVn2BU=.6f33250d-35c8-4fc3-92cd-b258299e209c@github.com>

On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

Given the way the benchmarks are written, I suspect the actual performance gains are higher than indicated by the figures above. The benchmark likely spends more time in preparing for the call (e.g. checking, looping) than in the actual target method.

-------------

PR: https://git.openjdk.org/jdk/pull/12204


From tnakamura at openjdk.org  Thu Jan 26 09:18:22 2023
From: tnakamura at openjdk.org (Toshio Nakamura)
Date: Thu, 26 Jan 2023 09:18:22 GMT
Subject: RFR: 8295248: JEditorPane HTML form with multi-selection broke
 data after resetting [v3]
In-Reply-To: <XJ54TYURwthQqWedWpAuAGeRuDqq043NdAQRcucAWpc=.6160f318-c362-4788-909e-7f9932ee99fb@github.com>
References: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
 <XJ54TYURwthQqWedWpAuAGeRuDqq043NdAQRcucAWpc=.6160f318-c362-4788-909e-7f9932ee99fb@github.com>
Message-ID: <M_banzscwT4GWinPMGzA9rJDAobfyTEVmyfzCY-yxxw=.f5405ae5-de2c-4234-8695-1b4900a33c80@github.com>

On Mon, 24 Oct 2022 02:06:23 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> When JEditorPane shown HTML form with multi-selection, the reset operation broke its data.
>> 
>> The sample testcase were attached in JBS. The recreate steps are below:
>> 1. The sample shows a multi-selection form with 5 items.
>> 2. Select the 4th item.
>> 3. Press the reset button.
>> Actual: The 4th item is still selected.
>> Expect: No item should be selected. Resetting operation may move to the initial state. The sample doesn't use 'selected' property in each option tag.
>> 4. Just after the step 3, move the focus to outside of the application and back.
>> Actual: The 2nd item is selected. It means inside data indicates so.
>> Expect: No item is selected.
>> 
>> There are two issues. The current method `OptionListModel.removeIndexInterval()` removed the indexed item, and shifted the rest. Then, selection values were corrupted.
>> I think the clear selection method `OptionListModel.clearSelection()` is suitable here.
>> 
>> Test: jdk_desktop on macOS (x64, Monterey), Linux (x64, RHEL8), and Windows (x64, 2012R2).
>>       No regression found
>
> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed space

(Reopened this PR.)
Let me re-explain the problem.
Currently, the reset action of HTML form uses `javax/swing/text/html/OptionListModel#removeIndexInternal`. It removes the indexed value. When a multiple selection form has 5 items, the method worked like below.


for (int i = 0; i < size; i++) {
    removeIndexInternal(i,i)
}



i - item values
0 - (1) 2  3  4  5 - remove 1st item and shift
     2  3  4  5  x
1 -  2 (3) 4  5  x - remove 2nd item and shift
     2  4  5  x  x
2 -  2  4 (5) x  x - remove 3rd item and shift
     2  4  x  x  x
3 -  2  4  x (x) x
4 -  2  4  x  x (x)


At the end, 2nd and 4th values remain even after resetting.

The intention of the function may clear all items, and `clearSelection` method can be appropriate.

-------------

PR: https://git.openjdk.org/jdk/pull/10685


From aturbanov at openjdk.org  Thu Jan 26 09:28:48 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 26 Jan 2023 09:28:48 GMT
Subject: RFR: 8300929: Avoid unnecessary array fill after creation in
 java.awt.image [v2]
In-Reply-To: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
References: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
Message-ID: <UuDy9HQjg4biGyePMid3CcKI7Gy6wcFJ2maahGycatQ=.441da7b3-38a1-44ab-8617-f6ca00aebe25@github.com>

> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8300929: Avoid unnecessary array fill after creation in java.awt.image
  
  add clarifying comment for the 'bandOffsets'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12147/files
  - new: https://git.openjdk.org/jdk/pull/12147/files/52bf8583..059b01f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12147&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12147&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12147.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12147/head:pull/12147

PR: https://git.openjdk.org/jdk/pull/12147


From aturbanov at openjdk.org  Thu Jan 26 09:28:50 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 26 Jan 2023 09:28:50 GMT
Subject: RFR: 8300929: Avoid unnecessary array fill after creation in
 java.awt.image [v2]
In-Reply-To: <4wl-9TD1_Q7eUgtGNlXVEwPgFvbJTvTIBIsJP8FfJ9U=.8c1ae7e9-df51-4e21-acba-62b2115e51fc@github.com>
References: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
 <RaGAJiwGcG8mxuY7kCdM2QG0AOn5zgzxb5LCLnnvXuI=.81c98a8a-e5a1-4a48-ae95-50d735bd45f1@github.com>
 <RRBMqJ6kaMOo-9kIqxHinRmKReqnxaCSM_bkVTpPjyc=.2dbe497e-7078-4ab2-8ed5-e51f66971ac1@github.com>
 <4wl-9TD1_Q7eUgtGNlXVEwPgFvbJTvTIBIsJP8FfJ9U=.8c1ae7e9-df51-4e21-acba-62b2115e51fc@github.com>
Message-ID: <4Mmwxt6zzUW7DfSf3iA5ahYLZEYskCxVKMpncTVD9XY=.8a64037c-30a8-4434-b84a-fe18d9b50dc4@github.com>

On Tue, 24 Jan 2023 22:50:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yeah, please, no commented-out code. I'd be fine with the code as it was, I don't think it needs much clarification. If @mrserb insists on a comment then I agree that a comment on the array declaration should be sufficient.
>
> That is not about the default values in the array but about missing initialization of `bandOffsets`, which we will skip intentionally. So it won't raise the question later why we initiated the Indices and not offsets.

I've added comment and moved array declaration. I think currently code is clear enough.

-------------

PR: https://git.openjdk.org/jdk/pull/12147


From attila at openjdk.org  Thu Jan 26 09:30:39 2023
From: attila at openjdk.org (Attila Szegedi)
Date: Thu, 26 Jan 2023 09:30:39 GMT
Subject: RFR: 8300929: Avoid unnecessary array fill after creation in
 java.awt.image [v2]
In-Reply-To: <UuDy9HQjg4biGyePMid3CcKI7Gy6wcFJ2maahGycatQ=.441da7b3-38a1-44ab-8617-f6ca00aebe25@github.com>
References: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
 <UuDy9HQjg4biGyePMid3CcKI7Gy6wcFJ2maahGycatQ=.441da7b3-38a1-44ab-8617-f6ca00aebe25@github.com>
Message-ID: <QNi7kbvG4_SfbCWQuFWy7UR7avKhtSa0cXSP_jYZjHc=.fc0daf7b-7f80-4422-b63d-3f887e7632ea@github.com>

On Thu, 26 Jan 2023 09:28:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300929: Avoid unnecessary array fill after creation in java.awt.image
>   
>   add clarifying comment for the 'bandOffsets'

Marked as reviewed by attila (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12147


From bourges.laurent at gmail.com  Thu Jan 26 10:10:43 2023
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 26 Jan 2023 11:10:43 +0100
Subject: Enhancing java2d Image classes & pipelines to support HDR (10b) or
 16bits RGBA
Message-ID: <CAKjRUT4ikL859oL8MPNVpkye0YbsZU8eU2838oUq67pK-MFYrg@mail.gmail.com>

Hi,

I would like enhancing Java Image classes (awt / java2D) to support
natively new image types with their use cases:
- BGRA (inverse RGBA) with both byte, integer & PREMUL variants (4x8bits),
as supported by skia, metal, vulkan apis
- 10 or 16 bits per RGBA component to support HDR or 64bits images like
R10G10B10A2 or R16G16B16A16, as supported by skia, metal, vulkan apis but
also by PNG & TIFF file formats

It represents a lot of work:
- CSR to define new BufferedImageType, Image API changes to deal with short
/ long values (rgba 48 or 64bits)
- fix native software loops (macros)
- fix DirectX, OpenGL, XRender, Metal pipelines for accelerated Surface

Ideally such image handling requires to handle properly gamma correction &
colorspaces (linear RGBA or perceptual sRGB, P3...) but it is maybe another
topic !

Comments are welcome & potential use cases too,

Thanks,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230126/e7413b58/attachment.htm>

From rriggs at openjdk.org  Thu Jan 26 16:08:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 26 Jan 2023 16:08:18 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <bSMNAtZQSAAp_kVC5HNj3PTavDNITZZVDZarXVhd8KE=.243d1099-2d99-4a59-80eb-7cfb4e502fb4@github.com>

On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

Can the benchmark be moved to the JMH framework; it deals with the setup and measurements in a more predictable way.
See test/micro/org/openjdk/bench/jajva/nio/... for examples.

-------------

PR: https://git.openjdk.org/jdk/pull/12204


From duke at openjdk.org  Thu Jan 26 16:17:29 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 26 Jan 2023 16:17:29 GMT
Subject: RFR: 8300929: Avoid unnecessary array fill after creation in
 java.awt.image [v2]
In-Reply-To: <4Mmwxt6zzUW7DfSf3iA5ahYLZEYskCxVKMpncTVD9XY=.8a64037c-30a8-4434-b84a-fe18d9b50dc4@github.com>
References: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
 <RaGAJiwGcG8mxuY7kCdM2QG0AOn5zgzxb5LCLnnvXuI=.81c98a8a-e5a1-4a48-ae95-50d735bd45f1@github.com>
 <RRBMqJ6kaMOo-9kIqxHinRmKReqnxaCSM_bkVTpPjyc=.2dbe497e-7078-4ab2-8ed5-e51f66971ac1@github.com>
 <4wl-9TD1_Q7eUgtGNlXVEwPgFvbJTvTIBIsJP8FfJ9U=.8c1ae7e9-df51-4e21-acba-62b2115e51fc@github.com>
 <4Mmwxt6zzUW7DfSf3iA5ahYLZEYskCxVKMpncTVD9XY=.8a64037c-30a8-4434-b84a-fe18d9b50dc4@github.com>
Message-ID: <iowpiIowkjx7H4r-gQq0dvMlqvHtjRfyk6NxjeU2Bxk=.9945ab88-b516-4b30-9fd6-6c7fc647cbf9@github.com>

On Thu, 26 Jan 2023 09:24:25 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> That is not about the default values in the array but about missing initialization of `bandOffsets`, which we will skip intentionally. So it won't raise the question later why we initiated the Indices and not offsets.
>
> I've added comment and moved array declaration. I think currently code is clear enough.

Yeah, the message is super clear now.

-------------

PR: https://git.openjdk.org/jdk/pull/12147


From prr at openjdk.org  Thu Jan 26 18:24:21 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Jan 2023 18:24:21 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v17]
In-Reply-To: <hF3_a7jZr5PrfWlGeu3r8585eaCKP1fLSNN0xhOGpzQ=.62524ef2-4726-4b87-bde8-3181bd8d70d3@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <hF3_a7jZr5PrfWlGeu3r8585eaCKP1fLSNN0xhOGpzQ=.62524ef2-4726-4b87-bde8-3181bd8d70d3@github.com>
Message-ID: <GgsxFNMMJt3XFeHYJQNNsnZphHg0RecNfdkckLz_GIA=.91f35eac-5c51-4a46-9f31-e40b4e5a9f29@github.com>

On Wed, 25 Jan 2023 13:22:31 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 incrementally with one additional commit since the last revision:
> 
>   Skip tests if required font is absent

I think I already raised this, but tests failing because Noto Color Emoji isn't installed is going to be a problem. It *largely* arises because these tests are headless .. (don't have @key headful) which in turn means that they are likely to be run on systems which aren't configured with any X11 libraries or fonts. Making them headful would be better since it is more reasonable to require that someone add a few more fonts to a system that has an Xserver than to one that isn't used for that at all.

-------------

PR: https://git.openjdk.org/jdk/pull/4798


From aivanov at openjdk.org  Thu Jan 26 19:44:19 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 26 Jan 2023 19:44:19 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url)
In-Reply-To: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
Message-ID: <xXS7SNRp8Sf78laD8b-jX4Zs6j49wFhYSSoadZQMf7M=.e45d1896-2d23-4eb8-b3a0-dbb7c0a4c7c6@github.com>

On Tue, 24 Jan 2023 23:29:58 GMT, Phil Race <prr at openjdk.org> wrote:

> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
> So deprecating - for removal - and adding warnings now in the docs is appropriate.

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java line 625:

> 623:      * trust, is strongly discouraged.
> 624:      * The alternative mechanisms to load styles from an {@code InputStream}
> 625:      * located as a resource co-located with the application or by

??an `InputStream` *located* as a resource co-located??

Will it sound clearer if the word ?located? is removed?

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From achung at openjdk.org  Thu Jan 26 19:44:41 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 26 Jan 2023 19:44:41 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v3]
In-Reply-To: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
Message-ID: <l8sgyoN8Ty-O-qmHImEZ56mIN-osNMCVEcOMFmYNsEU=.577c3d5c-e757-488a-9fff-7eb86eb559ca@github.com>

> Fixed test bug where mouse location was being calculated before robot mouseMove operation was complete

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  added debug statements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10363/files
  - new: https://git.openjdk.org/jdk/pull/10363/files/281589c2..4c8b373a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10363&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10363&range=01-02

  Stats: 15 lines in 2 files changed: 12 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10363.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10363/head:pull/10363

PR: https://git.openjdk.org/jdk/pull/10363


From prr at openjdk.org  Thu Jan 26 20:03:17 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Jan 2023 20:03:17 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url)
In-Reply-To: <xXS7SNRp8Sf78laD8b-jX4Zs6j49wFhYSSoadZQMf7M=.e45d1896-2d23-4eb8-b3a0-dbb7c0a4c7c6@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <xXS7SNRp8Sf78laD8b-jX4Zs6j49wFhYSSoadZQMf7M=.e45d1896-2d23-4eb8-b3a0-dbb7c0a4c7c6@github.com>
Message-ID: <5pfjnj0ytEyIOoB8AxCyvjeVxVYONn-HQMWz196jnVU=.614f4613-7c83-43db-8e3b-012c10032185@github.com>

On Thu, 26 Jan 2023 19:41:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
>> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
>> So deprecating - for removal - and adding warnings now in the docs is appropriate.
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java line 625:
> 
>> 623:      * trust, is strongly discouraged.
>> 624:      * The alternative mechanisms to load styles from an {@code InputStream}
>> 625:      * located as a resource co-located with the application or by
> 
> ??an `InputStream` *located* as a resource co-located??
> 
> Will it sound clearer if the word ?located? is removed?

"using a resource co-located with the application"  ?

I'm going to write up the CSR now since the wording seems mostly settled.

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From aivanov at openjdk.org  Thu Jan 26 20:14:18 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 26 Jan 2023 20:14:18 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url)
In-Reply-To: <5pfjnj0ytEyIOoB8AxCyvjeVxVYONn-HQMWz196jnVU=.614f4613-7c83-43db-8e3b-012c10032185@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <xXS7SNRp8Sf78laD8b-jX4Zs6j49wFhYSSoadZQMf7M=.e45d1896-2d23-4eb8-b3a0-dbb7c0a4c7c6@github.com>
 <5pfjnj0ytEyIOoB8AxCyvjeVxVYONn-HQMWz196jnVU=.614f4613-7c83-43db-8e3b-012c10032185@github.com>
Message-ID: <tM5tsGAE49LQZoASR9L4jMEFI1Vg-1bYj-ZBVhUdM6c=.a03a302a-2666-445c-8d58-1d314724be79@github.com>

On Thu, 26 Jan 2023 20:00:40 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java line 625:
>> 
>>> 623:      * trust, is strongly discouraged.
>>> 624:      * The alternative mechanisms to load styles from an {@code InputStream}
>>> 625:      * located as a resource co-located with the application or by
>> 
>> ??an `InputStream` *located* as a resource co-located??
>> 
>> Will it sound clearer if the word ?located? is removed?
>
> "using a resource co-located with the application"  ?
> 
> I'm going to write up the CSR now since the wording seems mostly settled.

Yes, it looks better to me. Thank you.

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From prr at openjdk.org  Thu Jan 26 20:21:24 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Jan 2023 20:21:24 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v2]
In-Reply-To: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
Message-ID: <X7zoKMBEXapS1IFCUDu9pYEPo4qF8INc8Cjjb6WYghQ=.02227de3-bda1-426e-bc47-5b59e9a1bb24@github.com>

> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
> So deprecating - for removal - and adding warnings now in the docs is appropriate.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8300891

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12175/files
  - new: https://git.openjdk.org/jdk/pull/12175/files/738414c0..1c80ec4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12175&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12175&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12175.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12175/head:pull/12175

PR: https://git.openjdk.org/jdk/pull/12175


From prr at openjdk.org  Thu Jan 26 20:32:18 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Jan 2023 20:32:18 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v2]
In-Reply-To: <X7zoKMBEXapS1IFCUDu9pYEPo4qF8INc8Cjjb6WYghQ=.02227de3-bda1-426e-bc47-5b59e9a1bb24@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <X7zoKMBEXapS1IFCUDu9pYEPo4qF8INc8Cjjb6WYghQ=.02227de3-bda1-426e-bc47-5b59e9a1bb24@github.com>
Message-ID: <SsMoWq_hj-wbvMeFawE_pBTthkl1g-7GalNVCX6VJec=.0f9a0bdd-dbce-42be-88e7-b35888e38478@github.com>

On Thu, 26 Jan 2023 20:21:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
>> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
>> So deprecating - for removal - and adding warnings now in the docs is appropriate.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300891

The CSR https://bugs.openjdk.org/browse/JDK-8301032 is now ready for a reviewer.
I did not include the doc-files changes since I don't think the comments there are required in the CSR.

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From dnguyen at openjdk.org  Thu Jan 26 22:36:39 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 26 Jan 2023 22:36:39 GMT
Subject: [jdk20] Integrated: 8300719: JDK 20 RDP2 L10n resource files update
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <z7OxU1K7tY5joYmEwBKhNW6uZjOx05mtjEF7bRlLNIg=.d95c6b89-3c0d-4400-8def-cd5b3d59c3e7@github.com>

On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

This pull request has now been integrated.

Changeset: a67b1e77
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/a67b1e77d33339f5db36c6d15bac0423a31eb5ee
Stats:     1023 lines in 82 files changed: 218 ins; 114 del; 691 mod

8300719: JDK 20 RDP2 L10n resource files update

Reviewed-by: cjplummer, naoto, prr, joehw, asemenyuk, jlu, lancea, ihse, jjg, weijun

-------------

PR: https://git.openjdk.org/jdk20/pull/116


From aivanov at openjdk.org  Thu Jan 26 22:40:18 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 26 Jan 2023 22:40:18 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v2]
In-Reply-To: <X7zoKMBEXapS1IFCUDu9pYEPo4qF8INc8Cjjb6WYghQ=.02227de3-bda1-426e-bc47-5b59e9a1bb24@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <X7zoKMBEXapS1IFCUDu9pYEPo4qF8INc8Cjjb6WYghQ=.02227de3-bda1-426e-bc47-5b59e9a1bb24@github.com>
Message-ID: <h5DCsgA90JsUdM0Rgi51goJk-hehBkXRpHr_CTHWucQ=.458c8c8b-2a6b-469a-a87e-3654d8d9be96@github.com>

On Thu, 26 Jan 2023 20:21:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
>> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
>> So deprecating - for removal - and adding warnings now in the docs is appropriate.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300891

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From psadhukhan at openjdk.org  Fri Jan 27 03:41:19 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 27 Jan 2023 03:41:19 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v2]
In-Reply-To: <X7zoKMBEXapS1IFCUDu9pYEPo4qF8INc8Cjjb6WYghQ=.02227de3-bda1-426e-bc47-5b59e9a1bb24@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <X7zoKMBEXapS1IFCUDu9pYEPo4qF8INc8Cjjb6WYghQ=.02227de3-bda1-426e-bc47-5b59e9a1bb24@github.com>
Message-ID: <ZjuFXvJf2JJVjjuTPoSi3t_SYU0woxK2CFlZYIQzjIY=.fc3ec610-1f3e-4a32-8a83-8c347b0249f9@github.com>

On Thu, 26 Jan 2023 20:21:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
>> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
>> So deprecating - for removal - and adding warnings now in the docs is appropriate.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300891

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java line 627:

> 625:      * using a resource co-located with the application or by
> 626:      * providing a {@code SynthStyleFactory} are preferred.
> 627:      * Consequently this method is deprecated and will be removed in a future release.

We probably can use "@see" tag to link the alternate preferred method `load(InputStream input, Class<?> resourceBase)` since this is going to be deprecated

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From psadhukhan at openjdk.org  Fri Jan 27 04:25:48 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 27 Jan 2023 04:25:48 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v2]
In-Reply-To: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
Message-ID: <3BtuavqYdt0jgniOlHFPZ8fm6gJvMPvqfkp7pMu67-s=.dbff2a1e-3f5b-46a4-a24d-2cceeb22284c@github.com>

> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
> Fix is made to reset the font if it is set by L&F.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Iterate all installed L&F

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12180/files
  - new: https://git.openjdk.org/jdk/pull/12180/files/57ea6be6..a704310e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12180&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12180&range=00-01

  Stats: 30 lines in 1 file changed: 16 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/12180.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12180/head:pull/12180

PR: https://git.openjdk.org/jdk/pull/12180


From psadhukhan at openjdk.org  Fri Jan 27 05:08:16 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 27 Jan 2023 05:08:16 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v3]
In-Reply-To: <kkN_fihRAOtPRTzHMmwe4NtWWzaDcZ4wnqCGBJB-r_o=.51f8dfb3-f108-48c0-ae0b-b32bda45ec4f@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <kkN_fihRAOtPRTzHMmwe4NtWWzaDcZ4wnqCGBJB-r_o=.51f8dfb3-f108-48c0-ae0b-b32bda45ec4f@github.com>
Message-ID: <I_2nVc_gNBlPUi5YW-ZxxIngM2TBi4Wo-QykDPu2LTE=.5189f52d-a94a-4625-ab7a-6d3ed0885635@github.com>

On Fri, 13 Jan 2023 04:03:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove blocking thread sleep for EDT

Any more comments on this? 
Should we close the JBS as "Not an issue"?
or
Should we just update the spec citing it's not necessary to wait for doInBackground() to finish before done() is called?
or
any other suggestion for the fix?

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Fri Jan 27 05:09:15 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 27 Jan 2023 05:09:15 GMT
Subject: RFR: 7169951: SwingSet2 throws NullPointerException with Nimbus
 L&F
In-Reply-To: <hU2Q5fjkF4qi35_Ai-qPNqxeZx1Xvu6dfKTPuHggbl0=.18f7a248-c577-4f93-9fab-e707289c8dc7@github.com>
References: <hU2Q5fjkF4qi35_Ai-qPNqxeZx1Xvu6dfKTPuHggbl0=.18f7a248-c577-4f93-9fab-e707289c8dc7@github.com>
Message-ID: <rJkKRWVSZog4WNTj6COTlOGRA1NR67LDdO7FM4yzGeY=.433ec244-d2fb-4c4d-a553-882202d6c5a9@github.com>

On Fri, 13 Jan 2023 04:25:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is observed that if SwingSet2 is run in Nimbus L&F and
> we drag the icon tool bar (which is floatable) out of the GUI Window
> and  Once the tool bar is detached, click on "Look & Feel" menu option to change to any L&F (say Java L&F)
> it causes NPE due to font being null when getFontMetrics() is called
> 
> In other L&F, it uses the tabPane's [font ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L2177) whereas in Nimbus font is obtained from getStyle().getFont() which returns null when toolbar is detached from the main window.
> The proposed fix is to get tabPane's font if the font passed is null alike other L&Fs. 
> 
> No regression test is made as it can be verified with SwingSet2..

Any more comments on this fix?

-------------

PR: https://git.openjdk.org/jdk/pull/11984


From dnguyen at openjdk.org  Fri Jan 27 05:31:56 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 27 Jan 2023 05:31:56 GMT
Subject: [jdk20] RFR: 8300269: The selected item in an editable JComboBox with
 titled border is not visible in Aqua LAF
Message-ID: <1_Ah8Gt3uFk_lcF4v4v8BzTaXL9IQooYrqR8p89KzBo=.78db6e48-73d7-442f-8bbb-f23564e7da5f@github.com>

Fixes regression bug where Aqua L&F editable JComboBox with a TitledBorder was not visible. 

This fix adds a conditional that addresses cases where a border is used on an AquaComboBox. The patch that caused the issue set a static height, but this height caused issues with a TitledBorder, which modifies the height to account for the border. In this case, revert to the old method of calculating a comboBox's height.

A point made in the previous PR was that the previous method had +1 to comboBox height. This could be re-added, but in the comment thread in [the previous PR](https://github.com/openjdk/jdk/pull/12087), leaving this out is better because the extra height causes the textField to be skewed South.

<img width="63" alt="Screen Shot 2023-01-20 at 12 54 47 PM" src="https://user-images.githubusercontent.com/96267980/214998560-2340ac1d-5df3-47ba-94f7-56459211330e.png">

This also adds the test that checks an editable JComboBox across all L&F's except GTK. There seems to be an unrelated bug to this fix that causes GTK L&F comboBoxes to not behave as expected with these key presses.

-------------

Commit messages:
 - Change line separator
 - Fix carriage return
 - Fix height issue with border. Add test

Changes: https://git.openjdk.org/jdk20/pull/119/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=119&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300269
  Stats: 184 lines in 2 files changed: 183 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/119.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/119/head:pull/119

PR: https://git.openjdk.org/jdk20/pull/119


From psadhukhan at openjdk.org  Fri Jan 27 05:31:56 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 27 Jan 2023 05:31:56 GMT
Subject: [jdk20] RFR: 8300269: The selected item in an editable JComboBox
 with titled border is not visible in Aqua LAF
In-Reply-To: <1_Ah8Gt3uFk_lcF4v4v8BzTaXL9IQooYrqR8p89KzBo=.78db6e48-73d7-442f-8bbb-f23564e7da5f@github.com>
References: <1_Ah8Gt3uFk_lcF4v4v8BzTaXL9IQooYrqR8p89KzBo=.78db6e48-73d7-442f-8bbb-f23564e7da5f@github.com>
Message-ID: <i-vUbJHbDIOsRYEfIdVdY41phAF1H-xp-qzqaY8dIhI=.b985f931-cdb3-4533-b409-46cafbec198e@github.com>

On Fri, 27 Jan 2023 02:40:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Fixes regression bug where Aqua L&F editable JComboBox with a TitledBorder was not visible. 
> 
> This fix adds a conditional that addresses cases where a border is used on an AquaComboBox. The patch that caused the issue set a static height, but this height caused issues with a TitledBorder, which modifies the height to account for the border. In this case, revert to the old method of calculating a comboBox's height.
> 
> A point made in the previous PR was that the previous method had +1 to comboBox height. This could be re-added, but in the comment thread in [the previous PR](https://github.com/openjdk/jdk/pull/12087), leaving this out is better because the extra height causes the textField to be skewed South.
> 
> <img width="63" alt="Screen Shot 2023-01-20 at 12 54 47 PM" src="https://user-images.githubusercontent.com/96267980/214998560-2340ac1d-5df3-47ba-94f7-56459211330e.png">
> 
> This also adds the test that checks an editable JComboBox across all L&F's except GTK. There seems to be an unrelated bug to this fix that causes GTK L&F comboBoxes to not behave as expected with these key presses.

There's jcheck issues with this PR...please fix it for review...

-------------

PR: https://git.openjdk.org/jdk20/pull/119


From dnguyen at openjdk.org  Fri Jan 27 05:31:56 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 27 Jan 2023 05:31:56 GMT
Subject: [jdk20] RFR: 8300269: The selected item in an editable JComboBox
 with titled border is not visible in Aqua LAF
In-Reply-To: <i-vUbJHbDIOsRYEfIdVdY41phAF1H-xp-qzqaY8dIhI=.b985f931-cdb3-4533-b409-46cafbec198e@github.com>
References: <1_Ah8Gt3uFk_lcF4v4v8BzTaXL9IQooYrqR8p89KzBo=.78db6e48-73d7-442f-8bbb-f23564e7da5f@github.com>
 <i-vUbJHbDIOsRYEfIdVdY41phAF1H-xp-qzqaY8dIhI=.b985f931-cdb3-4533-b409-46cafbec198e@github.com>
Message-ID: <qIfCy5lyYIwAVmBpMIrzCMYRmhM3b6l3eRwnkemkbpE=.746c4cf2-8048-4968-a5ee-3ddc8f09ccfc@github.com>

On Fri, 27 Jan 2023 04:01:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> There's jcheck issues with this PR...please fix it for review...

The branch had the wrong line separator because of another fix I had to complete. I believe it's fixed now whenever you can review @prsadhuk. Thanks!

-------------

PR: https://git.openjdk.org/jdk20/pull/119


From psadhukhan at openjdk.org  Fri Jan 27 07:22:23 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 27 Jan 2023 07:22:23 GMT
Subject: [jdk20] RFR: 8300269: The selected item in an editable JComboBox
 with titled border is not visible in Aqua LAF
In-Reply-To: <1_Ah8Gt3uFk_lcF4v4v8BzTaXL9IQooYrqR8p89KzBo=.78db6e48-73d7-442f-8bbb-f23564e7da5f@github.com>
References: <1_Ah8Gt3uFk_lcF4v4v8BzTaXL9IQooYrqR8p89KzBo=.78db6e48-73d7-442f-8bbb-f23564e7da5f@github.com>
Message-ID: <dB3Np63o0_1mj-WFb1crNltCOt5r0kAMGq0kH8_k-9Y=.b481c725-ade7-4969-b4ee-3b47c987faeb@github.com>

On Fri, 27 Jan 2023 02:40:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Fixes regression bug where Aqua L&F editable JComboBox with a TitledBorder was not visible. 
> 
> This fix adds a conditional that addresses cases where a border is used on an AquaComboBox. The patch that caused the issue set a static height, but this height caused issues with a TitledBorder, which modifies the height to account for the border. In this case, revert to the old method of calculating a comboBox's height.
> 
> A point made in the previous PR was that the previous method had +1 to comboBox height. This could be re-added, but in the comment thread in [the previous PR](https://github.com/openjdk/jdk/pull/12087), leaving this out is better because the extra height causes the textField to be skewed South.
> 
> <img width="63" alt="Screen Shot 2023-01-20 at 12 54 47 PM" src="https://user-images.githubusercontent.com/96267980/214998560-2340ac1d-5df3-47ba-94f7-56459211330e.png">
> 
> This also adds the test that checks an editable JComboBox across all L&F's except GTK. There seems to be an unrelated bug to this fix that causes GTK L&F comboBoxes to not behave as expected with these key presses.

test/jdk/javax/swing/JComboBox/JComboBoxWithTitledBorderTest.java line 76:

> 74:             // doesn't change text and resets to starting text instead.
> 75:             if (laf.equals("com.sun.java.swing.plaf.gtk.GTKLookAndFeel")) {
> 76:                 return;

Guess it should be "continue" instead of "return" to ensure other L&Fs can execute..

Also, I hope you have run full clientlibs and manual JComboxBox jtreg tests without issues since it's past RDP2...
Did you also try with other "Border" other than TitledBorder?

-------------

PR: https://git.openjdk.org/jdk20/pull/119


From abhiscxk at openjdk.org  Fri Jan 27 08:50:18 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 27 Jan 2023 08:50:18 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v2]
In-Reply-To: <3BtuavqYdt0jgniOlHFPZ8fm6gJvMPvqfkp7pMu67-s=.dbff2a1e-3f5b-46a4-a24d-2cceeb22284c@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <3BtuavqYdt0jgniOlHFPZ8fm6gJvMPvqfkp7pMu67-s=.dbff2a1e-3f5b-46a4-a24d-2cceeb22284c@github.com>
Message-ID: <NPg2o0RCLyjnFztx8AHimGvjLRTNFqW-Gus9O_Vkc2Y=.3940b52b-84ec-476f-aaa1-acf2f958c8e0@github.com>

On Fri, 27 Jan 2023 04:25:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
>> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
>> Fix is made to reset the font if it is set by L&F.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Iterate all installed L&F

Verified. Looks ok to me.

-------------

Marked as reviewed by abhiscxk (Author).

PR: https://git.openjdk.org/jdk/pull/12180


From dnguyen at openjdk.org  Fri Jan 27 10:14:51 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 27 Jan 2023 10:14:51 GMT
Subject: [jdk20] RFR: 8300269: The selected item in an editable JComboBox
 with titled border is not visible in Aqua LAF [v2]
In-Reply-To: <1_Ah8Gt3uFk_lcF4v4v8BzTaXL9IQooYrqR8p89KzBo=.78db6e48-73d7-442f-8bbb-f23564e7da5f@github.com>
References: <1_Ah8Gt3uFk_lcF4v4v8BzTaXL9IQooYrqR8p89KzBo=.78db6e48-73d7-442f-8bbb-f23564e7da5f@github.com>
Message-ID: <SX_jaaEgnl_vCLqvdl55gYcIbWpeFFob5Ma156q1rLU=.b51728a2-743c-4e75-ac05-36e5b81971f1@github.com>

> Fixes regression bug where Aqua L&F editable JComboBox with a TitledBorder was not visible. 
> 
> This fix adds a conditional that addresses cases where a border is used on an AquaComboBox. The patch that caused the issue set a static height, but this height caused issues with a TitledBorder, which modifies the height to account for the border. In this case, revert to the old method of calculating a comboBox's height.
> 
> A point made in the previous PR was that the previous method had +1 to comboBox height. This could be re-added, but in the comment thread in [the previous PR](https://github.com/openjdk/jdk/pull/12087), leaving this out is better because the extra height causes the textField to be skewed South.
> 
> <img width="63" alt="Screen Shot 2023-01-20 at 12 54 47 PM" src="https://user-images.githubusercontent.com/96267980/214998560-2340ac1d-5df3-47ba-94f7-56459211330e.png">
> 
> This also adds the test that checks an editable JComboBox across all L&F's except GTK. There seems to be an unrelated bug to this fix that causes GTK L&F comboBoxes to not behave as expected with these key presses.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Change return to continue

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/119/files
  - new: https://git.openjdk.org/jdk20/pull/119/files/1cb97b3f..05e8342b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=119&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=119&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/119.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/119/head:pull/119

PR: https://git.openjdk.org/jdk20/pull/119


From dnguyen at openjdk.org  Fri Jan 27 10:22:18 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 27 Jan 2023 10:22:18 GMT
Subject: [jdk20] RFR: 8300269: The selected item in an editable JComboBox
 with titled border is not visible in Aqua LAF [v2]
In-Reply-To: <dB3Np63o0_1mj-WFb1crNltCOt5r0kAMGq0kH8_k-9Y=.b481c725-ade7-4969-b4ee-3b47c987faeb@github.com>
References: <1_Ah8Gt3uFk_lcF4v4v8BzTaXL9IQooYrqR8p89KzBo=.78db6e48-73d7-442f-8bbb-f23564e7da5f@github.com>
 <dB3Np63o0_1mj-WFb1crNltCOt5r0kAMGq0kH8_k-9Y=.b481c725-ade7-4969-b4ee-3b47c987faeb@github.com>
Message-ID: <p3-QTLWTpgA1UZ7HAZy23Kyd7eWKTdrWPte_5oXRJUo=.a6d9743d-e373-43d4-8bbb-df791b20ac24@github.com>

On Fri, 27 Jan 2023 07:19:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change return to continue
>
> test/jdk/javax/swing/JComboBox/JComboBoxWithTitledBorderTest.java line 76:
> 
>> 74:             // doesn't change text and resets to starting text instead.
>> 75:             if (laf.equals("com.sun.java.swing.plaf.gtk.GTKLookAndFeel")) {
>> 76:                 return;
> 
> Guess it should be "continue" instead of "return" to ensure other L&Fs can execute..
> 
> Also, I hope you have run full clientlibs and manual JComboxBox jtreg tests without issues since it's past RDP2...
> Did you also try with other "Border" other than TitledBorder?

I agree, I updated this to "continue". I did run both the entire clientlibs test and the individual test with a repeat of 5. I will re-run these tests with the "continue" just in case this affects the results.

I tried locally with other Borders, such as LineBorder. The test still works for this case.

-------------

PR: https://git.openjdk.org/jdk20/pull/119


From psadhukhan at openjdk.org  Fri Jan 27 10:34:07 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 27 Jan 2023 10:34:07 GMT
Subject: RFR: 6817009: Action.SELECTED_KEY not toggled when using key binding
Message-ID: <DYsG8pG_MZQAuC3hOVqpwSoge8qrhCCZ-8GzuTVEmq0=.44e519dc-c56a-4b95-91c9-377a88bd0795@github.com>

When the Action.SELECTED_KEY property action is assigned to ToggleButton and an accelerator key binding is mapped to the action, then pressing the accelerator key binding does not toggle the toggle button.
This is because SwingUtilities.notifyAction does not fire itemStateChanged event for such action related to SELECTED_KEY.
Fix is to get the Action.SELECTED_KEY command/action and fire itemStateChanged Event via JToggleButton.setSelected() call to notify propertyChange listener of the toggled property.

-------------

Commit messages:
 - JDK-6817009: Action.SELECTED_KEY not toggled when using key binding

Changes: https://git.openjdk.org/jdk/pull/12253/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12253&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6817009
  Stats: 139 lines in 2 files changed: 139 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12253.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12253/head:pull/12253

PR: https://git.openjdk.org/jdk/pull/12253


From psadhukhan at openjdk.org  Fri Jan 27 10:36:24 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 27 Jan 2023 10:36:24 GMT
Subject: [jdk20] RFR: 8300269: The selected item in an editable JComboBox
 with titled border is not visible in Aqua LAF [v2]
In-Reply-To: <SX_jaaEgnl_vCLqvdl55gYcIbWpeFFob5Ma156q1rLU=.b51728a2-743c-4e75-ac05-36e5b81971f1@github.com>
References: <1_Ah8Gt3uFk_lcF4v4v8BzTaXL9IQooYrqR8p89KzBo=.78db6e48-73d7-442f-8bbb-f23564e7da5f@github.com>
 <SX_jaaEgnl_vCLqvdl55gYcIbWpeFFob5Ma156q1rLU=.b51728a2-743c-4e75-ac05-36e5b81971f1@github.com>
Message-ID: <SOKbqgMMR2K7qVyJ2LgzlR9_HHYAZgYm0yguxv-uBlc=.27b042ba-2414-4dca-a364-caffbf3f6ff4@github.com>

On Fri, 27 Jan 2023 10:14:51 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Fixes regression bug where Aqua L&F editable JComboBox with a TitledBorder was not visible. 
>> 
>> This fix adds a conditional that addresses cases where a border is used on an AquaComboBox. The patch that caused the issue set a static height, but this height caused issues with a TitledBorder, which modifies the height to account for the border. In this case, revert to the old method of calculating a comboBox's height.
>> 
>> A point made in the previous PR was that the previous method had +1 to comboBox height. This could be re-added, but in the comment thread in [the previous PR](https://github.com/openjdk/jdk/pull/12087), leaving this out is better because the extra height causes the textField to be skewed South.
>> 
>> <img width="63" alt="Screen Shot 2023-01-20 at 12 54 47 PM" src="https://user-images.githubusercontent.com/96267980/214998560-2340ac1d-5df3-47ba-94f7-56459211330e.png">
>> 
>> This also adds the test that checks an editable JComboBox across all L&F's except GTK. There seems to be an unrelated bug to this fix that causes GTK L&F comboBoxes to not behave as expected with these key presses.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change return to continue

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/119


From tr at openjdk.org  Fri Jan 27 11:03:18 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 27 Jan 2023 11:03:18 GMT
Subject: RFR: 8297454: javax/swing/JComponent/7154030/bug7154030.java
 failed with "Exception: Failed to show opaque button"
In-Reply-To: <nIuP21ewUd0nALclypyH1ULkFk_cAq5q34LIxmCloUs=.a7326479-4586-4a2f-bb38-15d572a4512d@github.com>
References: <nIuP21ewUd0nALclypyH1ULkFk_cAq5q34LIxmCloUs=.a7326479-4586-4a2f-bb38-15d572a4512d@github.com>
Message-ID: <j6mvsxfnlqQpHeA5xGcyGb6tcDNMGlRuECdKnMiHy70=.69ee52e6-18de-457d-8dfd-ee6040943204@github.com>

On Wed, 25 Jan 2023 06:41:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test intermittently failed in CI macos system owing to robot screencapture failing to compare the images.
> Seems like from artifacts, that composite image created by robot contains mouse cursor, which when compared are not giving exact pixel color. This has occurred in the past also for some tests for which we have made the mouseMove to move mouse cursor outside the area being captured for pixel comparison.
> Similar fix is done whereby mouse is moved to outside the captured area. Several iterations in CI are ok.

Marked as reviewed by tr (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/12179


From abhiscxk at openjdk.org  Fri Jan 27 11:05:16 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 27 Jan 2023 11:05:16 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: <eao5G7uMPnITKZIwmQT-OQ8SkDxskstZ5DbyCwX1JX8=.82f76996-a95f-4859-9355-78b42c56cfd7@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.

@prsadhuk Trying to run the test in **ubuntu** system, it ended with time out error. Test passed in **windows** system.

-------------

PR: https://git.openjdk.org/jdk/pull/12181


From tr at openjdk.org  Fri Jan 27 11:08:25 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 27 Jan 2023 11:08:25 GMT
Subject: Integrated: 8300405: Screen capture for test
 JFileChooserSetLocationTest.java, failure case
In-Reply-To: <H9i4szvE-s7cWX1cu8bkx6nLa3yvB44bftLmYbbfhvM=.a5ae761a-cfe3-4a71-80b2-88bbb6ae7858@github.com>
References: <H9i4szvE-s7cWX1cu8bkx6nLa3yvB44bftLmYbbfhvM=.a5ae761a-cfe3-4a71-80b2-88bbb6ae7858@github.com>
Message-ID: <XUCVpLCKbADJmUKFz4qPu_ZJVdN9YetSOqHw2pyV4xY=.11a10ed3-eb48-49ea-9b34-d70fdb848dab@github.com>

On Wed, 18 Jan 2023 06:37:30 GMT, Tejesh R <tr at openjdk.org> wrote:

> This is a diagnostic update related to [JDK-8295804](https://bugs.openjdk.org/browse/JDK-8295804). The issue was not reproducible and was showing up in particular machines (Where the machines are down now). So adding a screen capture to `BufferedImage` in case of failure so that it will help in analysis when the issue comes up in future.

This pull request has now been integrated.

Changeset: db8fa1be
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db8fa1be052c8558398ea5fea2105458f1a3cd16
Stats:     13 lines in 1 file changed: 12 ins; 0 del; 1 mod

8300405: Screen capture for test JFileChooserSetLocationTest.java, failure case

Reviewed-by: serb

-------------

PR: https://git.openjdk.org/jdk/pull/12060


From aivanov at openjdk.org  Fri Jan 27 14:04:24 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 27 Jan 2023 14:04:24 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v2]
In-Reply-To: <X7zoKMBEXapS1IFCUDu9pYEPo4qF8INc8Cjjb6WYghQ=.02227de3-bda1-426e-bc47-5b59e9a1bb24@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <X7zoKMBEXapS1IFCUDu9pYEPo4qF8INc8Cjjb6WYghQ=.02227de3-bda1-426e-bc47-5b59e9a1bb24@github.com>
Message-ID: <rjf087kHY1gdexy1B7dW-2nDwSac0wZlP1BDxEBl7sM=.b5bb33c6-1111-4948-85aa-20d83f38a926@github.com>

On Thu, 26 Jan 2023 20:21:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
>> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
>> So deprecating - for removal - and adding warnings now in the docs is appropriate.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300891

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java line 622:

> 620:      * delivered with a {@code LookAndFeel} or application, and so have an
> 621:      * equal level of trust with application code, using it to load from
> 622:      * from remote resources, particularly any which may have a lower level of

Suggestion:

     * equal level of trust with application code, using it to load from
     * remote resources, particularly any which may have a lower level of

The word _?from?_ is repeated, thank to IDEA for catching it.

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java line 627:

> 625:      * using a resource co-located with the application or by
> 626:      * providing a {@code SynthStyleFactory} are preferred.
> 627:      * Consequently this method is deprecated and will be removed in a future release.

Suggestion:

     * Consequently, this method is deprecated and will be removed in a future release.

Shall the comma be added?

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From aivanov at openjdk.org  Fri Jan 27 14:04:29 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 27 Jan 2023 14:04:29 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v2]
In-Reply-To: <ZjuFXvJf2JJVjjuTPoSi3t_SYU0woxK2CFlZYIQzjIY=.fc3ec610-1f3e-4a32-8a83-8c347b0249f9@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <X7zoKMBEXapS1IFCUDu9pYEPo4qF8INc8Cjjb6WYghQ=.02227de3-bda1-426e-bc47-5b59e9a1bb24@github.com>
 <ZjuFXvJf2JJVjjuTPoSi3t_SYU0woxK2CFlZYIQzjIY=.fc3ec610-1f3e-4a32-8a83-8c347b0249f9@github.com>
Message-ID: <jtGC8pDZ7hvsdLMo1fTkn8O-5l0jXi4mTNrPvLQXHRw=.98b85b3f-e582-4949-95fb-3465eda14f18@github.com>

On Fri, 27 Jan 2023 03:38:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8300891
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java line 627:
> 
>> 625:      * using a resource co-located with the application or by
>> 626:      * providing a {@code SynthStyleFactory} are preferred.
>> 627:      * Consequently this method is deprecated and will be removed in a future release.
> 
> We probably can use "@see" tag to link the alternate preferred method `load(InputStream input, Class<?> resourceBase)` since this is going to be deprecated

Great suggestion. The javadoc should link to the alternatives `load` or `SynthStyleFactory`.

The following line should be added to javadoc:

     * @deprecated Use {@link #load(InputStream, Class)} or {@link SynthStyleFactory}
     *             as described above.

The entire paragraph could probably used in `@deprecated`. The result would look like this:
![Rendered javadoc with @deprecated before the added paragraph](https://user-images.githubusercontent.com/70774172/215103931-2f093a8a-f057-49f7-8dce-e8cbb9e2ff90.png)

Here's the code that I used:

     * information.
     *
     * @deprecated Whilst this API may be safe for loading local resources that are
     * ...
     * The alternative mechanisms to load styles from an
     * {@link #load(InputStream, Class) InputStream} using a resource
     * co-located with the application or by
     * providing a {@link SynthStyleFactory} are preferred.
     * ...

However, such use of linking for `load` with `InputStream` is likely to be confusing, so the text should be re-worded.

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From tr at openjdk.org  Fri Jan 27 15:48:16 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 27 Jan 2023 15:48:16 GMT
Subject: RFR: 6817009: Action.SELECTED_KEY not toggled when using key
 binding
In-Reply-To: <DYsG8pG_MZQAuC3hOVqpwSoge8qrhCCZ-8GzuTVEmq0=.44e519dc-c56a-4b95-91c9-377a88bd0795@github.com>
References: <DYsG8pG_MZQAuC3hOVqpwSoge8qrhCCZ-8GzuTVEmq0=.44e519dc-c56a-4b95-91c9-377a88bd0795@github.com>
Message-ID: <NLJC2j1oR8Cz0xJPiQLFJtvQ3phYInRYHpxrrbICuWM=.20382aad-17a8-42aa-a33a-7a615f54ed99@github.com>

On Fri, 27 Jan 2023 10:26:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When the Action.SELECTED_KEY property action is assigned to ToggleButton and an accelerator key binding is mapped to the action, then pressing the accelerator key binding does not toggle the toggle button.
> This is because SwingUtilities.notifyAction does not fire itemStateChanged event for such action related to SELECTED_KEY.
> Fix is to get the Action.SELECTED_KEY command/action and fire itemStateChanged Event via JToggleButton.setSelected() call to notify propertyChange listener of the toggled property.

Fix work as expected.

-------------

Marked as reviewed by tr (Committer).

PR: https://git.openjdk.org/jdk/pull/12253


From alexsch at openjdk.org  Fri Jan 27 16:53:04 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Fri, 27 Jan 2023 16:53:04 GMT
Subject: RFR: 8301254: UNIX sun/font coding does not detect SuSE in openSUSE
 Leap distributive
Message-ID: <mT0PlFG6VxvcXjvjQjrvJLQqsHHLhB2aM74PzA_vDo8=.2759eb4a-97f7-4c9d-8806-08791f824c6c@github.com>

[JDK-8278549](https://bugs.openjdk.org/browse/JDK-8278549)` UNIX sun/font coding misses SUSE distro detection on recent distro SUSE 15` adds SuSE detection by checking SLES os name property in `/etc/os-release` file.

`opensuse/leap:15.4` docker defines os name property as `"openSUSE Leap"` in `/etc/os-release` file which is not recognized as SuSE.

The issue is reproduced with Oracle jdk-19.0.2 with custom fontconfig.SuSE.properties file copied to jdk-19.0.2/lib directory.

The fix checks if os name property from  `/etc/os-release` contains `SUSE`  substring.

Steps to reproduce.
- Download Oracle jdk-19.0.2
- Copy custom [fontconfig.SuSE.properties](https://bugs.openjdk.org/secure/attachment/102435/fontconfig.SuSE.properties) file to jdk-19.0.2/lib directory.
- Run the `opensuse/leap:15.4` docker and install freetype and dejavu fonts (do not install fontconfig)

docker run --rm --security-opt seccomp=unconfined -it opensuse/leap:15.4 bash
zypper install -y dejavu-fonts
zypper install -y freetype2

- Run HelloImage java sample in the docker

import javax.imageio.ImageIO;
import java.awt.*;
import java.awt.image.BufferedImage;
import java.io.File;

public class HelloImage {

    public static void main(String[] args) throws Exception {

        BufferedImage buff = new BufferedImage(300, 200, BufferedImage.TYPE_INT_RGB);
        Graphics2D g = buff.createGraphics();
        g.setColor(Color.WHITE);
        g.fillRect(0, 0, buff.getWidth(), buff.getHeight());

        g.setColor(Color.BLUE);
        g.setFont(g.getFont().deriveFont(32f));
        g.drawString("Hello, Image!", 50, 50);
        g.dispose();

        File file = new File("hello-image.png");
        ImageIO.write(buff, "png", file);
    }
}



./jdk-19.0.2/bin/javac HelloImage.java
./jdk-19.0.2/bin/java HelloImage
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:1261)
	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:706)
	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:318)
	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:56)
	at java.desktop/sun.font.PlatformFontInfo.createFontManager(PlatformFontInfo.java:37)
	at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:51)
	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:151)
	at java.desktop/sun.java2d.SunGraphics2D.checkFontInfo(SunGraphics2D.java:671)
	at java.desktop/sun.java2d.SunGraphics2D.getFontInfo(SunGraphics2D.java:837)
	at java.desktop/sun.java2d.pipe.GlyphListPipe.drawString(GlyphListPipe.java:46)
	at java.desktop/sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2931)
	at HelloImage.main(HelloImage.java:17)

-------------

Commit messages:
 - 8301254: UNIX sun/font coding does not detect SuSE in openSUSE Leap distributive

Changes: https://git.openjdk.org/jdk/pull/12260/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12260&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301254
  Stats: 7 lines in 2 files changed: 4 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12260/head:pull/12260

PR: https://git.openjdk.org/jdk/pull/12260


From alexsch at openjdk.org  Fri Jan 27 17:00:48 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Fri, 27 Jan 2023 17:00:48 GMT
Subject: RFR: 8301254: UNIX sun/font coding does not detect SuSE in
 openSUSE Leap distributive [v2]
In-Reply-To: <mT0PlFG6VxvcXjvjQjrvJLQqsHHLhB2aM74PzA_vDo8=.2759eb4a-97f7-4c9d-8806-08791f824c6c@github.com>
References: <mT0PlFG6VxvcXjvjQjrvJLQqsHHLhB2aM74PzA_vDo8=.2759eb4a-97f7-4c9d-8806-08791f824c6c@github.com>
Message-ID: <sU7oZqE6FU5biu3MNOA_zwKmYotbMX7edfWdKDHqggA=.51de7d26-db67-4cf8-a8ca-75a0e1c20b53@github.com>

> [JDK-8278549](https://bugs.openjdk.org/browse/JDK-8278549)` UNIX sun/font coding misses SUSE distro detection on recent distro SUSE 15` adds SuSE detection by checking SLES os name property in `/etc/os-release` file.
> 
> `opensuse/leap:15.4` docker defines os name property as `"openSUSE Leap"` in `/etc/os-release` file which is not recognized as SuSE.
> 
> The issue is reproduced with Oracle jdk-19.0.2 with custom fontconfig.SuSE.properties file copied to jdk-19.0.2/lib directory.
> 
> The fix checks if os name property from  `/etc/os-release` contains `SUSE`  substring.
> 
> Steps to reproduce.
> - Download Oracle jdk-19.0.2
> - Copy custom [fontconfig.SuSE.properties](https://bugs.openjdk.org/secure/attachment/102435/fontconfig.SuSE.properties) file to jdk-19.0.2/lib directory.
> - Run the `opensuse/leap:15.4` docker and install freetype and dejavu fonts (do not install fontconfig)
> 
> docker run --rm --security-opt seccomp=unconfined -it opensuse/leap:15.4 bash
> zypper install -y dejavu-fonts
> zypper install -y freetype2
> 
> - Run HelloImage java sample in the docker
> 
> import javax.imageio.ImageIO;
> import java.awt.*;
> import java.awt.image.BufferedImage;
> import java.io.File;
> 
> public class HelloImage {
> 
>     public static void main(String[] args) throws Exception {
> 
>         BufferedImage buff = new BufferedImage(300, 200, BufferedImage.TYPE_INT_RGB);
>         Graphics2D g = buff.createGraphics();
>         g.setColor(Color.WHITE);
>         g.fillRect(0, 0, buff.getWidth(), buff.getHeight());
> 
>         g.setColor(Color.BLUE);
>         g.setFont(g.getFont().deriveFont(32f));
>         g.drawString("Hello, Image!", 50, 50);
>         g.dispose();
> 
>         File file = new File("hello-image.png");
>         ImageIO.write(buff, "png", file);
>     }
> }
> 
> 
> 
> ./jdk-19.0.2/bin/javac HelloImage.java
> ./jdk-19.0.2/bin/java HelloImage
> 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:1261)
> 	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:706)
> 	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:318)
> 	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:56)
> 	at java.desktop/sun.font.PlatformFontInfo.createFontManager(PlatformFontInfo.java:37)
> 	at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:51)
> 	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:151)
> 	at java.desktop/sun.java2d.SunGraphics2D.checkFontInfo(SunGraphics2D.java:671)
> 	at java.desktop/sun.java2d.SunGraphics2D.getFontInfo(SunGraphics2D.java:837)
> 	at java.desktop/sun.java2d.pipe.GlyphListPipe.drawString(GlyphListPipe.java:46)
> 	at java.desktop/sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2931)
> 	at HelloImage.main(HelloImage.java:17)

Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:

  Revert back empty line removing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12260/files
  - new: https://git.openjdk.org/jdk/pull/12260/files/5253f196..ba04df3f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12260&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12260&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12260/head:pull/12260

PR: https://git.openjdk.org/jdk/pull/12260


From abhiscxk at openjdk.org  Fri Jan 27 17:37:20 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 27 Jan 2023 17:37:20 GMT
Subject: RFR: 7169951: SwingSet2 throws NullPointerException with Nimbus
 L&F
In-Reply-To: <hU2Q5fjkF4qi35_Ai-qPNqxeZx1Xvu6dfKTPuHggbl0=.18f7a248-c577-4f93-9fab-e707289c8dc7@github.com>
References: <hU2Q5fjkF4qi35_Ai-qPNqxeZx1Xvu6dfKTPuHggbl0=.18f7a248-c577-4f93-9fab-e707289c8dc7@github.com>
Message-ID: <xrd1s4Tybbf0GWieRaMruCpyhiUb1rde5XPzaOU_AOQ=.cbc3e477-8791-4498-bc7b-9fb37ff2598c@github.com>

On Fri, 13 Jan 2023 04:25:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is observed that if SwingSet2 is run in Nimbus L&F and
> we drag the icon tool bar (which is floatable) out of the GUI Window
> and  Once the tool bar is detached, click on "Look & Feel" menu option to change to any L&F (say Java L&F)
> it causes NPE due to font being null when getFontMetrics() is called
> 
> In other L&F, it uses the tabPane's [font ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L2177) whereas in Nimbus font is obtained from getStyle().getFont() which returns null when toolbar is detached from the main window.
> The proposed fix is to get tabPane's font if the font passed is null alike other L&Fs. 
> 
> No regression test is made as it can be verified with SwingSet2..

Verified SwingSet2 floating toolbar with current fix. 
I think copyright year can be updated else looks good to me.

-------------

Marked as reviewed by abhiscxk (Author).

PR: https://git.openjdk.org/jdk/pull/11984


From duke at openjdk.org  Fri Jan 27 17:39:24 2023
From: duke at openjdk.org (SWinxy)
Date: Fri, 27 Jan 2023 17:39:24 GMT
Subject: RFR: 6817009: Action.SELECTED_KEY not toggled when using key
 binding
In-Reply-To: <DYsG8pG_MZQAuC3hOVqpwSoge8qrhCCZ-8GzuTVEmq0=.44e519dc-c56a-4b95-91c9-377a88bd0795@github.com>
References: <DYsG8pG_MZQAuC3hOVqpwSoge8qrhCCZ-8GzuTVEmq0=.44e519dc-c56a-4b95-91c9-377a88bd0795@github.com>
Message-ID: <Aao6ZVcVQ9tlpRcwwZmjFlCHhJWdSYYZS-6_JtMF-SA=.14c5fb1b-2093-4b02-87e3-3d0c2a04f85f@github.com>

On Fri, 27 Jan 2023 10:26:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When the Action.SELECTED_KEY property action is assigned to ToggleButton and an accelerator key binding is mapped to the action, then pressing the accelerator key binding does not toggle the toggle button.
> This is because SwingUtilities.notifyAction does not fire itemStateChanged event for such action related to SELECTED_KEY.
> Fix is to get the Action.SELECTED_KEY command/action and fire itemStateChanged Event via JToggleButton.setSelected() call to notify propertyChange listener of the toggled property.

Changes requested by SWinxy at github.com (no known OpenJDK username).

src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 1814:

> 1812:                         modifiers));
> 1813:         if (event.getSource() instanceof JToggleButton) {
> 1814:             JToggleButton tb = (JToggleButton)event.getSource();

Please use a pattern variable here:
Suggestion:

        if (event.getSource() instanceof JToggleButton tb) {

-------------

PR: https://git.openjdk.org/jdk/pull/12253


From kizune at openjdk.org  Fri Jan 27 18:43:29 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 27 Jan 2023 18:43:29 GMT
Subject: [jdk20] RFR: 8300269: The selected item in an editable JComboBox
 with titled border is not visible in Aqua LAF [v2]
In-Reply-To: <SX_jaaEgnl_vCLqvdl55gYcIbWpeFFob5Ma156q1rLU=.b51728a2-743c-4e75-ac05-36e5b81971f1@github.com>
References: <1_Ah8Gt3uFk_lcF4v4v8BzTaXL9IQooYrqR8p89KzBo=.78db6e48-73d7-442f-8bbb-f23564e7da5f@github.com>
 <SX_jaaEgnl_vCLqvdl55gYcIbWpeFFob5Ma156q1rLU=.b51728a2-743c-4e75-ac05-36e5b81971f1@github.com>
Message-ID: <hme7Vgb75Bh2LYqWGAkFzv9e67uYFCkWGbW8bQw6hlk=.d2f4d794-c84f-4a5b-8aec-e18fbde3fe92@github.com>

On Fri, 27 Jan 2023 10:14:51 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Fixes regression bug where Aqua L&F editable JComboBox with a TitledBorder was not visible. 
>> 
>> This fix adds a conditional that addresses cases where a border is used on an AquaComboBox. The patch that caused the issue set a static height, but this height caused issues with a TitledBorder, which modifies the height to account for the border. In this case, revert to the old method of calculating a comboBox's height.
>> 
>> A point made in the previous PR was that the previous method had +1 to comboBox height. This could be re-added, but in the comment thread in [the previous PR](https://github.com/openjdk/jdk/pull/12087), leaving this out is better because the extra height causes the textField to be skewed South.
>> 
>> <img width="63" alt="Screen Shot 2023-01-20 at 12 54 47 PM" src="https://user-images.githubusercontent.com/96267980/214998560-2340ac1d-5df3-47ba-94f7-56459211330e.png">
>> 
>> This also adds the test that checks an editable JComboBox across all L&F's except GTK. There seems to be an unrelated bug to this fix that causes GTK L&F comboBoxes to not behave as expected with these key presses.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change return to continue

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/119


From duke at openjdk.org  Fri Jan 27 18:43:34 2023
From: duke at openjdk.org (duke)
Date: Fri, 27 Jan 2023 18:43:34 GMT
Subject: Withdrawn: 8296546: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <Bmh8EC1Xp-UN0iY-YE8mDhTuf06aJtr4orDONeB7J8U=.6380dac7-c81f-45be-aee5-4a5a3e6e2a5e@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11073


From prr at openjdk.org  Fri Jan 27 20:22:48 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 27 Jan 2023 20:22:48 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v3]
In-Reply-To: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
Message-ID: <F5rc9C6Tmfg97QGHmygzARQD0WWwulxsVXWp9x0s38U=.2681ab7b-c858-496e-9016-1f8cb00f6125@github.com>

> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
> So deprecating - for removal - and adding warnings now in the docs is appropriate.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8300891

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12175/files
  - new: https://git.openjdk.org/jdk/pull/12175/files/1c80ec4b..a9d49aa3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12175&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12175&range=01-02

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12175.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12175/head:pull/12175

PR: https://git.openjdk.org/jdk/pull/12175


From achung at openjdk.org  Fri Jan 27 20:25:27 2023
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 27 Jan 2023 20:25:27 GMT
Subject: [jdk20] RFR: 8300269: The selected item in an editable JComboBox
 with titled border is not visible in Aqua LAF [v2]
In-Reply-To: <SX_jaaEgnl_vCLqvdl55gYcIbWpeFFob5Ma156q1rLU=.b51728a2-743c-4e75-ac05-36e5b81971f1@github.com>
References: <1_Ah8Gt3uFk_lcF4v4v8BzTaXL9IQooYrqR8p89KzBo=.78db6e48-73d7-442f-8bbb-f23564e7da5f@github.com>
 <SX_jaaEgnl_vCLqvdl55gYcIbWpeFFob5Ma156q1rLU=.b51728a2-743c-4e75-ac05-36e5b81971f1@github.com>
Message-ID: <i0hW6PGUG--yOEyro3xUhzR29RpSa9Ef4iFHT_wzVaU=.8f74fa51-8ea8-4be4-abcd-77627a720294@github.com>

On Fri, 27 Jan 2023 10:14:51 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Fixes regression bug where Aqua L&F editable JComboBox with a TitledBorder was not visible. 
>> 
>> This fix adds a conditional that addresses cases where a border is used on an AquaComboBox. The patch that caused the issue set a static height, but this height caused issues with a TitledBorder, which modifies the height to account for the border. In this case, revert to the old method of calculating a comboBox's height.
>> 
>> A point made in the previous PR was that the previous method had +1 to comboBox height. This could be re-added, but in the comment thread in [the previous PR](https://github.com/openjdk/jdk/pull/12087), leaving this out is better because the extra height causes the textField to be skewed South.
>> 
>> <img width="63" alt="Screen Shot 2023-01-20 at 12 54 47 PM" src="https://user-images.githubusercontent.com/96267980/214998560-2340ac1d-5df3-47ba-94f7-56459211330e.png">
>> 
>> This also adds the test that checks an editable JComboBox across all L&F's except GTK. There seems to be an unrelated bug to this fix that causes GTK L&F comboBoxes to not behave as expected with these key presses.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change return to continue

Marked as reviewed by achung (Committer).

-------------

PR: https://git.openjdk.org/jdk20/pull/119


From prr at openjdk.org  Fri Jan 27 20:27:20 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 27 Jan 2023 20:27:20 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v3]
In-Reply-To: <F5rc9C6Tmfg97QGHmygzARQD0WWwulxsVXWp9x0s38U=.2681ab7b-c858-496e-9016-1f8cb00f6125@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <F5rc9C6Tmfg97QGHmygzARQD0WWwulxsVXWp9x0s38U=.2681ab7b-c858-496e-9016-1f8cb00f6125@github.com>
Message-ID: <IqCdla1K_k9WPccI6KaRlhoFXs1PzCtMIBDlSyJJbrc=.f4eec849-6312-4ff3-a204-11f12c535560@github.com>

On Fri, 27 Jan 2023 20:22:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
>> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
>> So deprecating - for removal - and adding warnings now in the docs is appropriate.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300891

I added the links and removed the from but the "," and moving the text doesn't work well as
the @deprecated tag is placed first by the javadoc and I think it was better to go into the explanation where it was.
Also "as described above" doesn't work because there's nothing above ..

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From jwilhelm at openjdk.org  Fri Jan 27 21:08:40 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 27 Jan 2023 21:08:40 GMT
Subject: RFR: Merge jdk20
Message-ID: <7o8i6xuRhpJrSJJg2EUyu-JPcawJAytTWS3yHX3PZd0=.0157940a-bbb2-4dc0-a645-5cde446d5052@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8301206: Fix issue with LocaleData after JDK-8300719
 - 8300953: ClassDesc::ofInternalName missing @since tag
 - 8300719: JDK 20 RDP2 L10n resource files update

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=12267&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=12267&range=00.1

Changes: https://git.openjdk.org/jdk/pull/12267/files
  Stats: 1078 lines in 85 files changed: 220 ins; 114 del; 744 mod
  Patch: https://git.openjdk.org/jdk/pull/12267.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12267/head:pull/12267

PR: https://git.openjdk.org/jdk/pull/12267


From prr at openjdk.org  Fri Jan 27 21:48:26 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 27 Jan 2023 21:48:26 GMT
Subject: [jdk20] RFR: 8300269: The selected item in an editable JComboBox
 with titled border is not visible in Aqua LAF [v2]
In-Reply-To: <SX_jaaEgnl_vCLqvdl55gYcIbWpeFFob5Ma156q1rLU=.b51728a2-743c-4e75-ac05-36e5b81971f1@github.com>
References: <1_Ah8Gt3uFk_lcF4v4v8BzTaXL9IQooYrqR8p89KzBo=.78db6e48-73d7-442f-8bbb-f23564e7da5f@github.com>
 <SX_jaaEgnl_vCLqvdl55gYcIbWpeFFob5Ma156q1rLU=.b51728a2-743c-4e75-ac05-36e5b81971f1@github.com>
Message-ID: <zOBz2MvHzhPXf-WdA2WfmWMBWUNfN7DW5ftG788IVtA=.9c1cbb06-0a99-4543-a049-c43ccffa033b@github.com>

On Fri, 27 Jan 2023 10:14:51 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Fixes regression bug where Aqua L&F editable JComboBox with a TitledBorder was not visible. 
>> 
>> This fix adds a conditional that addresses cases where a border is used on an AquaComboBox. The patch that caused the issue set a static height, but this height caused issues with a TitledBorder, which modifies the height to account for the border. In this case, revert to the old method of calculating a comboBox's height.
>> 
>> A point made in the previous PR was that the previous method had +1 to comboBox height. This could be re-added, but in the comment thread in [the previous PR](https://github.com/openjdk/jdk/pull/12087), leaving this out is better because the extra height causes the textField to be skewed South.
>> 
>> <img width="63" alt="Screen Shot 2023-01-20 at 12 54 47 PM" src="https://user-images.githubusercontent.com/96267980/214998560-2340ac1d-5df3-47ba-94f7-56459211330e.png">
>> 
>> This also adds the test that checks an editable JComboBox across all L&F's except GTK. There seems to be an unrelated bug to this fix that causes GTK L&F comboBoxes to not behave as expected with these key presses.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change return to continue

This looks to me like it will need reworking in future - "22" seems a bit too much of a magic number - but reverting to using the height

src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 460:

> 458:         protected Rectangle rectangleForCurrentValue() {
> 459:             int width = comboBox.getWidth();
> 460:             int height = comboBox.getBorder() == null ? 22 : comboBox.getHeight();

This looks to me like it will need reworking in future - "22" seems a bit too much of a magic number - but reverting to using the height for the problem case seems safe.
However please do run all related Swing tests on Aqua INCLUDING manual tests of the combo-box - perhaps using SwingSet2 - to make sure it looks good.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/119


From duke at openjdk.org  Fri Jan 27 22:25:08 2023
From: duke at openjdk.org (ScientificWare)
Date: Fri, 27 Jan 2023 22:25:08 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v24]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <iK_0y4P_wjCbgDVWrmMEEvrZDfroR-boBj8zCC5Qebc=.b010849a-ef58-4083-b23e-2eb56983514f@github.com>

> 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:

  Updates stringToColor specifications
  
  Updates stringToColor specifications to integrate a reference to CSS Color Module 4 for color names and hexadecimal notation.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/070462e9..7c2fc48c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=22-23

  Stats: 22 lines in 1 file changed: 15 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9825.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9825/head:pull/9825

PR: https://git.openjdk.org/jdk/pull/9825


From jwilhelm at openjdk.org  Fri Jan 27 22:49:26 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 27 Jan 2023 22:49:26 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <7o8i6xuRhpJrSJJg2EUyu-JPcawJAytTWS3yHX3PZd0=.0157940a-bbb2-4dc0-a645-5cde446d5052@github.com>
References: <7o8i6xuRhpJrSJJg2EUyu-JPcawJAytTWS3yHX3PZd0=.0157940a-bbb2-4dc0-a645-5cde446d5052@github.com>
Message-ID: <JVZE_mPEwJ2rcS4QD7ftXAXrVcbj_TksRnNb7Nmdi-U=.44286872-ced9-458a-b59d-879b09876ecf@github.com>

On Fri, 27 Jan 2023 21:00:03 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 5c59de52
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c59de52a31da937663ad2cef055213489b0516e
Stats:     1078 lines in 85 files changed: 220 ins; 114 del; 744 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/12267


From dnguyen at openjdk.org  Fri Jan 27 23:12:28 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 27 Jan 2023 23:12:28 GMT
Subject: [jdk20] Integrated: 8300269: The selected item in an editable
 JComboBox with titled border is not visible in Aqua LAF
In-Reply-To: <1_Ah8Gt3uFk_lcF4v4v8BzTaXL9IQooYrqR8p89KzBo=.78db6e48-73d7-442f-8bbb-f23564e7da5f@github.com>
References: <1_Ah8Gt3uFk_lcF4v4v8BzTaXL9IQooYrqR8p89KzBo=.78db6e48-73d7-442f-8bbb-f23564e7da5f@github.com>
Message-ID: <IfC1KFaGeHOFnXIOlelucz8oDq-GXjT51RLAZQ_JsIU=.b8fe6729-148a-47d0-8c12-def98d004977@github.com>

On Fri, 27 Jan 2023 02:40:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Fixes regression bug where Aqua L&F editable JComboBox with a TitledBorder was not visible. 
> 
> This fix adds a conditional that addresses cases where a border is used on an AquaComboBox. The patch that caused the issue set a static height, but this height caused issues with a TitledBorder, which modifies the height to account for the border. In this case, revert to the old method of calculating a comboBox's height.
> 
> A point made in the previous PR was that the previous method had +1 to comboBox height. This could be re-added, but in the comment thread in [the previous PR](https://github.com/openjdk/jdk/pull/12087), leaving this out is better because the extra height causes the textField to be skewed South.
> 
> <img width="63" alt="Screen Shot 2023-01-20 at 12 54 47 PM" src="https://user-images.githubusercontent.com/96267980/214998560-2340ac1d-5df3-47ba-94f7-56459211330e.png">
> 
> This also adds the test that checks an editable JComboBox across all L&F's except GTK. There seems to be an unrelated bug to this fix that causes GTK L&F comboBoxes to not behave as expected with these key presses.

This pull request has now been integrated.

Changeset: ef6200c7
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/ef6200c727332796d2e1c8ae3bfa155cbaa72f4c
Stats:     184 lines in 2 files changed: 183 ins; 0 del; 1 mod

8300269: The selected item in an editable JComboBox with titled border is not visible in Aqua LAF

Co-authored-by: Manukumar V S <mvs at openjdk.org>
Reviewed-by: psadhukhan, kizune, achung, prr

-------------

PR: https://git.openjdk.org/jdk20/pull/119


From duke at openjdk.org  Sat Jan 28 00:39:27 2023
From: duke at openjdk.org (duke)
Date: Sat, 28 Jan 2023 00:39:27 GMT
Subject: Withdrawn: 8298042: Fix hidden but significant trailing whitespace in
 properties files for client code
In-Reply-To: <fHGFT7w4afEunhQKcP-Y6B6PKSczto3m4vqeWIzplME=.c2b40ecd-5f83-4adf-b07d-4d34d196ed24@github.com>
References: <fHGFT7w4afEunhQKcP-Y6B6PKSczto3m4vqeWIzplME=.c2b40ecd-5f83-4adf-b07d-4d34d196ed24@github.com>
Message-ID: <ZNRuYJ4ATh2ue9vEwzPAtS2qoqLs41cq9_AXL7RTCJ0=.2aa95004-bb5e-44db-9bd8-8d8daa28b8d8@github.com>

On Fri, 2 Dec 2022 16:38:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the client-libs team.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11488


From duke at openjdk.org  Sat Jan 28 02:29:20 2023
From: duke at openjdk.org (SWinxy)
Date: Sat, 28 Jan 2023 02:29:20 GMT
Subject: RFR: 8301254: UNIX sun/font coding does not detect SuSE in
 openSUSE Leap distributive [v2]
In-Reply-To: <sU7oZqE6FU5biu3MNOA_zwKmYotbMX7edfWdKDHqggA=.51de7d26-db67-4cf8-a8ca-75a0e1c20b53@github.com>
References: <mT0PlFG6VxvcXjvjQjrvJLQqsHHLhB2aM74PzA_vDo8=.2759eb4a-97f7-4c9d-8806-08791f824c6c@github.com>
 <sU7oZqE6FU5biu3MNOA_zwKmYotbMX7edfWdKDHqggA=.51de7d26-db67-4cf8-a8ca-75a0e1c20b53@github.com>
Message-ID: <D8JdiJIruDWXXpA0t9xaRBkvKZ39vKHZ5pwEwhrilDo=.c7311ba7-c32b-4dd6-b279-b1e0c625f82e@github.com>

On Fri, 27 Jan 2023 17:00:48 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> [JDK-8278549](https://bugs.openjdk.org/browse/JDK-8278549)` UNIX sun/font coding misses SUSE distro detection on recent distro SUSE 15` adds SuSE detection by checking SLES os name property in `/etc/os-release` file.
>> 
>> `opensuse/leap:15.4` docker defines os name property as `"openSUSE Leap"` in `/etc/os-release` file which is not recognized as SuSE.
>> 
>> The issue is reproduced with Oracle jdk-19.0.2 with custom fontconfig.SuSE.properties file copied to jdk-19.0.2/lib directory.
>> 
>> The fix checks if os name property from  `/etc/os-release` contains `SUSE`  substring.
>> 
>> Steps to reproduce.
>> - Download Oracle jdk-19.0.2
>> - Copy custom [fontconfig.SuSE.properties](https://bugs.openjdk.org/secure/attachment/102435/fontconfig.SuSE.properties) file to jdk-19.0.2/lib directory.
>> - Run the `opensuse/leap:15.4` docker and install freetype and dejavu fonts (do not install fontconfig)
>> 
>> docker run --rm --security-opt seccomp=unconfined -it opensuse/leap:15.4 bash
>> zypper install -y dejavu-fonts
>> zypper install -y freetype2
>> 
>> - Run HelloImage java sample in the docker
>> 
>> import javax.imageio.ImageIO;
>> import java.awt.*;
>> import java.awt.image.BufferedImage;
>> import java.io.File;
>> 
>> public class HelloImage {
>> 
>>     public static void main(String[] args) throws Exception {
>> 
>>         BufferedImage buff = new BufferedImage(300, 200, BufferedImage.TYPE_INT_RGB);
>>         Graphics2D g = buff.createGraphics();
>>         g.setColor(Color.WHITE);
>>         g.fillRect(0, 0, buff.getWidth(), buff.getHeight());
>> 
>>         g.setColor(Color.BLUE);
>>         g.setFont(g.getFont().deriveFont(32f));
>>         g.drawString("Hello, Image!", 50, 50);
>>         g.dispose();
>> 
>>         File file = new File("hello-image.png");
>>         ImageIO.write(buff, "png", file);
>>     }
>> }
>> 
>> 
>> 
>> ./jdk-19.0.2/bin/javac HelloImage.java
>> ./jdk-19.0.2/bin/java HelloImage
>> 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:1261)
>> 	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:706)
>> 	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:318)
>> 	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:56)
>> 	at java.desktop/sun.font.PlatformFontInfo.createFontManager(PlatformFontInfo.java:37)
>> 	at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:51)
>> 	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:151)
>> 	at java.desktop/sun.java2d.SunGraphics2D.checkFontInfo(SunGraphics2D.java:671)
>> 	at java.desktop/sun.java2d.SunGraphics2D.getFontInfo(SunGraphics2D.java:837)
>> 	at java.desktop/sun.java2d.pipe.GlyphListPipe.drawString(GlyphListPipe.java:46)
>> 	at java.desktop/sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2931)
>> 	at HelloImage.main(HelloImage.java:17)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert back empty line removing

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/12260


From aivanov at openjdk.org  Sat Jan 28 18:55:16 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 28 Jan 2023 18:55:16 GMT
Subject: RFR: 4934362: see also refers to self [v4]
In-Reply-To: <YYfN2px7U82QiuHv4HHIe-5PGuaPfpx6D2lgL1np1BI=.263bd130-df76-44c3-b2a2-70f4e6d3e9d6@github.com>
References: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
 <YYfN2px7U82QiuHv4HHIe-5PGuaPfpx6D2lgL1np1BI=.263bd130-df76-44c3-b2a2-70f4e6d3e9d6@github.com>
Message-ID: <zVN2FPYk51ZFNkZSj5X8dnuFRZ2BCIGthZxCoMci-M4=.5c027340-e963-4155-a1d6-c2809f6579a8@github.com>

On Mon, 9 Jan 2023 03:57:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Some methods and constants has a hyperreference to self in javadoc which is rectified to reference proper methods
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Point to isEditable method

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11820


From aivanov at openjdk.org  Sun Jan 29 15:00:19 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sun, 29 Jan 2023 15:00:19 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v3]
In-Reply-To: <kkN_fihRAOtPRTzHMmwe4NtWWzaDcZ4wnqCGBJB-r_o=.51f8dfb3-f108-48c0-ae0b-b32bda45ec4f@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <kkN_fihRAOtPRTzHMmwe4NtWWzaDcZ4wnqCGBJB-r_o=.51f8dfb3-f108-48c0-ae0b-b32bda45ec4f@github.com>
Message-ID: <hCEkbC4GGKOfytfFY1fAAi4cuCoKa1dasJb1p6lGwIo=.ea01e9e1-084e-4db0-a0d3-2cecdf4eec3b@github.com>

On Fri, 13 Jan 2023 04:03:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove blocking thread sleep for EDT

Blocking EDT with `cancel` is unacceptable.

I propose the following fix ([**diff to your PR**](https://github.com/openjdk/jdk/compare/pr/11940...aivanov-jdk:prasanta/8081474-SwingWorker-done)):

diff --git a/src/java.desktop/share/classes/javax/swing/SwingWorker.java b/src/java.desktop/share/classes/javax/swing/SwingWorker.java
index 6acca76d859..9da72fe2f0a 100644
--- a/src/java.desktop/share/classes/javax/swing/SwingWorker.java
+++ b/src/java.desktop/share/classes/javax/swing/SwingWorker.java
@@ -301,18 +301,16 @@ public abstract class SwingWorker<T, V> implements RunnableFuture<T> {
                 new Callable<T>() {
                     public T call() throws Exception {
                         setState(StateValue.STARTED);
-                        T ret = doInBackground();
-                        setState(StateValue.DONE);
-                        return ret;
+                        try {
+                            return doInBackground();
+                        } finally {
+                            setState(StateValue.DONE);
+                            doneEDT();
+                        }
                     }
                 };
 
-        future = new FutureTask<T>(callable) {
-                       @Override
-                       protected void done() {
-                           doneEDT();
-                       }
-                   };
+       future = new FutureTask<T>(callable);
        state = StateValue.PENDING;
        propertyChangeSupport = new SwingWorkerPropertyChangeSupport(this);
        doProcess = null;
@@ -566,7 +564,7 @@ public abstract class SwingWorker<T, V> implements RunnableFuture<T> {
      * {@inheritDoc}
      */
     public final boolean isDone() {
-        return future.isDone();
+        return future.isDone() && state == StateValue.DONE;
     }
 
     /**
@@ -753,13 +751,6 @@ public abstract class SwingWorker<T, V> implements RunnableFuture<T> {
         if (SwingUtilities.isEventDispatchThread()) {
             doDone.run();
         } else {
-            if (state != StateValue.DONE) {
-                do {
-                    try {
-                        Thread.sleep(100);
-                    } catch (InterruptedException e) {}
-                } while (state != StateValue.DONE);
-            }
             doSubmit.add(doDone);
         }
     }


or diff to master:

diff --git a/src/java.desktop/share/classes/javax/swing/SwingWorker.java b/src/java.desktop/share/classes/javax/swing/SwingWorker.java
index 0d86075be3f..9da72fe2f0a 100644
--- a/src/java.desktop/share/classes/javax/swing/SwingWorker.java
+++ b/src/java.desktop/share/classes/javax/swing/SwingWorker.java
@@ -301,18 +301,16 @@ public abstract class SwingWorker<T, V> implements RunnableFuture<T> {
                 new Callable<T>() {
                     public T call() throws Exception {
                         setState(StateValue.STARTED);
-                        return doInBackground();
+                        try {
+                            return doInBackground();
+                        } finally {
+                            setState(StateValue.DONE);
+                            doneEDT();
+                        }
                     }
                 };
 
-        future = new FutureTask<T>(callable) {
-                       @Override
-                       protected void done() {
-                           doneEDT();
-                           setState(StateValue.DONE);
-                       }
-                   };
-
+       future = new FutureTask<T>(callable);
        state = StateValue.PENDING;
        propertyChangeSupport = new SwingWorkerPropertyChangeSupport(this);
        doProcess = null;
@@ -566,7 +564,7 @@ public abstract class SwingWorker<T, V> implements RunnableFuture<T> {
      * {@inheritDoc}
      */
     public final boolean isDone() {
-        return future.isDone();
+        return future.isDone() && state == StateValue.DONE;
     }
 
     /**


This approach ensures `cancel` completes quickly and `done` is called only after `doInBackground` exits.

I also suggest adding a condition to the test which verifies `cancel` doesn't take too long as well as ensuring `done` was called before exiting from `main`.

The `isDone` method has the same problem: it returns `true` before the background task has completed, that's why I modified it so that it returns `true` only when the state is `DONE` too.

I believe the time of `sleep` to simulate work can be reduced for automatic testing, however, I agree a few seconds' delay is better for debugging. That's why the time could be configurable in constants.

src/java.desktop/share/classes/javax/swing/SwingWorker.java line 305:

> 303:                         setState(StateValue.STARTED);
> 304:                         T ret = doInBackground();
> 305:                         setState(StateValue.DONE);

What if doInBackground thrown an exception? `DONE` state will never be reached.

src/java.desktop/share/classes/javax/swing/SwingWorker.java line 762:

> 760:                     } catch (InterruptedException e) {}
> 761:                 } while (state != StateValue.DONE);
> 762:             }

In the previous iteration, using `sleep` for waiting was *the concern*, you're still using `sleep`.

This is not going to work because it makes `cancel` wait until `DONE` state is reached, which is not what one would expect, especially taking into account that `cancel` is likely called from EDT to cancel the background operation and blocking EDT is not acceptable.

test/jdk/javax/swing/SwingWorker/TestSwingWorker.java line 32:

> 30: import javax.swing.SwingWorker;
> 31: 
> 32: public class TestSwingWorker {

I believe it was decided to give test classes a meaningful names but `TestSwingWorker` isn't better than `bug8081474`. The latter has an advantage though, it's unique.

`DoneBeforeDoInBackground` seems a better name which describes the test purpose, don't you think?

test/jdk/javax/swing/SwingWorker/TestSwingWorker.java line 47:

> 45:                     }
> 46:                 }
> 47:                 catch (InterruptedException ex) {

Suggestion:

                } catch (InterruptedException ex) {

`catch` should be on the same line as the closing `brace` of the previous block.

-------------

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Sun Jan 29 15:17:17 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sun, 29 Jan 2023 15:17:17 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v3]
In-Reply-To: <I_2nVc_gNBlPUi5YW-ZxxIngM2TBi4Wo-QykDPu2LTE=.5189f52d-a94a-4625-ab7a-6d3ed0885635@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <kkN_fihRAOtPRTzHMmwe4NtWWzaDcZ4wnqCGBJB-r_o=.51f8dfb3-f108-48c0-ae0b-b32bda45ec4f@github.com>
 <I_2nVc_gNBlPUi5YW-ZxxIngM2TBi4Wo-QykDPu2LTE=.5189f52d-a94a-4625-ab7a-6d3ed0885635@github.com>
Message-ID: <-ohGn3FbqfkBX8YV2mLl93gAVcLr3UaPhgnnp8Rylds=.414fa4fd-f39c-4dc0-99f0-d41a02e77c6d@github.com>

On Fri, 27 Jan 2023 05:05:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Should we just update the spec citing it's not necessary to wait for `doInBackground()` to finish before `done()` is called?

It is also an option.

All the suggested approaches set the state to `DONE` before `done` is called now. Yet the Workflow states the following: ?After the `doInBackground` method is finished the `done` method is executed. Then `SwingWorker` notifies any `PropertyChangeListeners` about the state property change to `StateValue.DONE`.?

However, the last sentence may not have been guaranteed before either but it was likely satisfied as `doneEDT` was called before `setState(StateValue.DONE)`. So, `done` had likely been executed before `PropertyChangeListener` was notified.

Hence, a small update to the spec may still be required whatever option we choose.

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From serb at openjdk.org  Sun Jan 29 20:07:23 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 29 Jan 2023 20:07:23 GMT
Subject: Integrated: 8238170: BeanContextSupport remove and propertyChange can
 deadlock
In-Reply-To: <qS_fxqeO2UlPD7Tqkc7Iqe4vYVBn0Az4B328s7uVw_k=.5560c0f8-33e0-4fb5-bd25-08220ff8a8e3@github.com>
References: <qS_fxqeO2UlPD7Tqkc7Iqe4vYVBn0Az4B328s7uVw_k=.5560c0f8-33e0-4fb5-bd25-08220ff8a8e3@github.com>
Message-ID: <wj4CZ4xbFIvFPC8JuSHjKQBmOVk7s25DySsmR5Aj6DU=.5e4d1e90-e7c9-43b5-9909-9af4efb01558@github.com>

On Tue, 24 Jan 2023 03:15:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Two methods in the BeanContextSupport class use two locks in a different order, which can cause a deadlock. 
> 
> Here is the first order: (1) first acquire BeanContext.globalHierarchyLock and then children:
> 
>     enter public method remove(Object) at line 484
>     call remove(Object, boolean) at line 485
>     acquire synchronization on BeanContext.globalHierarchyLock at line 502
>     acquire synchronization on children at line 534
> 
> Here is the second order: (2) first acquire children and then BeanContext.globalHierarchyLock:
> 
>     enter public method propertyChange() at line 1110
>     acquire synchronization on children at line 1114
>     call remove(Object, boolean) at line 1121
>     acquire synchronization on BeanContext.globalHierarchyLock at line 502 
> 
> The fix added the "BeanContext.globalHierarchyLock" before the usage of the "children" lock in the propertyChange method.

This pull request has now been integrated.

Changeset: d4e9f5e5
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4e9f5e5f2c92964c3602f34a59b92947d1595a5
Stats:     158 lines in 3 files changed: 147 ins; 0 del; 11 mod

8238170: BeanContextSupport remove and propertyChange can deadlock

Reviewed-by: phh

-------------

PR: https://git.openjdk.org/jdk/pull/12158


From psadhukhan at openjdk.org  Mon Jan 30 06:56:53 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 30 Jan 2023 06:56:53 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v11]
In-Reply-To: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
Message-ID: <D4hw-DuUlrsUQj1ebXwuyLy9RiNVo-AFgfVVMPYxQHU=.fad33ab6-13ca-435d-a1b4-a86ed4f7cf9d@github.com>

> DefaultListSelectionModel.removeIndexInterva accepts `int` value which allows it to take in Integer.MAX_VALUE theoratically but it does calculation with that value which can results in IOOBE.
> Fix is to make sure the calculation stays within bounds.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10409/files
  - new: https://git.openjdk.org/jdk/pull/10409/files/b1857d3c..da05d20e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10409&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10409&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10409.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10409/head:pull/10409

PR: https://git.openjdk.org/jdk/pull/10409


From psadhukhan at openjdk.org  Mon Jan 30 07:40:22 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 30 Jan 2023 07:40:22 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v12]
In-Reply-To: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
Message-ID: <wLOkBt8E8SvXtdRMQ-n9p9XF9XPILNi6vOXkUdwa59E=.c2813d09-0c7f-4440-ab6f-7614be7990c9@github.com>

> DefaultListSelectionModel.removeIndexInterva accepts `int` value which allows it to take in Integer.MAX_VALUE theoratically but it does calculation with that value which can results in IOOBE.
> Fix is to make sure the calculation stays within bounds.

Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-6187113
 - Update copyright year
 - Review fix
 - Review fix
 - Review fix
 - Review comment fix
 - removeIndexInterval, insertIndexInterval fix
 - insertIndexInterval fix. Add more subtests
 - javadoc update
 - Review comment to exclude MAX_VALUE
 - ... and 5 more: https://git.openjdk.org/jdk/compare/17e00224...eb99ea3b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10409/files
  - new: https://git.openjdk.org/jdk/pull/10409/files/da05d20e..eb99ea3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10409&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10409&range=10-11

  Stats: 487548 lines in 7616 files changed: 244698 ins; 156619 del; 86231 mod
  Patch: https://git.openjdk.org/jdk/pull/10409.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10409/head:pull/10409

PR: https://git.openjdk.org/jdk/pull/10409


From psadhukhan at openjdk.org  Mon Jan 30 07:40:24 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 30 Jan 2023 07:40:24 GMT
Subject: Integrated: 6187113: DefaultListSelectionModel.removeIndexInterval(0, 
 Integer.MAX_VALUE) fails
In-Reply-To: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
Message-ID: <iggr4Tk_6KegyqSH3qG33qbrCnkwf_LgwvomuTNrLyk=.fb851b5b-b5b7-418d-8f8d-4e62ca18af21@github.com>

On Fri, 23 Sep 2022 13:19:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> DefaultListSelectionModel.removeIndexInterva accepts `int` value which allows it to take in Integer.MAX_VALUE theoratically but it does calculation with that value which can results in IOOBE.
> Fix is to make sure the calculation stays within bounds.

This pull request has now been integrated.

Changeset: c2ebd179
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c2ebd179388cac5d6e10f98aab9a7ea909f8bc6b
Stats:     111 lines in 2 files changed: 103 ins; 0 del; 8 mod

6187113: DefaultListSelectionModel.removeIndexInterval(0, Integer.MAX_VALUE) fails

Co-authored-by: Alexey Ivanov <aivanov at openjdk.org>
Reviewed-by: aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/10409


From psadhukhan at openjdk.org  Mon Jan 30 08:37:19 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 30 Jan 2023 08:37:19 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v3]
In-Reply-To: <hCEkbC4GGKOfytfFY1fAAi4cuCoKa1dasJb1p6lGwIo=.ea01e9e1-084e-4db0-a0d3-2cecdf4eec3b@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <kkN_fihRAOtPRTzHMmwe4NtWWzaDcZ4wnqCGBJB-r_o=.51f8dfb3-f108-48c0-ae0b-b32bda45ec4f@github.com>
 <hCEkbC4GGKOfytfFY1fAAi4cuCoKa1dasJb1p6lGwIo=.ea01e9e1-084e-4db0-a0d3-2cecdf4eec3b@github.com>
Message-ID: <f5EQs8jqc97QHBUuB4wkGazE2VqbWYORB-NxqbywRh0=.e3b631fa-2d9d-4880-a42b-75ead935fd08@github.com>

On Sun, 29 Jan 2023 14:32:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove blocking thread sleep for EDT
>
> src/java.desktop/share/classes/javax/swing/SwingWorker.java line 762:
> 
>> 760:                     } catch (InterruptedException e) {}
>> 761:                 } while (state != StateValue.DONE);
>> 762:             }
> 
> In the previous iteration, using `sleep` for waiting was *the concern*, you're still using `sleep`.
> 
> This is not going to work because it makes `cancel` wait until `DONE` state is reached, which is not what one would expect, especially taking into account that `cancel` is likely called from EDT to cancel the background operation and blocking EDT is not acceptable.

I removed sleep from EDT case and not blocking EDT and guess sleep is now being done for non-EDT case...
If it is to be called from EDT then it should go to "if" block and not to "else" which is what I based my fix on..

Anyway, I appreciate your fix and will see to it..

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Mon Jan 30 09:52:19 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 30 Jan 2023 09:52:19 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v3]
In-Reply-To: <F5rc9C6Tmfg97QGHmygzARQD0WWwulxsVXWp9x0s38U=.2681ab7b-c858-496e-9016-1f8cb00f6125@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <F5rc9C6Tmfg97QGHmygzARQD0WWwulxsVXWp9x0s38U=.2681ab7b-c858-496e-9016-1f8cb00f6125@github.com>
Message-ID: <amqYhEJ1zCy_R2Jfnalee2A1BPRXQzY1kxTb1v5VcMA=.54efd7ae-0cc3-4272-bd0b-562ef7cff151@github.com>

On Fri, 27 Jan 2023 20:22:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
>> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
>> So deprecating - for removal - and adding warnings now in the docs is appropriate.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300891

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java line 637:

> 635:      * @since 1.6
> 636:      * @deprecated Use {@link load(InputStream, Class)} or
> 637:      * {@link setStyleFactory} instead

The link to setStyleFactory was used like "{@link #setStyleFactory}" earlier
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java#L77

shouldn't we keep it same?

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From aivanov at openjdk.org  Mon Jan 30 09:53:20 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 30 Jan 2023 09:53:20 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v3]
In-Reply-To: <f5EQs8jqc97QHBUuB4wkGazE2VqbWYORB-NxqbywRh0=.e3b631fa-2d9d-4880-a42b-75ead935fd08@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <kkN_fihRAOtPRTzHMmwe4NtWWzaDcZ4wnqCGBJB-r_o=.51f8dfb3-f108-48c0-ae0b-b32bda45ec4f@github.com>
 <hCEkbC4GGKOfytfFY1fAAi4cuCoKa1dasJb1p6lGwIo=.ea01e9e1-084e-4db0-a0d3-2cecdf4eec3b@github.com>
 <f5EQs8jqc97QHBUuB4wkGazE2VqbWYORB-NxqbywRh0=.e3b631fa-2d9d-4880-a42b-75ead935fd08@github.com>
Message-ID: <goObx40wfIwqroukX3_X7H0ccahEtSB1dgygLn5bDvE=.4a6645fb-e8cd-4608-abf1-99e63f1c1141@github.com>

On Mon, 30 Jan 2023 08:34:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/SwingWorker.java line 762:
>> 
>>> 760:                     } catch (InterruptedException e) {}
>>> 761:                 } while (state != StateValue.DONE);
>>> 762:             }
>> 
>> In the previous iteration, using `sleep` for waiting was *the concern*, you're still using `sleep`.
>> 
>> This is not going to work because it makes `cancel` wait until `DONE` state is reached, which is not what one would expect, especially taking into account that `cancel` is likely called from EDT to cancel the background operation and blocking EDT is not acceptable.
>
> I removed sleep from EDT case and not blocking EDT and guess sleep is now being done for non-EDT case...
> If it is to be called from EDT then it should go to "if" block and not to "else" which is what I based my fix on..
> 
> Anyway, I appreciate your fix and will see to it..

Yet having `sleep` is an indication of busy wait. You could've used `CountDownLatch` in conjunction with `setState` to avoid `sleep` at all.

> I removed sleep from EDT case and not blocking EDT and guess sleep is now being done for non-EDT case...

Ah, right. But then if `cancel` is called on EDT, `done` is invoked before `doInBackground` completes, isn't it?

If `cancel` is called from another thread, the main thread as in the test, it doesn't return until `doInBackground` completes. With your test case and fix, `cancel` blocks for 5 seconds.

Either way, the behaviour does not look right.

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From aturbanov at openjdk.org  Mon Jan 30 12:01:10 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 30 Jan 2023 12:01:10 GMT
Subject: RFR: 8301342: Prefer ArrayList to LinkedList in LayoutComparator
Message-ID: <Lb8r9AULVVdbUx9R8NUUYB9BGHYgi9uKU36pmeo42_E=.422d3284-5ab0-484d-8544-e25b8a63ae03@github.com>

There is only add/iterator calls on this list. No removes from the head or something like this. Not sure why LinkedList was used, but ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

-------------

Commit messages:
 - [PATCH] Prefer ArrayList to LinkedList in LayoutComparator

Changes: https://git.openjdk.org/jdk/pull/12274/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12274&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301342
  Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12274.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12274/head:pull/12274

PR: https://git.openjdk.org/jdk/pull/12274


From duke at openjdk.org  Mon Jan 30 12:01:11 2023
From: duke at openjdk.org (SWinxy)
Date: Mon, 30 Jan 2023 12:01:11 GMT
Subject: RFR: 8301342: Prefer ArrayList to LinkedList in LayoutComparator
In-Reply-To: <Lb8r9AULVVdbUx9R8NUUYB9BGHYgi9uKU36pmeo42_E=.422d3284-5ab0-484d-8544-e25b8a63ae03@github.com>
References: <Lb8r9AULVVdbUx9R8NUUYB9BGHYgi9uKU36pmeo42_E=.422d3284-5ab0-484d-8544-e25b8a63ae03@github.com>
Message-ID: <CtmtGdKACMZ_O52DzBuuvzWN-y612Zp0UYhx4TQylac=.bc34df67-4cc2-457c-959f-9eeb1f484a08@github.com>

On Sat, 28 Jan 2023 14:54:38 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is only add/iterator calls on this list. No removes from the head or something like this. Not sure why LinkedList was used, but ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

Personal preference is that the variables are typed as `List<T> xyz = new ArrayList<>();`.

-------------

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

PR: https://git.openjdk.org/jdk/pull/12274


From tr at openjdk.org  Mon Jan 30 15:05:55 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 30 Jan 2023 15:05:55 GMT
Subject: RFR: 8300549: JFileChooser Approve button tooltip is null in Aqua
 L&F in CUSTOM_DIALOG mode [v2]
In-Reply-To: <IPLzXe7hJxn5KukI-eFxqO1CJNDO_g70pUBOlwLewIA=.68dd5394-541a-4096-8dce-99f2b6156b0d@github.com>
References: <IPLzXe7hJxn5KukI-eFxqO1CJNDO_g70pUBOlwLewIA=.68dd5394-541a-4096-8dce-99f2b6156b0d@github.com>
Message-ID: <VIAJ0-tM7BIjE5c-8vG8IfDOnMKZ-IWuExfyZPIizj4=.31771e62-e83d-4daa-a964-a55a9a1b4838@github.com>

> _JFilechooser_ returns _null_ for Approve button tool tip in `CUSTOM_DIALOG` mode (`getToolTipText()`). The fallback text has been set to "Choose" text. Observation found in validating the test of PR - #11901.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Property added

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12198/files
  - new: https://git.openjdk.org/jdk/pull/12198/files/8a23cb04..93b02724

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12198&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12198&range=00-01

  Stats: 6 lines in 2 files changed: 3 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12198.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12198/head:pull/12198

PR: https://git.openjdk.org/jdk/pull/12198


From prr at openjdk.org  Mon Jan 30 18:18:19 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 30 Jan 2023 18:18:19 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v3]
In-Reply-To: <amqYhEJ1zCy_R2Jfnalee2A1BPRXQzY1kxTb1v5VcMA=.54efd7ae-0cc3-4272-bd0b-562ef7cff151@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <F5rc9C6Tmfg97QGHmygzARQD0WWwulxsVXWp9x0s38U=.2681ab7b-c858-496e-9016-1f8cb00f6125@github.com>
 <amqYhEJ1zCy_R2Jfnalee2A1BPRXQzY1kxTb1v5VcMA=.54efd7ae-0cc3-4272-bd0b-562ef7cff151@github.com>
Message-ID: <kmqkLvDPzL983a7xIRJx4AGudqID1rFe8_R_OYRJlBE=.e4f20d59-3e03-4d02-b28a-7609d2a2c059@github.com>

On Mon, 30 Jan 2023 09:49:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8300891
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java line 637:
> 
>> 635:      * @since 1.6
>> 636:      * @deprecated Use {@link load(InputStream, Class)} or
>> 637:      * {@link setStyleFactory} instead
> 
> The link to setStyleFactory was used like "{@link #setStyleFactory}" earlier
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java#L77
> 
> shouldn't we keep it same?

where was this ? And why ? This works just fine.

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From jwilhelm at openjdk.org  Mon Jan 30 19:32:20 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 30 Jan 2023 19:32:20 GMT
Subject: RFR: Merge jdk20
Message-ID: <T5ev_OTtbxp7gbv2cv3Hyh479l2FS8yi0e-mx_HtPP8=.a776a713-cb3d-471f-bb32-c9ad8e88bb04@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8300269: The selected item in an editable JComboBox with titled border is not visible in Aqua LAF

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/12299/files
  Stats: 184 lines in 2 files changed: 183 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12299.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12299/head:pull/12299

PR: https://git.openjdk.org/jdk/pull/12299


From jwilhelm at openjdk.org  Mon Jan 30 20:57:08 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 30 Jan 2023 20:57:08 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <T5ev_OTtbxp7gbv2cv3Hyh479l2FS8yi0e-mx_HtPP8=.a776a713-cb3d-471f-bb32-c9ad8e88bb04@github.com>
References: <T5ev_OTtbxp7gbv2cv3Hyh479l2FS8yi0e-mx_HtPP8=.a776a713-cb3d-471f-bb32-c9ad8e88bb04@github.com>
Message-ID: <22jjdTpQrdm5moXeb24inXNINRq0xotkTmsXqVUejcs=.1627d418-44bf-41f9-bde9-7c8b19cb4dee@github.com>

On Mon, 30 Jan 2023 19:26:27 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 561a25e0
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/561a25e0250fde55eb0af7beb5dc064ef8321f9e
Stats:     184 lines in 2 files changed: 183 ins; 0 del; 1 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/12299


From prr at openjdk.org  Mon Jan 30 22:38:56 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 30 Jan 2023 22:38:56 GMT
Subject: RFR: 8301254: UNIX sun/font coding does not detect SuSE in
 openSUSE Leap distributive [v2]
In-Reply-To: <sU7oZqE6FU5biu3MNOA_zwKmYotbMX7edfWdKDHqggA=.51de7d26-db67-4cf8-a8ca-75a0e1c20b53@github.com>
References: <mT0PlFG6VxvcXjvjQjrvJLQqsHHLhB2aM74PzA_vDo8=.2759eb4a-97f7-4c9d-8806-08791f824c6c@github.com>
 <sU7oZqE6FU5biu3MNOA_zwKmYotbMX7edfWdKDHqggA=.51de7d26-db67-4cf8-a8ca-75a0e1c20b53@github.com>
Message-ID: <iaaA8J_u9cCeYOqu7Ga4wXWymgu9R1Nfslpm8kJdnFA=.2d9ec3b4-2042-4086-82eb-27d7a4aa545c@github.com>

On Fri, 27 Jan 2023 17:00:48 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> [JDK-8278549](https://bugs.openjdk.org/browse/JDK-8278549)` UNIX sun/font coding misses SUSE distro detection on recent distro SUSE 15` adds SuSE detection by checking SLES os name property in `/etc/os-release` file.
>> 
>> `opensuse/leap:15.4` docker defines os name property as `"openSUSE Leap"` in `/etc/os-release` file which is not recognized as SuSE.
>> 
>> The issue is reproduced with Oracle jdk-19.0.2 with custom fontconfig.SuSE.properties file copied to jdk-19.0.2/lib directory.
>> 
>> The fix checks if os name property from  `/etc/os-release` contains `SUSE`  substring.
>> 
>> Steps to reproduce.
>> - Download Oracle jdk-19.0.2
>> - Copy custom [fontconfig.SuSE.properties](https://bugs.openjdk.org/secure/attachment/102435/fontconfig.SuSE.properties) file to jdk-19.0.2/lib directory.
>> - Run the `opensuse/leap:15.4` docker and install freetype and dejavu fonts (do not install fontconfig)
>> 
>> docker run --rm --security-opt seccomp=unconfined -it opensuse/leap:15.4 bash
>> zypper install -y dejavu-fonts
>> zypper install -y freetype2
>> 
>> - Run HelloImage java sample in the docker
>> 
>> import javax.imageio.ImageIO;
>> import java.awt.*;
>> import java.awt.image.BufferedImage;
>> import java.io.File;
>> 
>> public class HelloImage {
>> 
>>     public static void main(String[] args) throws Exception {
>> 
>>         BufferedImage buff = new BufferedImage(300, 200, BufferedImage.TYPE_INT_RGB);
>>         Graphics2D g = buff.createGraphics();
>>         g.setColor(Color.WHITE);
>>         g.fillRect(0, 0, buff.getWidth(), buff.getHeight());
>> 
>>         g.setColor(Color.BLUE);
>>         g.setFont(g.getFont().deriveFont(32f));
>>         g.drawString("Hello, Image!", 50, 50);
>>         g.dispose();
>> 
>>         File file = new File("hello-image.png");
>>         ImageIO.write(buff, "png", file);
>>     }
>> }
>> 
>> 
>> 
>> ./jdk-19.0.2/bin/javac HelloImage.java
>> ./jdk-19.0.2/bin/java HelloImage
>> 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:1261)
>> 	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:706)
>> 	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:318)
>> 	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:56)
>> 	at java.desktop/sun.font.PlatformFontInfo.createFontManager(PlatformFontInfo.java:37)
>> 	at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:51)
>> 	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:151)
>> 	at java.desktop/sun.java2d.SunGraphics2D.checkFontInfo(SunGraphics2D.java:671)
>> 	at java.desktop/sun.java2d.SunGraphics2D.getFontInfo(SunGraphics2D.java:837)
>> 	at java.desktop/sun.java2d.pipe.GlyphListPipe.drawString(GlyphListPipe.java:46)
>> 	at java.desktop/sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2931)
>> 	at HelloImage.main(HelloImage.java:17)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert back empty line removing

it is distribution not distributive.

And I made a suggestion in the bug that what I'd prefer to see is that
this be done by parsing the /etc/release and using the exact name there rather
than remapping it.
This means fontconfig files would need to use SLES in the name not SuSE but
that seems a small price to pay for not having to keep editing OpenJDK code.

-------------

PR: https://git.openjdk.org/jdk/pull/12260


From prr at openjdk.org  Mon Jan 30 22:56:55 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 30 Jan 2023 22:56:55 GMT
Subject: RFR: 8301342: Prefer ArrayList to LinkedList in LayoutComparator
In-Reply-To: <Lb8r9AULVVdbUx9R8NUUYB9BGHYgi9uKU36pmeo42_E=.422d3284-5ab0-484d-8544-e25b8a63ae03@github.com>
References: <Lb8r9AULVVdbUx9R8NUUYB9BGHYgi9uKU36pmeo42_E=.422d3284-5ab0-484d-8544-e25b8a63ae03@github.com>
Message-ID: <8mxsL5sZVj66_mFw2EQZSZcJwKmr3vWqa58NyBXGObI=.b9099660-a7e3-4d41-85dd-be459480392b@github.com>

On Sat, 28 Jan 2023 14:54:38 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is only add/iterator calls on this list. No removes from the head or something like this. Not sure why LinkedList was used, but ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

I expect some testing to be done before it is pushed.

This looks safe but  I rather doubt anyone will be able to measure or ever see any performance benefit.
I suggest some manual testing of focus traversal which seems to be the sole user of the containing class.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12274


From achung at openjdk.org  Mon Jan 30 23:19:35 2023
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 30 Jan 2023 23:19:35 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v4]
In-Reply-To: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
Message-ID: <faAg_l3mXZDdEBAJHX4vR966zDgWXgEaTZsISNZtUeY=.f2f11807-9105-47b5-bc93-9f82f24e974e@github.com>

> Fixed test bug where mouse location was being calculated before robot mouseMove operation was complete

Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into 8292588/MultiScreenLocationTest
 - added debug statements
 - re-test
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8292588/MultiScreenLocationTest
 - added robot wait to prevent mouse position from being calculated before robot finishes mouseMove

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10363/files
  - new: https://git.openjdk.org/jdk/pull/10363/files/4c8b373a..ef1e22e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10363&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10363&range=02-03

  Stats: 23599 lines in 1139 files changed: 6709 ins; 4749 del; 12141 mod
  Patch: https://git.openjdk.org/jdk/pull/10363.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10363/head:pull/10363

PR: https://git.openjdk.org/jdk/pull/10363


From nikita.provotorov at jetbrains.com  Tue Jan 31 00:30:43 2023
From: nikita.provotorov at jetbrains.com (Nikita Provotorov)
Date: Tue, 31 Jan 2023 02:30:43 +0200
Subject: How to find all keyboard-related manual tests?
Message-ID: <CAMTdVeoT047Z7FKRUEtuSoLr67_1MRSniK-Jo_3rkYD2H3BGFQ@mail.gmail.com>

Hello! I'm trying to figure out how to find all *manual* tests which
verifies behavior of keyboards, e.g. the following cases:
* "Regular" text input
* Dead keys handling
* Input methods handling
* Shortcuts support

AFAIU it's easy enough to find all manual tests via just grepping of all
sources by the "/manual" substring. The next thing I've tried is to find
all usages of the class *java.awt.event.KeyEvent* among all found "/manual"
entries. But I believe it won't give me a complete list of such tests.

Could anyone advise anything?

Best regards,
Nikita Provotorov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230131/51d08880/attachment.htm>

From psadhukhan at openjdk.org  Tue Jan 31 03:37:57 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 31 Jan 2023 03:37:57 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v3]
In-Reply-To: <kmqkLvDPzL983a7xIRJx4AGudqID1rFe8_R_OYRJlBE=.e4f20d59-3e03-4d02-b28a-7609d2a2c059@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <F5rc9C6Tmfg97QGHmygzARQD0WWwulxsVXWp9x0s38U=.2681ab7b-c858-496e-9016-1f8cb00f6125@github.com>
 <amqYhEJ1zCy_R2Jfnalee2A1BPRXQzY1kxTb1v5VcMA=.54efd7ae-0cc3-4272-bd0b-562ef7cff151@github.com>
 <kmqkLvDPzL983a7xIRJx4AGudqID1rFe8_R_OYRJlBE=.e4f20d59-3e03-4d02-b28a-7609d2a2c059@github.com>
Message-ID: <7G-aYEgRO-2FkFFXEolBPttgBs98iYbnD8YDs-lGSwc=.acb7f614-bc2e-458d-a095-d323e85639ea@github.com>

On Mon, 30 Jan 2023 18:15:05 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java line 637:
>> 
>>> 635:      * @since 1.6
>>> 636:      * @deprecated Use {@link load(InputStream, Class)} or
>>> 637:      * {@link setStyleFactory} instead
>> 
>> The link to setStyleFactory was used like "{@link #setStyleFactory}" earlier
>> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java#L77
>> 
>> shouldn't we keep it same?
>
> where was this ? And why ? This works just fine.

I guess there's different ways but AFAIS, java.desktop javadocs use 
"@link xxx to link to a class
and "@link #xxx" to link to a field, constant or method in a class

for example, in SYnthLookAndFeel class only, we have this 
_{@link #load} method, or provide your own {@link SynthStyleFactory}
  to {@link #setStyleFactory}_

ANother example 

java/awt/Color.java:     * Throws an {@link IllegalArgumentException} if the value is out of
java/awt/Color.java:     * {@link ColorModel}.
java/awt/Color.java:     * format used by the method {@link #getRGB() getRGB}.


and here setStyleFactory is a method, so I asked...

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From psadhukhan at openjdk.org  Tue Jan 31 05:57:31 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 31 Jan 2023 05:57:31 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v4]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <7WbqymBEDIn5Hoh5KDoFHmFLQMJA3JTkUlpFzu39NaY=.26f3e13d-2b4e-4a93-9103-d606d176e58b@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix and test updated

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/4f59bfa4..c34d55b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=02-03

  Stats: 26 lines in 2 files changed: 3 ins; 15 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/11940.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11940/head:pull/11940

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Tue Jan 31 05:58:56 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 31 Jan 2023 05:58:56 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v3]
In-Reply-To: <goObx40wfIwqroukX3_X7H0ccahEtSB1dgygLn5bDvE=.4a6645fb-e8cd-4608-abf1-99e63f1c1141@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <kkN_fihRAOtPRTzHMmwe4NtWWzaDcZ4wnqCGBJB-r_o=.51f8dfb3-f108-48c0-ae0b-b32bda45ec4f@github.com>
 <hCEkbC4GGKOfytfFY1fAAi4cuCoKa1dasJb1p6lGwIo=.ea01e9e1-084e-4db0-a0d3-2cecdf4eec3b@github.com>
 <f5EQs8jqc97QHBUuB4wkGazE2VqbWYORB-NxqbywRh0=.e3b631fa-2d9d-4880-a42b-75ead935fd08@github.com>
 <goObx40wfIwqroukX3_X7H0ccahEtSB1dgygLn5bDvE=.4a6645fb-e8cd-4608-abf1-99e63f1c1141@github.com>
Message-ID: <S9-eV_HuugtZAkr48TtCImO-7AUF1anW0PnrqmXn_Ho=.4f61156e-57e5-4e5a-901a-70a74fa8ceaf@github.com>

On Mon, 30 Jan 2023 09:50:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I removed sleep from EDT case and not blocking EDT and guess sleep is now being done for non-EDT case...
>> If it is to be called from EDT then it should go to "if" block and not to "else" which is what I based my fix on..
>> 
>> Anyway, I appreciate your fix and will see to it..
>
> Yet having `sleep` is an indication of busy wait. You could've used `CountDownLatch` in conjunction with `setState` to avoid `sleep` at all.
> 
>> I removed sleep from EDT case and not blocking EDT and guess sleep is now being done for non-EDT case...
> 
> Ah, right. But then if `cancel` is called on EDT, `done` is invoked before `doInBackground` completes, isn't it?
> 
> If `cancel` is called from another thread, the main thread as in the test, it doesn't return until `doInBackground` completes. With your test case and fix, `cancel` blocks for 5 seconds.
> 
> Either way, the behaviour does not look right.

It seems the isDone method modification is causing a JCK test to fail and there's no spec for it to challenge JCK test, although logically it seems right that STATE should be DONE but for now, I have modified the fix which satisfies regression test and JCK both..

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From jwaters at openjdk.org  Tue Jan 31 06:36:42 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 31 Jan 2023 06:36:42 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code
Message-ID: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>

Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

-------------

Commit messages:
 - Partial Revert
 - sspi.cpp
 - Comments

Changes: https://git.openjdk.org/jdk/pull/12305/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12305&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301443
  Stats: 13 lines in 11 files changed: 0 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12305.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12305/head:pull/12305

PR: https://git.openjdk.org/jdk/pull/12305


From aturbanov at openjdk.org  Tue Jan 31 06:55:57 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 31 Jan 2023 06:55:57 GMT
Subject: RFR: 6817009: Action.SELECTED_KEY not toggled when using key
 binding
In-Reply-To: <DYsG8pG_MZQAuC3hOVqpwSoge8qrhCCZ-8GzuTVEmq0=.44e519dc-c56a-4b95-91c9-377a88bd0795@github.com>
References: <DYsG8pG_MZQAuC3hOVqpwSoge8qrhCCZ-8GzuTVEmq0=.44e519dc-c56a-4b95-91c9-377a88bd0795@github.com>
Message-ID: <WoMZy2rfrAQkUSqdcMlAsBahGE0kqkprGRInpuVeNpY=.ffef5b9d-252e-4c70-ab46-4694bcc897f6@github.com>

On Fri, 27 Jan 2023 10:26:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When the Action.SELECTED_KEY property action is assigned to ToggleButton and an accelerator key binding is mapped to the action, then pressing the accelerator key binding does not toggle the toggle button.
> This is because SwingUtilities.notifyAction does not fire itemStateChanged event for such action related to SELECTED_KEY.
> Fix is to get the Action.SELECTED_KEY command/action and fire itemStateChanged Event via JToggleButton.setSelected() call to notify propertyChange listener of the toggled property.

test/jdk/javax/swing/JToggleButton/TestSelectedKey.java line 96:

> 94:         action.addPropertyChangeListener(new PropertyChangeListener() {
> 95:             public void propertyChange(PropertyChangeEvent evt) {
> 96:                 if(Action.SELECTED_KEY.equals(evt.getPropertyName())) {

Suggestion:

                if (Action.SELECTED_KEY.equals(evt.getPropertyName())) {

-------------

PR: https://git.openjdk.org/jdk/pull/12253


From jwaters at openjdk.org  Tue Jan 31 07:01:57 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 31 Jan 2023 07:01:57 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code
In-Reply-To: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
Message-ID: <L7MKQlWUBi4ab22ZD56GLRhdPeEUGVcSTFRkz3cRKZc=.ed8edde6-1e26-47fe-a4e3-084ba5806445@github.com>

On Tue, 31 Jan 2023 06:28:21 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

@wangweij Sorry for the abrupt tag, but would the sspi.cpp change be fine with you? It seems like the comment is intended to signal a newline so the compile command's second half on the next line is read properly, but Visual C++ will simply interpret it as the object file \.o, which isn't correct, but I don't quite know the context behind that comment so I thought I'd ask first (On top of the fact that cmd doesn't allow newline formatted commands at all)

-------------

PR: https://git.openjdk.org/jdk/pull/12305


From alexsch at openjdk.org  Tue Jan 31 08:53:57 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Tue, 31 Jan 2023 08:53:57 GMT
Subject: RFR: 8301254: UNIX sun/font coding does not detect SuSE in
 openSUSE Leap distribution [v2]
In-Reply-To: <sU7oZqE6FU5biu3MNOA_zwKmYotbMX7edfWdKDHqggA=.51de7d26-db67-4cf8-a8ca-75a0e1c20b53@github.com>
References: <mT0PlFG6VxvcXjvjQjrvJLQqsHHLhB2aM74PzA_vDo8=.2759eb4a-97f7-4c9d-8806-08791f824c6c@github.com>
 <sU7oZqE6FU5biu3MNOA_zwKmYotbMX7edfWdKDHqggA=.51de7d26-db67-4cf8-a8ca-75a0e1c20b53@github.com>
Message-ID: <MFSXt2erBnMw2-_EUuBN7No7-YfWg5sZCFt9HE3gHqc=.cb0a995f-b0fd-4616-9d5d-d30e4c71cd0e@github.com>

On Fri, 27 Jan 2023 17:00:48 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> [JDK-8278549](https://bugs.openjdk.org/browse/JDK-8278549)` UNIX sun/font coding misses SUSE distro detection on recent distro SUSE 15` adds SuSE detection by checking SLES os name property in `/etc/os-release` file.
>> 
>> `opensuse/leap:15.4` docker defines os name property as `"openSUSE Leap"` in `/etc/os-release` file which is not recognized as SuSE.
>> 
>> The issue is reproduced with Oracle jdk-19.0.2 with custom fontconfig.SuSE.properties file copied to jdk-19.0.2/lib directory.
>> 
>> The fix checks if os name property from  `/etc/os-release` contains `SUSE`  substring.
>> 
>> Steps to reproduce.
>> - Download Oracle jdk-19.0.2
>> - Copy custom [fontconfig.SuSE.properties](https://bugs.openjdk.org/secure/attachment/102435/fontconfig.SuSE.properties) file to jdk-19.0.2/lib directory.
>> - Run the `opensuse/leap:15.4` docker and install freetype and dejavu fonts (do not install fontconfig)
>> 
>> docker run --rm --security-opt seccomp=unconfined -it opensuse/leap:15.4 bash
>> zypper install -y dejavu-fonts
>> zypper install -y freetype2
>> 
>> - Run HelloImage java sample in the docker
>> 
>> import javax.imageio.ImageIO;
>> import java.awt.*;
>> import java.awt.image.BufferedImage;
>> import java.io.File;
>> 
>> public class HelloImage {
>> 
>>     public static void main(String[] args) throws Exception {
>> 
>>         BufferedImage buff = new BufferedImage(300, 200, BufferedImage.TYPE_INT_RGB);
>>         Graphics2D g = buff.createGraphics();
>>         g.setColor(Color.WHITE);
>>         g.fillRect(0, 0, buff.getWidth(), buff.getHeight());
>> 
>>         g.setColor(Color.BLUE);
>>         g.setFont(g.getFont().deriveFont(32f));
>>         g.drawString("Hello, Image!", 50, 50);
>>         g.dispose();
>> 
>>         File file = new File("hello-image.png");
>>         ImageIO.write(buff, "png", file);
>>     }
>> }
>> 
>> 
>> 
>> ./jdk-19.0.2/bin/javac HelloImage.java
>> ./jdk-19.0.2/bin/java HelloImage
>> 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:1261)
>> 	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:706)
>> 	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:318)
>> 	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:56)
>> 	at java.desktop/sun.font.PlatformFontInfo.createFontManager(PlatformFontInfo.java:37)
>> 	at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:51)
>> 	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:151)
>> 	at java.desktop/sun.java2d.SunGraphics2D.checkFontInfo(SunGraphics2D.java:671)
>> 	at java.desktop/sun.java2d.SunGraphics2D.getFontInfo(SunGraphics2D.java:837)
>> 	at java.desktop/sun.java2d.pipe.GlyphListPipe.drawString(GlyphListPipe.java:46)
>> 	at java.desktop/sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2931)
>> 	at HelloImage.main(HelloImage.java:17)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert back empty line removing

A table with ID and Name values for some docker images:
|  Docker image | ID  |NAME   | 
|---|---|---|
| opensuse/leap:15.4  | opensuse-leap  | openSUSE Leap  | 
|  opensuse/tumbleweed | opensuse-tumbleweed  |  openSUSE Tumbleweed | 
| fedora:35  | fedora  | Fedora Linux  |   
| ubuntu:20.04 | ubuntu  |  Ubuntu | 
|  photon:4.0 |   photon|   VMware Photon OS|  
| archlinux  | arch  |  Arch Linux | 
| centos:8  | centos  |  CentOS Linux | 
|  alpine:3.17 |  alpine |  Alpine Linux |

-------------

PR: https://git.openjdk.org/jdk/pull/12260


From psadhukhan at openjdk.org  Tue Jan 31 08:54:39 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 31 Jan 2023 08:54:39 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v5]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <wuP70-tBQIFqdbSibzsr2EdPBgjQPNDLfIkFxiWC6KI=.e46bd69a-6449-4b36-8592-741f93bd4cc2@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Set DONE state for cancel

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/c34d55b9..5d723a78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=03-04

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11940.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11940/head:pull/11940

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Tue Jan 31 08:54:39 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 31 Jan 2023 08:54:39 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v3]
In-Reply-To: <S9-eV_HuugtZAkr48TtCImO-7AUF1anW0PnrqmXn_Ho=.4f61156e-57e5-4e5a-901a-70a74fa8ceaf@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <kkN_fihRAOtPRTzHMmwe4NtWWzaDcZ4wnqCGBJB-r_o=.51f8dfb3-f108-48c0-ae0b-b32bda45ec4f@github.com>
 <hCEkbC4GGKOfytfFY1fAAi4cuCoKa1dasJb1p6lGwIo=.ea01e9e1-084e-4db0-a0d3-2cecdf4eec3b@github.com>
 <f5EQs8jqc97QHBUuB4wkGazE2VqbWYORB-NxqbywRh0=.e3b631fa-2d9d-4880-a42b-75ead935fd08@github.com>
 <goObx40wfIwqroukX3_X7H0ccahEtSB1dgygLn5bDvE=.4a6645fb-e8cd-4608-abf1-99e63f1c1141@github.com>
 <S9-eV_HuugtZAkr48TtCImO-7AUF1anW0PnrqmXn_Ho=.4f61156e-57e5-4e5a-901a-70a74fa8ceaf@github.com>
Message-ID: <NwENeUfPamY810Eg3HVFVSzUhBOnfrYV1D4IL5IvOJg=.9f5cbaab-ca1c-4ddf-97f1-ae611629f1e9@github.com>

On Tue, 31 Jan 2023 05:56:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Yet having `sleep` is an indication of busy wait. You could've used `CountDownLatch` in conjunction with `setState` to avoid `sleep` at all.
>> 
>>> I removed sleep from EDT case and not blocking EDT and guess sleep is now being done for non-EDT case...
>> 
>> Ah, right. But then if `cancel` is called on EDT, `done` is invoked before `doInBackground` completes, isn't it?
>> 
>> If `cancel` is called from another thread, the main thread as in the test, it doesn't return until `doInBackground` completes. With your test case and fix, `cancel` blocks for 5 seconds.
>> 
>> Either way, the behaviour does not look right.
>
> It seems the isDone method modification is causing a JCK test to fail and there's no spec for it to challenge JCK test, although logically it seems right that STATE should be DONE but for now, I have modified the fix which satisfies regression test and JCK both..

isDone() spec mention `"Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true"`
so for cancel state also, the state needs to be in DONE state, in which case we can reinstate the DONE state check in isDone()

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From alexsch at openjdk.org  Tue Jan 31 09:19:58 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Tue, 31 Jan 2023 09:19:58 GMT
Subject: RFR: 8301254: UNIX sun/font coding does not detect SuSE in
 openSUSE Leap distribution [v2]
In-Reply-To: <sU7oZqE6FU5biu3MNOA_zwKmYotbMX7edfWdKDHqggA=.51de7d26-db67-4cf8-a8ca-75a0e1c20b53@github.com>
References: <mT0PlFG6VxvcXjvjQjrvJLQqsHHLhB2aM74PzA_vDo8=.2759eb4a-97f7-4c9d-8806-08791f824c6c@github.com>
 <sU7oZqE6FU5biu3MNOA_zwKmYotbMX7edfWdKDHqggA=.51de7d26-db67-4cf8-a8ca-75a0e1c20b53@github.com>
Message-ID: <q7zUAd1YMLSiJR2XPrKXMWOY9uJLnPhx9xYkYih6C5k=.2dddb068-a973-439f-b401-645605b91725@github.com>

On Fri, 27 Jan 2023 17:00:48 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> [JDK-8278549](https://bugs.openjdk.org/browse/JDK-8278549)` UNIX sun/font coding misses SUSE distro detection on recent distro SUSE 15` adds SuSE detection by checking SLES os name property in `/etc/os-release` file.
>> 
>> `opensuse/leap:15.4` docker defines os name property as `"openSUSE Leap"` in `/etc/os-release` file which is not recognized as SuSE.
>> 
>> The issue is reproduced with Oracle jdk-19.0.2 with custom fontconfig.SuSE.properties file copied to jdk-19.0.2/lib directory.
>> 
>> The fix checks if os name property from  `/etc/os-release` contains `SUSE`  substring.
>> 
>> Steps to reproduce.
>> - Download Oracle jdk-19.0.2
>> - Copy custom [fontconfig.SuSE.properties](https://bugs.openjdk.org/secure/attachment/102435/fontconfig.SuSE.properties) file to jdk-19.0.2/lib directory.
>> - Run the `opensuse/leap:15.4` docker and install freetype and dejavu fonts (do not install fontconfig)
>> 
>> docker run --rm --security-opt seccomp=unconfined -it opensuse/leap:15.4 bash
>> zypper install -y dejavu-fonts
>> zypper install -y freetype2
>> 
>> - Run HelloImage java sample in the docker
>> 
>> import javax.imageio.ImageIO;
>> import java.awt.*;
>> import java.awt.image.BufferedImage;
>> import java.io.File;
>> 
>> public class HelloImage {
>> 
>>     public static void main(String[] args) throws Exception {
>> 
>>         BufferedImage buff = new BufferedImage(300, 200, BufferedImage.TYPE_INT_RGB);
>>         Graphics2D g = buff.createGraphics();
>>         g.setColor(Color.WHITE);
>>         g.fillRect(0, 0, buff.getWidth(), buff.getHeight());
>> 
>>         g.setColor(Color.BLUE);
>>         g.setFont(g.getFont().deriveFont(32f));
>>         g.drawString("Hello, Image!", 50, 50);
>>         g.dispose();
>> 
>>         File file = new File("hello-image.png");
>>         ImageIO.write(buff, "png", file);
>>     }
>> }
>> 
>> 
>> 
>> ./jdk-19.0.2/bin/javac HelloImage.java
>> ./jdk-19.0.2/bin/java HelloImage
>> 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:1261)
>> 	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:706)
>> 	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:318)
>> 	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:56)
>> 	at java.desktop/sun.font.PlatformFontInfo.createFontManager(PlatformFontInfo.java:37)
>> 	at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:51)
>> 	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:151)
>> 	at java.desktop/sun.java2d.SunGraphics2D.checkFontInfo(SunGraphics2D.java:671)
>> 	at java.desktop/sun.java2d.SunGraphics2D.getFontInfo(SunGraphics2D.java:837)
>> 	at java.desktop/sun.java2d.pipe.GlyphListPipe.drawString(GlyphListPipe.java:46)
>> 	at java.desktop/sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2931)
>> 	at HelloImage.main(HelloImage.java:17)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert back empty line removing

May be it has sense to add  a property file which maps OS name used in fontconfig files to OS  names from 'os-release` file.
Something like this:

SuSE=SLES,opensuse-leap,opensuse-tumbleweed

-------------

PR: https://git.openjdk.org/jdk/pull/12260


From aivanov at openjdk.org  Tue Jan 31 09:20:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 31 Jan 2023 09:20:59 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v3]
In-Reply-To: <NwENeUfPamY810Eg3HVFVSzUhBOnfrYV1D4IL5IvOJg=.9f5cbaab-ca1c-4ddf-97f1-ae611629f1e9@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <kkN_fihRAOtPRTzHMmwe4NtWWzaDcZ4wnqCGBJB-r_o=.51f8dfb3-f108-48c0-ae0b-b32bda45ec4f@github.com>
 <hCEkbC4GGKOfytfFY1fAAi4cuCoKa1dasJb1p6lGwIo=.ea01e9e1-084e-4db0-a0d3-2cecdf4eec3b@github.com>
 <f5EQs8jqc97QHBUuB4wkGazE2VqbWYORB-NxqbywRh0=.e3b631fa-2d9d-4880-a42b-75ead935fd08@github.com>
 <goObx40wfIwqroukX3_X7H0ccahEtSB1dgygLn5bDvE=.4a6645fb-e8cd-4608-abf1-99e63f1c1141@github.com>
 <S9-eV_HuugtZAkr48TtCImO-7AUF1anW0PnrqmXn_Ho=.4f61156e-57e5-4e5a-901a-70a74fa8ceaf@github.com>
 <NwENeUfPamY810Eg3HVFVSzUhBOnfrYV1D4IL5IvOJg=.9f5cbaab-ca1c-4ddf-97f1-ae611629f1e9@github.com>
Message-ID: <DtVBXxZ0HeAcp7OtXwXYQqxgG8lnGf1wjpmsFDhWdLg=.f75a9dee-9a7e-4675-90d5-4de45a45f4c8@github.com>

On Tue, 31 Jan 2023 08:50:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It seems the isDone method modification is causing a JCK test to fail and there's no spec for it to challenge JCK test, although logically it seems right that STATE should be DONE but for now, I have modified the fix which satisfies regression test and JCK both..
>
> isDone() spec mention `"Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true"`
> so for cancel state also, the state needs to be in DONE state, in which case we can reinstate the DONE state check in isDone()

`isDone()` spec is inherited from `Future.isDone()` and it is true for how `FutureTask` is implemented.

https://github.com/openjdk/jdk/blob/810c8a271b4524ae776e2306ef699e04a7d145a2/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L565-L570

Can't we change it?

Given what is said in the spec for `SwingWorker` before, I assume `isDone` should return `true` when the status of `SwingWorker` moves to `DONE` and it should occur when `doInBackground` returns as this is defined in the spec:

https://github.com/openjdk/jdk/blob/810c8a271b4524ae776e2306ef699e04a7d145a2/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L288-L293

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Tue Jan 31 09:35:07 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 31 Jan 2023 09:35:07 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v5]
In-Reply-To: <wuP70-tBQIFqdbSibzsr2EdPBgjQPNDLfIkFxiWC6KI=.e46bd69a-6449-4b36-8592-741f93bd4cc2@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <wuP70-tBQIFqdbSibzsr2EdPBgjQPNDLfIkFxiWC6KI=.e46bd69a-6449-4b36-8592-741f93bd4cc2@github.com>
Message-ID: <U9XVv6RNp9GuDXZ6hHhtE4XVawdeOPQccYdARLvmfEM=.110623c4-5425-49d7-b5a1-dd4ea2ddaf9d@github.com>

On Tue, 31 Jan 2023 08:54:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set DONE state for cancel

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/SwingWorker.java line 554:

> 552:     public final boolean cancel(boolean mayInterruptIfRunning) {
> 553:         setState(StateValue.DONE);
> 554:         return future.cancel(mayInterruptIfRunning);

Setting the state to `DONE` unconditionally doesn't seem right either. What if `doInBackground` isn't started? What if `doInBackground` starts after you compare the state is `PENDING`?

If `cancel` changes the state, it must do it after `future.cancel` returns. But then, the state moves to `DONE` before `doInBackground` exited which contradicts the spec for `DONE`.

src/java.desktop/share/classes/javax/swing/SwingWorker.java line 568:

> 566:      */
> 567:     public final boolean isDone() {
> 568:         return future.isDone() && state == StateValue.DONE;

Suggestion:

        return state == StateValue.DONE;

I guess we can remove the call to `future.isDone()` altogether. Either both conditions are true, or both are false.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 51:

> 49:                 try {
> 50:                     System.out.println("Cleaning up");
> 51:                     Thread.sleep(5000);

I still think that you should define constants for *all the delays*, and using 1 or 2 seconds for cleaning should be enough.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 72:

> 70:         Thread.sleep(5000);
> 71: 
> 72:         worker.cancel(true);

I still suggest ensuring `cancel` does not take too long.

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From aturbanov at openjdk.org  Tue Jan 31 10:57:12 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 31 Jan 2023 10:57:12 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v5]
In-Reply-To: <wuP70-tBQIFqdbSibzsr2EdPBgjQPNDLfIkFxiWC6KI=.e46bd69a-6449-4b36-8592-741f93bd4cc2@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <wuP70-tBQIFqdbSibzsr2EdPBgjQPNDLfIkFxiWC6KI=.e46bd69a-6449-4b36-8592-741f93bd4cc2@github.com>
Message-ID: <3iukWhhd7HF8bKe3qcx89HfTEEYQGErrV8CAYlKtbGM=.613ed693-02f9-4009-b007-8236bbd07896@github.com>

On Tue, 31 Jan 2023 08:54:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set DONE state for cancel

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 34:

> 32: public class TestDoneBeforeDoInBackground {
> 33: 
> 34:     static boolean doInBackground =  false;

Suggestion:

    static boolean doInBackground = false;

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Tue Jan 31 11:17:39 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 31 Jan 2023 11:17:39 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v6]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <PTPx20vVNKQREIO1WadYNeK7IsCz-kuH-BFFf-PK7e0=.f3665903-ff5d-4853-bf4d-c027af5b768b@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix and test updated

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/5d723a78..4e93f1cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=04-05

  Stats: 9 lines in 2 files changed: 2 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11940.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11940/head:pull/11940

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Tue Jan 31 11:17:47 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 31 Jan 2023 11:17:47 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v5]
In-Reply-To: <U9XVv6RNp9GuDXZ6hHhtE4XVawdeOPQccYdARLvmfEM=.110623c4-5425-49d7-b5a1-dd4ea2ddaf9d@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <wuP70-tBQIFqdbSibzsr2EdPBgjQPNDLfIkFxiWC6KI=.e46bd69a-6449-4b36-8592-741f93bd4cc2@github.com>
 <U9XVv6RNp9GuDXZ6hHhtE4XVawdeOPQccYdARLvmfEM=.110623c4-5425-49d7-b5a1-dd4ea2ddaf9d@github.com>
Message-ID: <Eytc7_Q_mQ04d7mK8ZUAsC8N6weHIZIlPXD1FLMZqFA=.64bce79f-6748-4629-a8c9-de4bd8e76485@github.com>

On Tue, 31 Jan 2023 09:26:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set DONE state for cancel
>
> src/java.desktop/share/classes/javax/swing/SwingWorker.java line 554:
> 
>> 552:     public final boolean cancel(boolean mayInterruptIfRunning) {
>> 553:         setState(StateValue.DONE);
>> 554:         return future.cancel(mayInterruptIfRunning);
> 
> Setting the state to `DONE` unconditionally doesn't seem right either. What if `doInBackground` isn't started? What if `doInBackground` starts after you compare the state is `PENDING`?
> 
> If `cancel` changes the state, it must do it after `future.cancel` returns. But then, the state moves to `DONE` before `doInBackground` exited which contradicts the spec for `DONE`.

OK..I have removed unconditional setting of DONE state..
But then as I mentioned, it would cause JCK failure, so I have reverted isDone() change too...

> src/java.desktop/share/classes/javax/swing/SwingWorker.java line 568:
> 
>> 566:      */
>> 567:     public final boolean isDone() {
>> 568:         return future.isDone() && state == StateValue.DONE;
> 
> Suggestion:
> 
>         return state == StateValue.DONE;
> 
> I guess we can remove the call to `future.isDone()` altogether. Either both conditions are true, or both are false.

It will cause JCK issue..

> test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 51:
> 
>> 49:                 try {
>> 50:                     System.out.println("Cleaning up");
>> 51:                     Thread.sleep(5000);
> 
> I still think that you should define constants for *all the delays*, and using 1 or 2 seconds for cleaning should be enough.

done

> test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 72:
> 
>> 70:         Thread.sleep(5000);
>> 71: 
>> 72:         worker.cancel(true);
> 
> I still suggest ensuring `cancel` does not take too long.

Not sure I understand this...please elaborate...

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Tue Jan 31 11:21:01 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 31 Jan 2023 11:21:01 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v5]
In-Reply-To: <Eytc7_Q_mQ04d7mK8ZUAsC8N6weHIZIlPXD1FLMZqFA=.64bce79f-6748-4629-a8c9-de4bd8e76485@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <wuP70-tBQIFqdbSibzsr2EdPBgjQPNDLfIkFxiWC6KI=.e46bd69a-6449-4b36-8592-741f93bd4cc2@github.com>
 <U9XVv6RNp9GuDXZ6hHhtE4XVawdeOPQccYdARLvmfEM=.110623c4-5425-49d7-b5a1-dd4ea2ddaf9d@github.com>
 <Eytc7_Q_mQ04d7mK8ZUAsC8N6weHIZIlPXD1FLMZqFA=.64bce79f-6748-4629-a8c9-de4bd8e76485@github.com>
Message-ID: <BaLHOQDDPAraVAb98XoURF-cu6yxIqXDK6TNXo-DV2g=.2a014dc5-f688-408b-a715-a30386d71cfc@github.com>

On Tue, 31 Jan 2023 11:11:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> OK..I have removed unconditional setting of DONE state.. But then as I mentioned, it would cause JCK failure, so I have reverted isDone() change too...

Should we update the spec for `isDone()`? I think it's the right way because it makes the behaviour consistent. Doing so requires a CSR which will be the grounds for updating the JCK test.

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Tue Jan 31 11:26:58 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 31 Jan 2023 11:26:58 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v5]
In-Reply-To: <Eytc7_Q_mQ04d7mK8ZUAsC8N6weHIZIlPXD1FLMZqFA=.64bce79f-6748-4629-a8c9-de4bd8e76485@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <wuP70-tBQIFqdbSibzsr2EdPBgjQPNDLfIkFxiWC6KI=.e46bd69a-6449-4b36-8592-741f93bd4cc2@github.com>
 <U9XVv6RNp9GuDXZ6hHhtE4XVawdeOPQccYdARLvmfEM=.110623c4-5425-49d7-b5a1-dd4ea2ddaf9d@github.com>
 <Eytc7_Q_mQ04d7mK8ZUAsC8N6weHIZIlPXD1FLMZqFA=.64bce79f-6748-4629-a8c9-de4bd8e76485@github.com>
Message-ID: <xatY6gxatbkEZQ8VuJMFszLQrj9pRClziMnW2P4MdPw=.fcbe6a05-ea3c-4f87-b51e-6ebc4d180d4b@github.com>

On Tue, 31 Jan 2023 11:13:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 72:
>> 
>>> 70:         Thread.sleep(5000);
>>> 71: 
>>> 72:         worker.cancel(true);
>> 
>> I still suggest ensuring `cancel` does not take too long.
>
> Not sure I understand this...please elaborate...

Something like this:

https://github.com/aivanov-jdk/jdk/blob/15580d0f1a3a9630b224bb567aacec03d825c777/test/jdk/javax/swing/SwingWorker/TestSwingWorker.java#L83-L90

You can take all the changes to the test as it is quicker and configurable.

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Tue Jan 31 12:34:27 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 31 Jan 2023 12:34:27 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v7]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <gll-HVV3fi_I91vvXrZyVsjSqa0ec1G88S1u9LdgmIM=.64b441d0-8f8a-4297-b9ee-1b0aabe13157@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Test update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/4e93f1cb..ff5d18ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=05-06

  Stats: 17 lines in 1 file changed: 13 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11940.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11940/head:pull/11940

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Tue Jan 31 12:34:27 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 31 Jan 2023 12:34:27 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v5]
In-Reply-To: <BaLHOQDDPAraVAb98XoURF-cu6yxIqXDK6TNXo-DV2g=.2a014dc5-f688-408b-a715-a30386d71cfc@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <wuP70-tBQIFqdbSibzsr2EdPBgjQPNDLfIkFxiWC6KI=.e46bd69a-6449-4b36-8592-741f93bd4cc2@github.com>
 <U9XVv6RNp9GuDXZ6hHhtE4XVawdeOPQccYdARLvmfEM=.110623c4-5425-49d7-b5a1-dd4ea2ddaf9d@github.com>
 <Eytc7_Q_mQ04d7mK8ZUAsC8N6weHIZIlPXD1FLMZqFA=.64bce79f-6748-4629-a8c9-de4bd8e76485@github.com>
 <BaLHOQDDPAraVAb98XoURF-cu6yxIqXDK6TNXo-DV2g=.2a014dc5-f688-408b-a715-a30386d71cfc@github.com>
Message-ID: <t2sqA-UE8tBiY7t2RVdLqBnB_xt447gTnB5PDdhPRDM=.ef0a44b4-0ca0-40eb-a0a3-f3634d09d135@github.com>

On Tue, 31 Jan 2023 11:18:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> OK..I have removed unconditional setting of DONE state..
>> But then as I mentioned, it would cause JCK failure, so I have reverted isDone() change too...
>
>> OK..I have removed unconditional setting of DONE state.. But then as I mentioned, it would cause JCK failure, so I have reverted isDone() change too...
> 
> Should we update the spec for `isDone()`? I think it's the right way because it makes the behaviour consistent. Doing so requires a CSR which will be the grounds for updating the JCK test.

I am not sure if it is entirely wrong..I will keep it as it is for now..I dont want to go in CSR route for now..
The present iteration takes care of reproducer and also satisifies JCK..
If in future it is needed, we can take a look..

>> Not sure I understand this...please elaborate...
>
> Something like this:
> 
> https://github.com/aivanov-jdk/jdk/blob/15580d0f1a3a9630b224bb567aacec03d825c777/test/jdk/javax/swing/SwingWorker/TestSwingWorker.java#L83-L90
> 
> You can take all the changes to the test as it is quicker and configurable.

Thanks for the test. I have updated..
Also, as per the spec you mentioned
https://github.com/openjdk/jdk/blob/810c8a271b4524ae776e2306ef699e04a7d145a2/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L288-L293

I have added one more condition

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Tue Jan 31 13:03:07 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 31 Jan 2023 13:03:07 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v7]
In-Reply-To: <gll-HVV3fi_I91vvXrZyVsjSqa0ec1G88S1u9LdgmIM=.64b441d0-8f8a-4297-b9ee-1b0aabe13157@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gll-HVV3fi_I91vvXrZyVsjSqa0ec1G88S1u9LdgmIM=.64b441d0-8f8a-4297-b9ee-1b0aabe13157@github.com>
Message-ID: <1OAGhGRLXFpx9eHwuxhpm2-q2BoN3Vcke0wNa9xMgo0=.9d5a090a-de71-40b6-b331-61dae5e7357c@github.com>

On Tue, 31 Jan 2023 12:34:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 37:

> 35: 
> 36:     static boolean doInBackground = false;
> 37:     static final int WAIT_TIME = 200;

Why not `private`?

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 87:

> 85:             throw new RuntimeException("doInBackground is finished " +
> 86:                                        " but State is not DONE");
> 87:         }

I think you should wait for cleanup to finish and ensure that `doInBackground` is set to `true` and the state is `DONE`.

If you don't wait until cleanup wait completes, the test does not test anything because jtreg will shutdown the JVM as soon main thread exists, which will happen before `done` gets called.

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Tue Jan 31 13:09:58 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 31 Jan 2023 13:09:58 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v5]
In-Reply-To: <t2sqA-UE8tBiY7t2RVdLqBnB_xt447gTnB5PDdhPRDM=.ef0a44b4-0ca0-40eb-a0a3-f3634d09d135@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <wuP70-tBQIFqdbSibzsr2EdPBgjQPNDLfIkFxiWC6KI=.e46bd69a-6449-4b36-8592-741f93bd4cc2@github.com>
 <U9XVv6RNp9GuDXZ6hHhtE4XVawdeOPQccYdARLvmfEM=.110623c4-5425-49d7-b5a1-dd4ea2ddaf9d@github.com>
 <Eytc7_Q_mQ04d7mK8ZUAsC8N6weHIZIlPXD1FLMZqFA=.64bce79f-6748-4629-a8c9-de4bd8e76485@github.com>
 <BaLHOQDDPAraVAb98XoURF-cu6yxIqXDK6TNXo-DV2g=.2a014dc5-f688-408b-a715-a30386d71cfc@github.com>
 <t2sqA-UE8tBiY7t2RVdLqBnB_xt447gTnB5PDdhPRDM=.ef0a44b4-0ca0-40eb-a0a3-f3634d09d135@github.com>
Message-ID: <f18Q9S5G53VzF690lvH-wDGKG4EEaIezegILDa77ya8=.410b8b64-690e-4036-a947-5ed1aaa29f34@github.com>

On Tue, 31 Jan 2023 12:29:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> OK..I have removed unconditional setting of DONE state.. But then as I mentioned, it would cause JCK failure, so I have reverted isDone() change too...
>> 
>> Should we update the spec for `isDone()`? I think it's the right way because it makes the behaviour consistent. Doing so requires a CSR which will be the grounds for updating the JCK test.
>
> I am not sure if it is entirely wrong..I will keep it as it is for now..I dont want to go in CSR route for now..
> The present iteration takes care of reproducer and also satisifies JCK..
> If in future it is needed, we can take a look..

Let's see what others have to say.

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From chen.j.patrick at gmail.com  Tue Jan 31 13:50:05 2023
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Tue, 31 Jan 2023 14:50:05 +0100
Subject: RFR: 8301254: UNIX sun/font coding does not detect SuSE in
 openSUSE Leap distribution [v2]
In-Reply-To: <q7zUAd1YMLSiJR2XPrKXMWOY9uJLnPhx9xYkYih6C5k=.2dddb068-a973-439f-b401-645605b91725@github.com>
References: <mT0PlFG6VxvcXjvjQjrvJLQqsHHLhB2aM74PzA_vDo8=.2759eb4a-97f7-4c9d-8806-08791f824c6c@github.com>
 <sU7oZqE6FU5biu3MNOA_zwKmYotbMX7edfWdKDHqggA=.51de7d26-db67-4cf8-a8ca-75a0e1c20b53@github.com>
 <q7zUAd1YMLSiJR2XPrKXMWOY9uJLnPhx9xYkYih6C5k=.2dddb068-a973-439f-b401-645605b91725@github.com>
Message-ID: <CANmuJ8so1=sysPgfAkoA3wW_UyY_WN7W-LHT7AkKoMkdzNJaHA@mail.gmail.com>

anyone can unsubscribe or ban me ? spam

Le mar. 31 janv. 2023 ? 10:21, Alexander Scherbatiy <alexsch at openjdk.org> a
?crit :

> On Fri, 27 Jan 2023 17:00:48 GMT, Alexander Scherbatiy <
> alexsch at openjdk.org> wrote:
>
> >> [JDK-8278549](https://bugs.openjdk.org/browse/JDK-8278549)`
> <https://bugs.openjdk.org/browse/JDK-8278549)> UNIX sun/font coding
> misses SUSE distro detection on recent distro SUSE 15` adds SuSE detection
> by checking SLES os name property in `/etc/os-release` file.
> >>
> >> `opensuse/leap:15.4` docker defines os name property as `"openSUSE
> Leap"` in `/etc/os-release` file which is not recognized as SuSE.
> >>
> >> The issue is reproduced with Oracle jdk-19.0.2 with custom
> fontconfig.SuSE.properties file copied to jdk-19.0.2/lib directory.
> >>
> >> The fix checks if os name property from  `/etc/os-release` contains
> `SUSE`  substring.
> >>
> >> Steps to reproduce.
> >> - Download Oracle jdk-19.0.2
> >> - Copy custom [fontconfig.SuSE.properties](
> https://bugs.openjdk.org/secure/attachment/102435/fontconfig.SuSE.properties)
> file to jdk-19.0.2/lib directory.
> >> - Run the `opensuse/leap:15.4` docker and install freetype and dejavu
> fonts (do not install fontconfig)
> >>
> >> docker run --rm --security-opt seccomp=unconfined -it
> opensuse/leap:15.4 bash
> >> zypper install -y dejavu-fonts
> >> zypper install -y freetype2
> >>
> >> - Run HelloImage java sample in the docker
> >>
> >> import javax.imageio.ImageIO;
> >> import java.awt.*;
> >> import java.awt.image.BufferedImage;
> >> import java.io.File;
> >>
> >> public class HelloImage {
> >>
> >>     public static void main(String[] args) throws Exception {
> >>
> >>         BufferedImage buff = new BufferedImage(300, 200,
> BufferedImage.TYPE_INT_RGB);
> >>         Graphics2D g = buff.createGraphics();
> >>         g.setColor(Color.WHITE);
> >>         g.fillRect(0, 0, buff.getWidth(), buff.getHeight());
> >>
> >>         g.setColor(Color.BLUE);
> >>         g.setFont(g.getFont().deriveFont(32f));
> >>         g.drawString("Hello, Image!", 50, 50);
> >>         g.dispose();
> >>
> >>         File file = new File("hello-image.png");
> >>         ImageIO.write(buff, "png", file);
> >>     }
> >> }
> >>
> >>
> >>
> >> ./jdk-19.0.2/bin/javac HelloImage.java
> >> ./jdk-19.0.2/bin/java HelloImage
> >> 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:1261)
> >>      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:706)
> >>      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:318)
> >>      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:56)
> >>      at
> java.desktop/sun.font.PlatformFontInfo.createFontManager(PlatformFontInfo.java:37)
> >>      at
> java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:51)
> >>      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:151)
> >>      at
> java.desktop/sun.java2d.SunGraphics2D.checkFontInfo(SunGraphics2D.java:671)
> >>      at
> java.desktop/sun.java2d.SunGraphics2D.getFontInfo(SunGraphics2D.java:837)
> >>      at
> java.desktop/sun.java2d.pipe.GlyphListPipe.drawString(GlyphListPipe.java:46)
> >>      at
> java.desktop/sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2931)
> >>      at HelloImage.main(HelloImage.java:17)
> >
> > Alexander Scherbatiy has updated the pull request incrementally with one
> additional commit since the last revision:
> >
> >   Revert back empty line removing
>
> May be it has sense to add  a property file which maps OS name used in
> fontconfig files to OS  names from 'os-release` file.
> Something like this:
>
> SuSE=SLES,opensuse-leap,opensuse-tumbleweed
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/12260
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230131/bed8ad57/attachment.htm>

From psadhukhan at openjdk.org  Tue Jan 31 14:42:29 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 31 Jan 2023 14:42:29 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v7]
In-Reply-To: <1OAGhGRLXFpx9eHwuxhpm2-q2BoN3Vcke0wNa9xMgo0=.9d5a090a-de71-40b6-b331-61dae5e7357c@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gll-HVV3fi_I91vvXrZyVsjSqa0ec1G88S1u9LdgmIM=.64b441d0-8f8a-4297-b9ee-1b0aabe13157@github.com>
 <1OAGhGRLXFpx9eHwuxhpm2-q2BoN3Vcke0wNa9xMgo0=.9d5a090a-de71-40b6-b331-61dae5e7357c@github.com>
Message-ID: <U5GH0KkI8TB2xzZelRtiKJryZg3XsmwKHwq8J5ghJpA=.6674da24-5069-4efe-adae-60f458dbf732@github.com>

On Tue, 31 Jan 2023 13:00:10 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test update
>
> test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 87:
> 
>> 85:             throw new RuntimeException("doInBackground is finished " +
>> 86:                                        " but State is not DONE");
>> 87:         }
> 
> I think you should wait for cleanup to finish and ensure that `doInBackground` is set to `true` and the state is `DONE`.
> 
> If you don't wait until cleanup wait completes, the test does not test anything because jtreg will shutdown the JVM as soon main thread exists, which will happen before `done` gets called.

Dont think so...If `doInBackground `is true it should mean cleanup is done as `doInBackground ` is false by default

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Tue Jan 31 14:51:17 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 31 Jan 2023 14:51:17 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v7]
In-Reply-To: <U5GH0KkI8TB2xzZelRtiKJryZg3XsmwKHwq8J5ghJpA=.6674da24-5069-4efe-adae-60f458dbf732@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gll-HVV3fi_I91vvXrZyVsjSqa0ec1G88S1u9LdgmIM=.64b441d0-8f8a-4297-b9ee-1b0aabe13157@github.com>
 <1OAGhGRLXFpx9eHwuxhpm2-q2BoN3Vcke0wNa9xMgo0=.9d5a090a-de71-40b6-b331-61dae5e7357c@github.com>
 <U5GH0KkI8TB2xzZelRtiKJryZg3XsmwKHwq8J5ghJpA=.6674da24-5069-4efe-adae-60f458dbf732@github.com>
Message-ID: <XSyu6Is-Z88T_sdn3xzjWbssHCUy76nKI-uyzSCnQGI=.3f19908f-1650-408d-9a03-4680b2905d27@github.com>

On Tue, 31 Jan 2023 14:39:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 87:
>> 
>>> 85:             throw new RuntimeException("doInBackground is finished " +
>>> 86:                                        " but State is not DONE");
>>> 87:         }
>> 
>> I think you should wait for cleanup to finish and ensure that `doInBackground` is set to `true` and the state is `DONE`.
>> 
>> If you don't wait until cleanup wait completes, the test does not test anything because jtreg will shutdown the JVM as soon main thread exists, which will happen before `done` gets called.
>
> Dont think so...If `doInBackground `is true it should mean cleanup is done as `doInBackground ` is false by default

That's the thing. If `cancel` doesn't wait until `doInBackground` completes, which *it shouldn't do*, then `cancel` returns quickly. Therefore the main thread reaches this condition before the ?cleanup? in `doInBackground` finishes, as such the test should always fail.

Do I miss anything?

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Tue Jan 31 15:34:44 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 31 Jan 2023 15:34:44 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v8]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <L4aiGpssMPzU3v5ngSkcPTh6sRQtrOk4CMbrDv7I2d4=.093bd80a-c140-439c-93a4-4aad0245cac4@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Test update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/ff5d18ae..f3b59bd2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=06-07

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11940.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11940/head:pull/11940

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Tue Jan 31 15:34:47 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 31 Jan 2023 15:34:47 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v7]
In-Reply-To: <XSyu6Is-Z88T_sdn3xzjWbssHCUy76nKI-uyzSCnQGI=.3f19908f-1650-408d-9a03-4680b2905d27@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gll-HVV3fi_I91vvXrZyVsjSqa0ec1G88S1u9LdgmIM=.64b441d0-8f8a-4297-b9ee-1b0aabe13157@github.com>
 <1OAGhGRLXFpx9eHwuxhpm2-q2BoN3Vcke0wNa9xMgo0=.9d5a090a-de71-40b6-b331-61dae5e7357c@github.com>
 <U5GH0KkI8TB2xzZelRtiKJryZg3XsmwKHwq8J5ghJpA=.6674da24-5069-4efe-adae-60f458dbf732@github.com>
 <XSyu6Is-Z88T_sdn3xzjWbssHCUy76nKI-uyzSCnQGI=.3f19908f-1650-408d-9a03-4680b2905d27@github.com>
Message-ID: <9BfWhSLXeXSdmh5lmHZCdCrhhQNPuvYH7nvwPfIXlqk=.929553ed-6b66-406f-b845-3cdb6f35e1a3@github.com>

On Tue, 31 Jan 2023 14:48:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Dont think so...If `doInBackground `is true it should mean cleanup is done as `doInBackground ` is false by default
>
> That's the thing. If `cancel` doesn't wait until `doInBackground` completes, which *it shouldn't do*, then `cancel` returns quickly. Therefore the main thread reaches this condition before the ?cleanup? in `doInBackground` finishes, as such the test should always fail.
> 
> Do I miss anything?

ok..understood...modified...

-------------

PR: https://git.openjdk.org/jdk/pull/11940


From duke at openjdk.org  Tue Jan 31 16:23:13 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Tue, 31 Jan 2023 16:23:13 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v17]
In-Reply-To: <3JQGjb1CawgL8ov_zMsEB2Q6DcgQa2kchkjec85mAZM=.7d6eea32-0f50-43f7-88c3-b28572c47d6a@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <hF3_a7jZr5PrfWlGeu3r8585eaCKP1fLSNN0xhOGpzQ=.62524ef2-4726-4b87-bde8-3181bd8d70d3@github.com>
 <3JQGjb1CawgL8ov_zMsEB2Q6DcgQa2kchkjec85mAZM=.7d6eea32-0f50-43f7-88c3-b28572c47d6a@github.com>
Message-ID: <vgh-OpjjgeBe1BlnHgC4YKTteMKDVhwxYk8QRQ4hxyI=.d5c58bd7-8935-427c-84bf-cd90dfe0e3a6@github.com>

On Wed, 25 Jan 2023 18:40:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Skip tests if required font is absent
>
> src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java line 92:
> 
>> 90: 
>> 91:     private static int unicodeToUnits(int unicode, int dstOffset, char[] dst) {
>> 92:         if (unicode >= 0x10000) {
> 
> Why can't you use public API that already does this ? [ ](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Character.html#toChars(int,char%5B%5D,int)) ?

Which API exactly? I didn't know there is any, so I added this as a helper method.

-------------

PR: https://git.openjdk.org/jdk/pull/4798


From philip.race at oracle.com  Tue Jan 31 17:58:51 2023
From: philip.race at oracle.com (Philip Race)
Date: Tue, 31 Jan 2023 09:58:51 -0800
Subject: How to find all keyboard-related manual tests?
In-Reply-To: <CAMTdVeoT047Z7FKRUEtuSoLr67_1MRSniK-Jo_3rkYD2H3BGFQ@mail.gmail.com>
References: <CAMTdVeoT047Z7FKRUEtuSoLr67_1MRSniK-Jo_3rkYD2H3BGFQ@mail.gmail.com>
Message-ID: <1f3d8009-5203-84cb-4b21-e2a6c827a07d@oracle.com>

There's no mechanism to find all tests for a particular functional 
sub-area - other than what you are already doing.

-phil.

On 1/30/23 4:30 PM, Nikita Provotorov wrote:
> Hello! I'm trying to figure out how to find all _manual_ tests which 
> verifies behavior of keyboards, e.g. the following cases:
> * "Regular" text input
> * Dead keys handling
> * Input methods handling
> * Shortcuts support
>
> AFAIU it's easy enough to find all manual tests via just grepping of 
> all sources by the "/manual" substring. The next thing I've tried is 
> to find all usages of the class /java.awt.event.KeyEvent/?among all 
> found "/manual" entries. But I believe it won't give me a complete 
> list of such tests.
>
> Could anyone advise anything?
>
> Best regards,
> Nikita Provotorov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230131/c4e586b8/attachment.htm>

From prr at openjdk.org  Tue Jan 31 18:08:45 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 31 Jan 2023 18:08:45 GMT
Subject: RFR: 8301254: UNIX sun/font coding does not detect SuSE in
 openSUSE Leap distribution [v2]
In-Reply-To: <q7zUAd1YMLSiJR2XPrKXMWOY9uJLnPhx9xYkYih6C5k=.2dddb068-a973-439f-b401-645605b91725@github.com>
References: <mT0PlFG6VxvcXjvjQjrvJLQqsHHLhB2aM74PzA_vDo8=.2759eb4a-97f7-4c9d-8806-08791f824c6c@github.com>
 <sU7oZqE6FU5biu3MNOA_zwKmYotbMX7edfWdKDHqggA=.51de7d26-db67-4cf8-a8ca-75a0e1c20b53@github.com>
 <q7zUAd1YMLSiJR2XPrKXMWOY9uJLnPhx9xYkYih6C5k=.2dddb068-a973-439f-b401-645605b91725@github.com>
Message-ID: <oX7ljbQSBM4nJbJ3absIOpkvBLXfHgpp6RnRndKyxv8=.5480d192-767b-4946-a4c9-b765d84f9cf1@github.com>

On Tue, 31 Jan 2023 09:16:50 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> uSE=SLES,opensuse-leap,opensuse-tumbleweed

I am not sure that would even be right.
Fedora and RHEL might need different mappings and so might these too.
So if you want to provide support for both of these, provide 2 files.
I'd like it simple as in "you look at /etc/os-release, and that tells you the name to use", without any more indirections than that.

-------------

PR: https://git.openjdk.org/jdk/pull/12260


From alexsch at openjdk.org  Tue Jan 31 18:26:59 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Tue, 31 Jan 2023 18:26:59 GMT
Subject: RFR: 8301254: UNIX sun/font coding does not detect SuSE in
 openSUSE Leap distribution [v2]
In-Reply-To: <sU7oZqE6FU5biu3MNOA_zwKmYotbMX7edfWdKDHqggA=.51de7d26-db67-4cf8-a8ca-75a0e1c20b53@github.com>
References: <mT0PlFG6VxvcXjvjQjrvJLQqsHHLhB2aM74PzA_vDo8=.2759eb4a-97f7-4c9d-8806-08791f824c6c@github.com>
 <sU7oZqE6FU5biu3MNOA_zwKmYotbMX7edfWdKDHqggA=.51de7d26-db67-4cf8-a8ca-75a0e1c20b53@github.com>
Message-ID: <T3iBFglkkl-sKG_9BKGXb-Dus0esrT_wN-b6d-Neu9A=.83ea11f0-a71f-41b2-bf65-2c3ac2d9e611@github.com>

On Fri, 27 Jan 2023 17:00:48 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> [JDK-8278549](https://bugs.openjdk.org/browse/JDK-8278549)` UNIX sun/font coding misses SUSE distro detection on recent distro SUSE 15` adds SuSE detection by checking SLES os name property in `/etc/os-release` file.
>> 
>> `opensuse/leap:15.4` docker defines os name property as `"openSUSE Leap"` in `/etc/os-release` file which is not recognized as SuSE.
>> 
>> The issue is reproduced with Oracle jdk-19.0.2 with custom fontconfig.SuSE.properties file copied to jdk-19.0.2/lib directory.
>> 
>> The fix checks if os name property from  `/etc/os-release` contains `SUSE`  substring.
>> 
>> Steps to reproduce.
>> - Download Oracle jdk-19.0.2
>> - Copy custom [fontconfig.SuSE.properties](https://bugs.openjdk.org/secure/attachment/102435/fontconfig.SuSE.properties) file to jdk-19.0.2/lib directory.
>> - Run the `opensuse/leap:15.4` docker and install freetype and dejavu fonts (do not install fontconfig)
>> 
>> docker run --rm --security-opt seccomp=unconfined -it opensuse/leap:15.4 bash
>> zypper install -y dejavu-fonts
>> zypper install -y freetype2
>> 
>> - Run HelloImage java sample in the docker
>> 
>> import javax.imageio.ImageIO;
>> import java.awt.*;
>> import java.awt.image.BufferedImage;
>> import java.io.File;
>> 
>> public class HelloImage {
>> 
>>     public static void main(String[] args) throws Exception {
>> 
>>         BufferedImage buff = new BufferedImage(300, 200, BufferedImage.TYPE_INT_RGB);
>>         Graphics2D g = buff.createGraphics();
>>         g.setColor(Color.WHITE);
>>         g.fillRect(0, 0, buff.getWidth(), buff.getHeight());
>> 
>>         g.setColor(Color.BLUE);
>>         g.setFont(g.getFont().deriveFont(32f));
>>         g.drawString("Hello, Image!", 50, 50);
>>         g.dispose();
>> 
>>         File file = new File("hello-image.png");
>>         ImageIO.write(buff, "png", file);
>>     }
>> }
>> 
>> 
>> 
>> ./jdk-19.0.2/bin/javac HelloImage.java
>> ./jdk-19.0.2/bin/java HelloImage
>> 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:1261)
>> 	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:706)
>> 	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:318)
>> 	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:56)
>> 	at java.desktop/sun.font.PlatformFontInfo.createFontManager(PlatformFontInfo.java:37)
>> 	at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:51)
>> 	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:151)
>> 	at java.desktop/sun.java2d.SunGraphics2D.checkFontInfo(SunGraphics2D.java:671)
>> 	at java.desktop/sun.java2d.SunGraphics2D.getFontInfo(SunGraphics2D.java:837)
>> 	at java.desktop/sun.java2d.pipe.GlyphListPipe.drawString(GlyphListPipe.java:46)
>> 	at java.desktop/sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2931)
>> 	at HelloImage.main(HelloImage.java:17)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert back empty line removing

The proposal is to add one `os-mapping.properties` file which contains os mapping for all new platforms:

SuSE=SLES,opensuse-leap,opensuse-tumbleweed
Ubuntu=ubuntu
Fedora=fedora
RedHat=rhel

It can be put to the same directory where `fontconfig.OS.properties` files are placed.

JDK reads `/etc/os-release` file, gets ID property and finds corresponding mapping in `os-mapping.properties` file (SuSE for SLES and opensuse-leap, RedHat for rhel, and etc).
What user needs for new OS name is to add one more mapping into  `os-mapping.properties` property file.
It allows to use only one `fontconfig.OS.properties` file for different OSes from the same family and reuse the old ones.

-------------

PR: https://git.openjdk.org/jdk/pull/12260


From prr at openjdk.org  Tue Jan 31 18:36:25 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 31 Jan 2023 18:36:25 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v4]
In-Reply-To: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
Message-ID: <YnXqa8KIQIlrArpqvqXpa1bmbHecnBqfTvE3JLFTDig=.e3a487b2-a2d1-4af9-971d-ce5fb530ebe7@github.com>

> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
> So deprecating - for removal - and adding warnings now in the docs is appropriate.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8300891

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12175/files
  - new: https://git.openjdk.org/jdk/pull/12175/files/a9d49aa3..6a0131bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12175&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12175&range=02-03

  Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12175.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12175/head:pull/12175

PR: https://git.openjdk.org/jdk/pull/12175


From prr at openjdk.org  Tue Jan 31 18:36:28 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 31 Jan 2023 18:36:28 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v3]
In-Reply-To: <F5rc9C6Tmfg97QGHmygzARQD0WWwulxsVXWp9x0s38U=.2681ab7b-c858-496e-9016-1f8cb00f6125@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <F5rc9C6Tmfg97QGHmygzARQD0WWwulxsVXWp9x0s38U=.2681ab7b-c858-496e-9016-1f8cb00f6125@github.com>
Message-ID: <ijpI5Z4q90IQe2r6AXBakQmffo_U7j51eV1sfIwByeA=.0d9f35f3-b95d-4002-bc8a-1c206dae7b8e@github.com>

On Fri, 27 Jan 2023 20:22:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
>> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
>> So deprecating - for removal - and adding warnings now in the docs is appropriate.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300891

It doesn't seem to matter .. but I added # .. and I changed one of the cases to use linkplain - the one embedded in the text - because it looks better that way. Cleaned up some formatting also.

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From aivanov at openjdk.org  Tue Jan 31 20:34:52 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 31 Jan 2023 20:34:52 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v4]
In-Reply-To: <YnXqa8KIQIlrArpqvqXpa1bmbHecnBqfTvE3JLFTDig=.e3a487b2-a2d1-4af9-971d-ce5fb530ebe7@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <YnXqa8KIQIlrArpqvqXpa1bmbHecnBqfTvE3JLFTDig=.e3a487b2-a2d1-4af9-971d-ce5fb530ebe7@github.com>
Message-ID: <Em_tgVxZ5reFgbix11eY3NJ0VxE3U64ly6lpG0uU5Sg=.d4fc852d-96a2-4ec6-9c0b-d5ab20dad788@github.com>

On Tue, 31 Jan 2023 18:36:25 GMT, Phil Race <prr at openjdk.org> wrote:

>> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
>> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
>> So deprecating - for removal - and adding warnings now in the docs is appropriate.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300891

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From kizune at openjdk.org  Tue Jan 31 21:39:52 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 31 Jan 2023 21:39:52 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v4]
In-Reply-To: <YnXqa8KIQIlrArpqvqXpa1bmbHecnBqfTvE3JLFTDig=.e3a487b2-a2d1-4af9-971d-ce5fb530ebe7@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <YnXqa8KIQIlrArpqvqXpa1bmbHecnBqfTvE3JLFTDig=.e3a487b2-a2d1-4af9-971d-ce5fb530ebe7@github.com>
Message-ID: <z2KFfigFCKwzvjfGBb86qhhGM32e5amJxIDX5_6gZ-I=.5969f467-2d96-4657-8292-f4dd3a7e73a2@github.com>

On Tue, 31 Jan 2023 18:36:25 GMT, Phil Race <prr at openjdk.org> wrote:

>> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
>> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
>> So deprecating - for removal - and adding warnings now in the docs is appropriate.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300891

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12175


From serb at openjdk.org  Tue Jan 31 23:55:53 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 31 Jan 2023 23:55:53 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v8]
In-Reply-To: <L4aiGpssMPzU3v5ngSkcPTh6sRQtrOk4CMbrDv7I2d4=.093bd80a-c140-439c-93a4-4aad0245cac4@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <L4aiGpssMPzU3v5ngSkcPTh6sRQtrOk4CMbrDv7I2d4=.093bd80a-c140-439c-93a4-4aad0245cac4@github.com>
Message-ID: <2iqTlhXat4p5UQFfk340a4WvY36dOlon_LGhMFX_4Ls=.598001c6-43c3-492c-9b78-974afc3d43a8@github.com>

On Tue, 31 Jan 2023 15:34:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

How the updated code is supposed to work if the worker will have some state updated by the "doInBackground" and used by the "done" method. I guess if the "doInBackground" will be canceled the "done" method may throw an exception? Do we have such usage in our codebase?

-------------

PR: https://git.openjdk.org/jdk/pull/11940