From myano at openjdk.java.net  Mon Nov  1 08:40:18 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 1 Nov 2021 08:40:18 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <aZX6pJkrGOTYLlAHRl9WlEGtoahiInx4QzelDWpV2b0=.c9a736f9-5dd5-4382-8513-94a0233105dc@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <-hj0v7RZ0HPpP9GND5csZsZ1Vz7oxaufOAC0-ZygtwM=.6a5ae7a8-52d6-4e3e-a166-2fae2c23dbe0@github.com>
 <cTqTWZsK6uJI_Kw9nUymKQnYxxzWBRrk52qJAKpAc9I=.18f7dffd-3ebe-4bd0-bc2f-d61b55437036@github.com>
 <aZX6pJkrGOTYLlAHRl9WlEGtoahiInx4QzelDWpV2b0=.c9a736f9-5dd5-4382-8513-94a0233105dc@github.com>
Message-ID: <U-qO88jAVsZm1kSSVeFENiBohIDvKJegL0ofZjgkAIA=.70a42880-8026-4077-9f78-4d50e38a8ede@github.com>

On Thu, 28 Oct 2021 09:03:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yes, this run() is called on "D3D Screen Updater" thread. It is reasonable that a new PaintEvent is posted when SurfaceData is replaced on this thread. I would limit posting new PaintEvent via createGraphics() only.
>
> Probably I should clarify my question, you added a parameter to the validate method and pass the "true" so the "validate" method will post a paint event, but just a few lines below there is a comment that the next code line "sd.getPeer().replaceSurfaceDataLater();" also will post an event. Is the comment outdated, or we will post two of them?

Neither. replaceSurfaceDataLater() is called when validate() fails to post a PaintEvent. So only one of them will be posted.

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

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


From myano at openjdk.java.net  Mon Nov  1 09:03:12 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 1 Nov 2021 09:03:12 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails [v2]
In-Reply-To: <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>
 <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
Message-ID: <Bip5bUVRJG0psF_Ns_FBvnzfboOwZpZW5tEKh-pcXSg=.2ddac801-542d-4a4b-b268-e3ae202c2bdb@github.com>

On Tue, 26 Oct 2021 04:52:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Masanori Yano 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:
>> 
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - Merge branch 'master' of https://github.com/masyano/jdk into 7001973
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>
> I'll check it, let me some time.

@mrserb Thank you for helping me with the test. How many more days does the test run?

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

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


From kizune at openjdk.java.net  Mon Nov  1 11:43:25 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 1 Nov 2021 11:43:25 GMT
Subject: RFR: 8169468: NoResizeEventOnDMChangeTest.java fails because FS Window
 didn't receive all resizes!
Message-ID: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>

I was able to reproduce this issue locally 2 times out of 100 runs on multi-monitor
configuration. Both times due to the screen resolution change is so slow window got
accidentally moved to the secondary screen by the display driver.
Can not reproduce this bug with ATI card at all.
Since there is nothing we can do to stop graphics driver from reassigning
the window if it decides that promary monitor is not on at the moment the
only way is to check if this has had happened and if so then we can not trust the test
since we changing resolution of one display and window not getting resized
because it is placed on another display and test should be skept.

After that i ran this test locally about a thousand times on all platforms
and has not seen the failure again.

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

Commit messages:
 - 8169468: NoResizeEventOnDMChangeTest.java fails because FS Window didn't receive all resizes!

Changes: https://git.openjdk.java.net/jdk/pull/6186/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6186&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8169468
  Stats: 26 lines in 2 files changed: 20 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6186.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6186/head:pull/6186

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


From kizune at openjdk.java.net  Mon Nov  1 15:44:21 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 1 Nov 2021 15:44:21 GMT
Subject: RFR: 8202667: java/awt/Debug/DumpOnKey/DumpOnKey.java times out on
 Windows
Message-ID: <UJlw_zkVH08cPUxgs4QIsqcgYlhwYDE6tUSK7H0T_Dw=.f3e5a6aa-c200-4175-a41a-5b8fca110e2e@github.com>

Looks like the problem occurs when system is slow to actually close windows,
then keyboard events are going to the wrong window. The idea of the fix is to
bring the new window to front before actual testing starts and close window
on EDT and then wait for 2 seconds for actual hardware window to disappear.

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

Commit messages:
 - 8202667: java/awt/Debug/DumpOnKey/DumpOnKey.java times out on Windows

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

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


From duke at openjdk.java.net  Mon Nov  1 17:04:42 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Mon, 1 Nov 2021 17:04:42 GMT
Subject: RFR: 8159451: [TEST_BUG]
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java [v2]
In-Reply-To: <spn83vBFx_i1HAc9XDeWfwu2EozpYl4eMGHnX3WXhqM=.ef1ba9ba-1605-4d96-bdec-f41bf702686f@github.com>
References: <spn83vBFx_i1HAc9XDeWfwu2EozpYl4eMGHnX3WXhqM=.ef1ba9ba-1605-4d96-bdec-f41bf702686f@github.com>
Message-ID: <gCsU7iWAMDpfQZs_WgG3G3a5DQqPspxwsbzftWGwWOs=.4d9c2424-bf5c-46f9-92c4-806f5ba514d7@github.com>

> Added more time to test, removed pixel check during EmbeddedFrame test from OverlappingTestBase.

Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:

 - reformat pixel check
 - removed debugging statement

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6177/files
  - new: https://git.openjdk.java.net/jdk/pull/6177/files/bbf1377d..f317c9df

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

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

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


From duke at openjdk.java.net  Mon Nov  1 17:04:46 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Mon, 1 Nov 2021 17:04:46 GMT
Subject: RFR: 8159451: [TEST_BUG]
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java [v2]
In-Reply-To: <ExePjnN8Y5CtQhQeAG7v_cJWbB9cOfkfJdpBZeR0K_c=.15aa272b-d54d-41f6-a5ac-48c7f9063409@github.com>
References: <spn83vBFx_i1HAc9XDeWfwu2EozpYl4eMGHnX3WXhqM=.ef1ba9ba-1605-4d96-bdec-f41bf702686f@github.com>
 <ExePjnN8Y5CtQhQeAG7v_cJWbB9cOfkfJdpBZeR0K_c=.15aa272b-d54d-41f6-a5ac-48c7f9063409@github.com>
Message-ID: <ZjNweLThUgD8bv8W5AwTfTgckht4BapMSR2CRwUJ0Xs=.9989c871-9acc-45f9-b775-20260848607a@github.com>

On Fri, 29 Oct 2021 21:29:44 GMT, Phil Race <prr at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - reformat pixel check
>>  - removed debugging statement
>
> test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 359:
> 
>> 357:     private static boolean isValidForPixelCheck(Component component) {
>> 358:         if ((component instanceof java.awt.Scrollbar)
>> 359:                 || (isMac && ((component instanceof java.awt.Button) || (component == null)))) {
> 
> "removed pixel check during EmbeddedFrame test from OverlappingTestBase."
> 
> Well you presumably can't pixel check a null component, but why is it null ?
> It seems like a test issue for it to be null. Can you explain how this happens ?
> 
> Also if this code *were* to stay it would be better formatted like
>  if ((component instanceof java.awt.Scrollbar) ||
>       (isMac && ((component instanceof java.awt.Button) ||
>       (component == null))))
>  {

When component is null it means EmbeddedFrame is currently being tested

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

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


From serb at openjdk.java.net  Mon Nov  1 19:25:13 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 1 Nov 2021 19:25:13 GMT
Subject: RFR: 8202667: java/awt/Debug/DumpOnKey/DumpOnKey.java times out on
 Windows
In-Reply-To: <UJlw_zkVH08cPUxgs4QIsqcgYlhwYDE6tUSK7H0T_Dw=.f3e5a6aa-c200-4175-a41a-5b8fca110e2e@github.com>
References: <UJlw_zkVH08cPUxgs4QIsqcgYlhwYDE6tUSK7H0T_Dw=.f3e5a6aa-c200-4175-a41a-5b8fca110e2e@github.com>
Message-ID: <WafkUFPm8R_dT7mATt9HqrA0TPLsM8pswxXnY7OE1Dc=.3c895658-0be7-4c4e-818f-c1aae0a127aa@github.com>

On Mon, 1 Nov 2021 15:34:42 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Looks like the problem occurs when system is slow to actually close windows,
> then keyboard events are going to the wrong window. The idea of the fix is to
> bring the new window to front before actual testing starts and close window
> on EDT and then wait for 2 seconds for actual hardware window to disappear.

>From the stack traces in the bug report, it seems that the problem was in some kind of deadlock in the SunToolkit.waitForIdle

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

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


From duke at openjdk.java.net  Mon Nov  1 22:32:19 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Mon, 1 Nov 2021 22:32:19 GMT
Subject: Integrated: 8262945: [macos] Regression Manual Test for Key Events
 Fails
In-Reply-To: <LhSIteG6WssDHH2if3oeA-0qLZGhxfqb11JyTC4EPh8=.b8b62eb4-a50c-4eb2-98c7-6f122f87d08b@github.com>
References: <LhSIteG6WssDHH2if3oeA-0qLZGhxfqb11JyTC4EPh8=.b8b62eb4-a50c-4eb2-98c7-6f122f87d08b@github.com>
Message-ID: <khrMElyzPpQfkbnZs1_5v6PNH1aXe7F9qR4YY1p8S8I=.7b8ec80b-f8bd-4a85-ba81-747a37eac0bc@github.com>

On Tue, 21 Sep 2021 18:00:13 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

> Added a check for active keyboard language and added support for Russian NSEvent keyCodes to JavaVirtualKeyCode translation. Originally, only English characters were checked for even if other languages were in native letterCharacterSet. Can be easily expanded to include other languages as well.

This pull request has now been integrated.

Changeset: 47e7a425
Author:    Alisen Chung <alisen.chung at oracle.com>
Committer: Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/47e7a42594f1c36f71cdf4d383080bf8d616b7e7
Stats:     13 lines in 1 file changed: 10 ins; 1 del; 2 mod

8262945: [macos] Regression Manual Test for Key Events Fails

Reviewed-by: prr, kizune

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

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


From kizune at openjdk.java.net  Mon Nov  1 22:53:14 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 1 Nov 2021 22:53:14 GMT
Subject: RFR: 8202667: java/awt/Debug/DumpOnKey/DumpOnKey.java times out on
 Windows
In-Reply-To: <WafkUFPm8R_dT7mATt9HqrA0TPLsM8pswxXnY7OE1Dc=.3c895658-0be7-4c4e-818f-c1aae0a127aa@github.com>
References: <UJlw_zkVH08cPUxgs4QIsqcgYlhwYDE6tUSK7H0T_Dw=.f3e5a6aa-c200-4175-a41a-5b8fca110e2e@github.com>
 <WafkUFPm8R_dT7mATt9HqrA0TPLsM8pswxXnY7OE1Dc=.3c895658-0be7-4c4e-818f-c1aae0a127aa@github.com>
Message-ID: <Ssd2xYtpngdcYhXKAmdY9F3By7GjVX47CreaMEXg0Qg=.1b0ec41a-7816-4c82-bbb9-3791cfb49516@github.com>

On Mon, 1 Nov 2021 19:22:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> From the stack traces in the bug report, it seems that the problem was in some kind of deadlock in the SunToolkit.waitForIdle

I was not able to reproduce the deadlock scenario - and i ran this test about 3 hours non-stop which resulted in more than 2000 invocations. I had couple of false positives where dump was expected but did not happened due to the mismatch between the windows that receiving key pressed and key released events and that is what i tried to fix to make test more stable. But neither locally nor on remote test machines i was not able to reproduce it exactly the way it reported. Giving the extensive use of Robot.waitForIdle() in other tests without any issue my only approach is to make this test more stable and enable it for execution and then see if it will timeout again. I doubt so.

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

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


From tnakamura at openjdk.java.net  Tue Nov  2 00:30:13 2021
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Tue, 2 Nov 2021 00:30:13 GMT
Subject: RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese
 characters were garbled
In-Reply-To: <4lgBU_G-xdIAebIcknY7c3Xg8BeWIVkLaWv6YlDSv1o=.37bf8684-d954-4dfb-8348-8d0a89464a38@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
 <4lgBU_G-xdIAebIcknY7c3Xg8BeWIVkLaWv6YlDSv1o=.37bf8684-d954-4dfb-8348-8d0a89464a38@github.com>
Message-ID: <PlkhU7xQCMN4_HAY_fNYliy5Z-nrrvOdHEIpuIvMoN8=.8fc1c94a-7f34-489d-a772-4d8135fb1b88@github.com>

On Fri, 23 Apr 2021 06:49:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Hi,
>> 
>> Could you review the fix?
>> When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts.
>> 
>> The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn.
>
> As far as I understand it is not directly related to the JTable and the bug is reproduced if some specific font is used when any text is printed? Did you check why the CTextPipe does not support it directly? It looks like the JavaCT_DrawGlyphVector uses pure core graphics, which I think should support this font?

@mrserb @prrace 
Could you review the latest patch, please? I believe it's more reasonable than previous proposals.

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

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


From prr at openjdk.java.net  Tue Nov  2 01:08:20 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Nov 2021 01:08:20 GMT
Subject: RFR: 8276266: Clean up incorrect client-libs ProblemList.txt entries
Message-ID: <-gLIqdVcPOaZgxCVSkMNQ6FzygLGTk7O710l-Mwc4zc=.8b8a3124-9d44-4893-af45-89c22d49b589@github.com>

We have a few stale entries in the Problem list.
We need to remap some tests to still open bugs
7100044 -> 6849371
8203047 -> 8072110
8233703 -> 8238436

We need to remove these FIXED bugs
java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java 7185258 macosx-all

java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java 8000171 windows-all
(actually closed as a dup of 8196100 which is fixed)

And this RESOLVED / not reproducible.
 java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java 8061235 macosx-all

I've verified that the removed ones do pass in the CI test system so we should be OK unless they are very intermittent or environment specific

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

Commit messages:
 - 8276266: Clean up incorrect client-libs ProblemList.txt entries

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

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


From prr at openjdk.java.net  Tue Nov  2 01:29:37 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Nov 2021 01:29:37 GMT
Subject: RFR: 8276266: Clean up incorrect client-libs ProblemList.txt
 entries [v2]
In-Reply-To: <-gLIqdVcPOaZgxCVSkMNQ6FzygLGTk7O710l-Mwc4zc=.8b8a3124-9d44-4893-af45-89c22d49b589@github.com>
References: <-gLIqdVcPOaZgxCVSkMNQ6FzygLGTk7O710l-Mwc4zc=.8b8a3124-9d44-4893-af45-89c22d49b589@github.com>
Message-ID: <Q68GylRF9581gV18UsW8evlKv6xh2vRSKtANJF0JSQc=.6f764d5f-78b7-4781-b569-80dd14cad809@github.com>

> We have a few stale entries in the Problem list.
> We need to remap some tests to still open bugs
> 7100044 -> 6849371
> 8203047 -> 8072110
> 8233703 -> 8238436
> 8273618 -> 8273617
> 
> We need to remove these FIXED bugs
> java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java 7185258 macosx-all
> 
> java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java 8000171 windows-all
> (actually closed as a dup of 8196100 which is fixed)
> 
> And this RESOLVED / not reproducible.
>  java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java 8061235 macosx-all
> 
> I've verified that the removed ones do pass in the CI test system so we should be OK unless they are very intermittent or environment specific

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

  8276266: Clean up incorrect client-libs ProblemList.txt entries

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6203/files
  - new: https://git.openjdk.java.net/jdk/pull/6203/files/11979ea9..0fa362a2

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

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

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


From serb at openjdk.java.net  Tue Nov  2 01:29:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 2 Nov 2021 01:29:37 GMT
Subject: RFR: 8276266: Clean up incorrect client-libs ProblemList.txt
 entries
In-Reply-To: <-gLIqdVcPOaZgxCVSkMNQ6FzygLGTk7O710l-Mwc4zc=.8b8a3124-9d44-4893-af45-89c22d49b589@github.com>
References: <-gLIqdVcPOaZgxCVSkMNQ6FzygLGTk7O710l-Mwc4zc=.8b8a3124-9d44-4893-af45-89c22d49b589@github.com>
Message-ID: <ZtQfaBZJjucLrzsLY9g7GHJayRM45RaNd9GuIC0hOoY=.7e71aa86-5339-4d5c-b6fc-c83d4cad909a@github.com>

On Tue, 2 Nov 2021 01:00:25 GMT, Phil Race <prr at openjdk.org> wrote:

> We have a few stale entries in the Problem list.
> We need to remap some tests to still open bugs
> 7100044 -> 6849371
> 8203047 -> 8072110
> 8233703 -> 8238436
> 8273618 -> 8273617
> 
> We need to remove these FIXED bugs
> java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java 7185258 macosx-all
> 
> java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java 8000171 windows-all
> (actually closed as a dup of 8196100 which is fixed)
> 
> And this RESOLVED / not reproducible.
>  java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java 8061235 macosx-all
> 
> I've verified that the removed ones do pass in the CI test system so we should be OK unless they are very intermittent or environment specific

I am not sure why the macOS-specific JDK-8203047 was closed as a duplicate of x11 specific JDK-8072110?
The HandleExceptionOnEDT from the JDK-8203047 is not even mentioned in the JDK-8072110.

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

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


From prr at openjdk.java.net  Tue Nov  2 02:53:19 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Nov 2021 02:53:19 GMT
Subject: Integrated: 8273704: DrawStringWithInfiniteXform.java failed :
 drawString with InfiniteXform transform takes long time
In-Reply-To: <Lpf8FVKhBAteysIOTzRIoWtn6p1EajY6ehzReguXoGc=.c4321b67-bfbc-4215-8ef7-1e88a856de8e@github.com>
References: <Lpf8FVKhBAteysIOTzRIoWtn6p1EajY6ehzReguXoGc=.c4321b67-bfbc-4215-8ef7-1e88a856de8e@github.com>
Message-ID: <8iz81BzM0JNb6yHEAmg6p_eXjDHBPk4m4b2Ol-sRcXs=.f5d816ee-3bdd-47ca-a637-590ac8dbf9de@github.com>

On Fri, 22 Oct 2021 19:25:28 GMT, Phil Race <prr at openjdk.org> wrote:

> This test has only failed once - for reasons that are not clear.
> I wanted to just increase the timeout but the test was written such that it always waited as long
> as the timeout since it had an un-canceled scheduled task.
> 
> So I've also made the test cancel the task once it is complete and made the variables volatile
> so that they should be read properly by the other thread.

This pull request has now been integrated.

Changeset: acceffcb
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/acceffcbf73aa4416c487f890f3ca65e55e47164
Stats:     7 lines in 1 file changed: 3 ins; 1 del; 3 mod

8273704: DrawStringWithInfiniteXform.java failed : drawString with InfiniteXform transform takes long time

Reviewed-by: serb, psadhukhan

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

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


From prr at openjdk.java.net  Tue Nov  2 03:03:09 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Nov 2021 03:03:09 GMT
Subject: RFR: 8202667: java/awt/Debug/DumpOnKey/DumpOnKey.java times out on
 Windows
In-Reply-To: <UJlw_zkVH08cPUxgs4QIsqcgYlhwYDE6tUSK7H0T_Dw=.f3e5a6aa-c200-4175-a41a-5b8fca110e2e@github.com>
References: <UJlw_zkVH08cPUxgs4QIsqcgYlhwYDE6tUSK7H0T_Dw=.f3e5a6aa-c200-4175-a41a-5b8fca110e2e@github.com>
Message-ID: <sW6Z6IOOMEwROo-qGVX2TSY3vYnd0YOVkTJ32A_Pgio=.530af4b7-eb2f-4f1d-90cb-9bac76018d88@github.com>

On Mon, 1 Nov 2021 15:34:42 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Looks like the problem occurs when system is slow to actually close windows,
> then keyboard events are going to the wrong window. The idea of the fix is to
> bring the new window to front before actual testing starts and close window
> on EDT and then wait for 2 seconds for actual hardware window to disappear.

Marked as reviewed by prr (Reviewer).

When originally reported this test frequently timed out. So if it didn't have the same timeout in 2000 iterations
perhaps the root cause of that is fixed ? Any ideas what that fix might have been ?
But with that and these modifications we can put this test back into production

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

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


From prr at openjdk.java.net  Tue Nov  2 03:14:09 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Nov 2021 03:14:09 GMT
Subject: RFR: 8169468: NoResizeEventOnDMChangeTest.java fails because FS
 Window didn't receive all resizes!
In-Reply-To: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
References: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
Message-ID: <KZ4Qk6OZ4u1oaky_ywd-eRJLhwNWVIqS_NsalpSwMP4=.59da0922-c57d-4cd2-990a-eb8c7f02e502@github.com>

On Mon, 1 Nov 2021 11:35:24 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> I was able to reproduce this issue locally 2 times out of 100 runs on multi-monitor
> configuration. Both times due to the screen resolution change is so slow window got
> accidentally moved to the secondary screen by the display driver.
> Can not reproduce this bug with ATI card at all.
> Since there is nothing we can do to stop graphics driver from reassigning
> the window if it decides that promary monitor is not on at the moment the
> only way is to check if this has had happened and if so then we can not trust the test
> since we changing resolution of one display and window not getting resized
> because it is placed on another display and test should be skept.
> 
> After that i ran this test locally about a thousand times on all platforms
> and has not seen the failure again.

test/jdk/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java line 194:

> 192:         if (skipTest.get()) {
> 193:             // Skipping test because graphics driver switched window to another screen
> 194:             return;

This test isn't about multi-mon .. it is about full screen.
If the window doesn't go full screen on the display we expect that's odd.
Are you saying it went FS on one display and then jumped ?
Can't we make the test more robust about it going on the display we expect OR pivot the test to verifying on the display that went FS ?

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

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


From prr at openjdk.java.net  Tue Nov  2 03:18:09 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Nov 2021 03:18:09 GMT
Subject: RFR: 8169474: KeyCharTest: Wrong number of key events: 0
In-Reply-To: <1fyY3RSMw8l0Xjcq3JFZ88qM7ert_bmJcnXPuW9qmNw=.09e8d110-40bd-4654-a268-40033ab93340@github.com>
References: <1fyY3RSMw8l0Xjcq3JFZ88qM7ert_bmJcnXPuW9qmNw=.09e8d110-40bd-4654-a268-40033ab93340@github.com>
Message-ID: <cDgEIg0qebfhX6q7LGjRrjiqbIzZRbGJcRnJx1uR1hM=.d9ebc43b-f432-47d7-a6d5-7d071822e6d8@github.com>

On Thu, 28 Oct 2021 17:02:45 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> When i reproduced the test failures locally on Ubuntu 18 it seems like AWT Frame
> that appeared on the screen had not received focus and keyboard events went to the
> Window Manager which ignored them for having no meaning in the current context.
> Added explicit toFront and requestFocus calls so window gets focused.

test/jdk/java/awt/event/KeyEvent/KeyChar/KeyCharTest.java line 90:

> 88:                     BufferedImage capture = robot.createScreenCapture(gd.getDefaultConfiguration().getBounds());
> 89:                     File captureFile = new File("capture.png");
> 90:                     ImageIO.write(capture, "png", captureFile);

Can you confirm this png gets written somewhere that isn't scratch spaced deleted at the end of testing ?
I don't think we do this multi-screen dance in most tests since the default screen should be good enough.
Why isn't it here ?

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

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


From prr at openjdk.java.net  Tue Nov  2 03:23:07 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Nov 2021 03:23:07 GMT
Subject: RFR: 8079267: [TEST_BUG] Test
 java/awt/Frame/MiscUndecorated/RepaintTest.java fails
In-Reply-To: <D3GP12GLPR9xzPb5FWN42g_HZkqUTUKdgBabiiJOECA=.800914e0-274f-405a-becd-fdd1a9271d1c@github.com>
References: <D3GP12GLPR9xzPb5FWN42g_HZkqUTUKdgBabiiJOECA=.800914e0-274f-405a-becd-fdd1a9271d1c@github.com>
Message-ID: <m-QwMWGD90ZZOYzB5A5kmzhkHs4zEB6lJDGq4Gr6qUU=.79b3022d-c9d3-4636-bcce-f70f3c0c5636@github.com>

On Thu, 28 Oct 2021 13:24:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test does not fail on Windows and does fail on Linux. 
> 
> After de-iconification we expect to see the button focused:
> ![image](https://user-images.githubusercontent.com/77687766/139171852-54413dba-d58a-46d4-ab83-59d93868e287.png)
> 
> Actual look:
> ![image](https://user-images.githubusercontent.com/77687766/139171775-80e64e58-c49d-489a-8fe0-fb0640fc3be9.png)
> 
> Button loses focus on `frame.to Front()` call, after its removal test passes. There is an [open issue](https://bugs.openjdk.java.net/browse/JDK-7156130) for this.
> 
> 
> Some cleanup was also made. Testing is green for all platforms.
> 
> 
> I am unable to reproduce [8266244 / macosx-aarch64](https://bugs.openjdk.java.net/browse/JDK-8266244), however it is not removed from the problem list due to its intermittent nature which needs more time to investigate.

"Button loses focus on frame.to Front() call, after its removal test passes. There is an open issue for this."

Is it specific to Button ?

You may want to discuss with @azuev-java since he is using toFront to get focus over in https://github.com/openjdk/jdk/pull/6161 but it isn't a Button there.

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

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


From kizune at openjdk.java.net  Tue Nov  2 04:01:12 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 2 Nov 2021 04:01:12 GMT
Subject: RFR: 8169468: NoResizeEventOnDMChangeTest.java fails because FS
 Window didn't receive all resizes!
In-Reply-To: <KZ4Qk6OZ4u1oaky_ywd-eRJLhwNWVIqS_NsalpSwMP4=.59da0922-c57d-4cd2-990a-eb8c7f02e502@github.com>
References: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
 <KZ4Qk6OZ4u1oaky_ywd-eRJLhwNWVIqS_NsalpSwMP4=.59da0922-c57d-4cd2-990a-eb8c7f02e502@github.com>
Message-ID: <_boEo0RRPZZQ4Bf4Lwe9sMf0YJ33JSApg_2-HB2lKis=.c045acdb-662e-4b68-9a93-6c22f6681d60@github.com>

On Tue, 2 Nov 2021 03:11:29 GMT, Phil Race <prr at openjdk.org> wrote:

> Are you saying it went FS on one display and then jumped ?

That is exactly what happened and only in this case the test were failed - obviously, because the window was on a secondary display and resize was happening on the primary so window has not got any events about resize. I added a lot of debug information to the native code but after that i ran test for hours non stop and it does not reproduce - i guess it is all due to the timings. You see, when we changing resolution the physical display goes offline (at least on my system with NVidia card) meaning status LED goes from green to amber, then it goes green again with the new resolution set. If request to get full screen windows from GD comes at that exact moment the window might be placed on a secondary display which does not change. I do not know how to force OS not to reassign window to another display in this case.

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

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


From kizune at openjdk.java.net  Tue Nov  2 13:27:13 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 2 Nov 2021 13:27:13 GMT
Subject: RFR: 8202667: java/awt/Debug/DumpOnKey/DumpOnKey.java times out on
 Windows
In-Reply-To: <sW6Z6IOOMEwROo-qGVX2TSY3vYnd0YOVkTJ32A_Pgio=.530af4b7-eb2f-4f1d-90cb-9bac76018d88@github.com>
References: <UJlw_zkVH08cPUxgs4QIsqcgYlhwYDE6tUSK7H0T_Dw=.f3e5a6aa-c200-4175-a41a-5b8fca110e2e@github.com>
 <sW6Z6IOOMEwROo-qGVX2TSY3vYnd0YOVkTJ32A_Pgio=.530af4b7-eb2f-4f1d-90cb-9bac76018d88@github.com>
Message-ID: <yUXlxDG9pPftW8MbNUYze8iHGsbRUEnhXzutSLdOyTE=.b9d556b3-0d9e-4507-9133-f07bee950c91@github.com>

On Tue, 2 Nov 2021 02:59:44 GMT, Phil Race <prr at openjdk.org> wrote:

> Any ideas what that fix might have been ?

There were some modifications to the problematic methods in SunToolkit including JDK-8196100 which would be the reason this test stopped deadlocking in that particular method.

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

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


From kizune at openjdk.java.net  Tue Nov  2 13:27:14 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 2 Nov 2021 13:27:14 GMT
Subject: Integrated: 8202667: java/awt/Debug/DumpOnKey/DumpOnKey.java times out
 on Windows
In-Reply-To: <UJlw_zkVH08cPUxgs4QIsqcgYlhwYDE6tUSK7H0T_Dw=.f3e5a6aa-c200-4175-a41a-5b8fca110e2e@github.com>
References: <UJlw_zkVH08cPUxgs4QIsqcgYlhwYDE6tUSK7H0T_Dw=.f3e5a6aa-c200-4175-a41a-5b8fca110e2e@github.com>
Message-ID: <TfNVAPHwMSgFXWR9hk09bcIAd0HjT5ZRXiddwbPi5Fw=.8743e758-5365-406c-aa0e-76d98ec51521@github.com>

On Mon, 1 Nov 2021 15:34:42 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Looks like the problem occurs when system is slow to actually close windows,
> then keyboard events are going to the wrong window. The idea of the fix is to
> bring the new window to front before actual testing starts and close window
> on EDT and then wait for 2 seconds for actual hardware window to disappear.

This pull request has now been integrated.

Changeset: cd778f5b
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cd778f5b049d52b68ab5872aad5f81e86e1718f7
Stats:     14 lines in 2 files changed: 10 ins; 1 del; 3 mod

8202667: java/awt/Debug/DumpOnKey/DumpOnKey.java times out on Windows

Reviewed-by: prr

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

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


From azvegint at openjdk.java.net  Tue Nov  2 15:29:20 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 2 Nov 2021 15:29:20 GMT
Subject: RFR: 8079267: [TEST_BUG] Test
 java/awt/Frame/MiscUndecorated/RepaintTest.java fails
In-Reply-To: <D3GP12GLPR9xzPb5FWN42g_HZkqUTUKdgBabiiJOECA=.800914e0-274f-405a-becd-fdd1a9271d1c@github.com>
References: <D3GP12GLPR9xzPb5FWN42g_HZkqUTUKdgBabiiJOECA=.800914e0-274f-405a-becd-fdd1a9271d1c@github.com>
Message-ID: <meoRQWu4AJPBhCqKneiy1IyTCtSkqc5keXk4qKFkdnM=.502e3fbe-1ca9-47ec-9db4-0bf9cc7f33fb@github.com>

On Thu, 28 Oct 2021 13:24:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test does not fail on Windows and does fail on Linux. 
> 
> After de-iconification we expect to see the button focused:
> ![image](https://user-images.githubusercontent.com/77687766/139171852-54413dba-d58a-46d4-ab83-59d93868e287.png)
> 
> Actual look:
> ![image](https://user-images.githubusercontent.com/77687766/139171775-80e64e58-c49d-489a-8fe0-fb0640fc3be9.png)
> 
> Button loses focus on `frame.to Front()` call, after its removal test passes. There is an [open issue](https://bugs.openjdk.java.net/browse/JDK-7156130) for this.
> 
> 
> Some cleanup was also made. Testing is green for all platforms.
> 
> 
> I am unable to reproduce [8266244 / macosx-aarch64](https://bugs.openjdk.java.net/browse/JDK-8266244), however it is not removed from the problem list due to its intermittent nature which needs more time to investigate.

> "Button loses focus on frame.to Front() call, after its removal test passes. There is an open issue for this."
> 
> Is it specific to Button ?
> 
> You may want to discuss with @azuev-java since he is using toFront to get focus over in #6161 but it isn't a Button there.

It is not specific to Button, it may be some other component as well. 
A window itself gets the focus on `toFront()` call, but not the previously focused component inside of it.

#6161 does not have any components and requires only window focus for the test, so it should not face this issue.

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

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


From prr at openjdk.java.net  Tue Nov  2 16:13:20 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Nov 2021 16:13:20 GMT
Subject: RFR: 8276266: Clean up incorrect client-libs ProblemList.txt
 entries
In-Reply-To: <ZtQfaBZJjucLrzsLY9g7GHJayRM45RaNd9GuIC0hOoY=.7e71aa86-5339-4d5c-b6fc-c83d4cad909a@github.com>
References: <-gLIqdVcPOaZgxCVSkMNQ6FzygLGTk7O710l-Mwc4zc=.8b8a3124-9d44-4893-af45-89c22d49b589@github.com>
 <ZtQfaBZJjucLrzsLY9g7GHJayRM45RaNd9GuIC0hOoY=.7e71aa86-5339-4d5c-b6fc-c83d4cad909a@github.com>
Message-ID: <u32Q5yNSHj0bo8IQHpzQ7OAVZ5b_fqlkKJvZoQEDOME=.a5840cea-7383-4950-b9c1-e91eadb5ffeb@github.com>

On Tue, 2 Nov 2021 01:24:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I am not sure why the macOS-specific JDK-8203047 was closed as a duplicate of x11 specific JDK-8072110?
> The HandleExceptionOnEDT from the JDK-8203047 is not even mentioned in the JDK-8072110.

I don't know. This was done by @prsadhuk - Prasanta can you explain that ?

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

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


From prr at openjdk.java.net  Tue Nov  2 21:35:28 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Nov 2021 21:35:28 GMT
Subject: RFR: 8276385: Re-run blessed-modifier-order script on java.desktop and
 jdk.accessibility
Message-ID: <vqzFVVDjA7a7Wh0Ejbs60tuptjgLUH_zghc91NoJz7M=.893dc063-c76d-4214-a491-deea8e42a76f@github.com>

Fix the non-blessed modifier order cases that have crept in since back when this was first fixed in JDK 9
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html
Similar clean up is happening in java.base https://git.openjdk.java.net/jdk/pull/6213

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

Commit messages:
 - 8276385: Re-run blessed-modifier-order script on java.desktop and jdk.accessibility

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

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


From serb at openjdk.java.net  Wed Nov  3 01:31:11 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 3 Nov 2021 01:31:11 GMT
Subject: RFR: 8276385: Re-run blessed-modifier-order script on java.desktop
 and jdk.accessibility
In-Reply-To: <vqzFVVDjA7a7Wh0Ejbs60tuptjgLUH_zghc91NoJz7M=.893dc063-c76d-4214-a491-deea8e42a76f@github.com>
References: <vqzFVVDjA7a7Wh0Ejbs60tuptjgLUH_zghc91NoJz7M=.893dc063-c76d-4214-a491-deea8e42a76f@github.com>
Message-ID: <I6raFzq2yCI7L65esNFglUTic-E2tIPMXQmCliWDzpc=.00dcbe27-47c9-4bec-b121-56c0d7d9cc72@github.com>

On Tue, 2 Nov 2021 21:27:59 GMT, Phil Race <prr at openjdk.org> wrote:

> Fix the non-blessed modifier order cases that have crept in since back when this was first fixed in JDK 9
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html
> Similar clean up is happening in java.base https://git.openjdk.java.net/jdk/pull/6213

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Wed Nov  3 01:51:13 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 3 Nov 2021 01:51:13 GMT
Subject: RFR: 8169468: NoResizeEventOnDMChangeTest.java fails because FS
 Window didn't receive all resizes!
In-Reply-To: <_boEo0RRPZZQ4Bf4Lwe9sMf0YJ33JSApg_2-HB2lKis=.c045acdb-662e-4b68-9a93-6c22f6681d60@github.com>
References: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
 <KZ4Qk6OZ4u1oaky_ywd-eRJLhwNWVIqS_NsalpSwMP4=.59da0922-c57d-4cd2-990a-eb8c7f02e502@github.com>
 <_boEo0RRPZZQ4Bf4Lwe9sMf0YJ33JSApg_2-HB2lKis=.c045acdb-662e-4b68-9a93-6c22f6681d60@github.com>
Message-ID: <tUaqwq_xewm0mS66byKEtEQP2_vwypi4C4f3Mq00S-4=.37c6c3b9-9fd2-494a-bb02-07bd4fd3f649@github.com>

On Tue, 2 Nov 2021 03:57:54 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> test/jdk/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java line 194:
>> 
>>> 192:         if (skipTest.get()) {
>>> 193:             // Skipping test because graphics driver switched window to another screen
>>> 194:             return;
>> 
>> This test isn't about multi-mon .. it is about full screen.
>> If the window doesn't go full screen on the display we expect that's odd.
>> Are you saying it went FS on one display and then jumped ?
>> Can't we make the test more robust about it going on the display we expect OR pivot the test to verifying on the display that went FS ?
>
>> Are you saying it went FS on one display and then jumped ?
> 
> That is exactly what happened and only in this case the test were failed - obviously, because the window was on a secondary display and resize was happening on the primary so window has not got any events about resize. I added a lot of debug information to the native code but after that i ran test for hours non stop and it does not reproduce - i guess it is all due to the timings. You see, when we changing resolution the physical display goes offline (at least on my system with NVidia card) meaning status LED goes from green to amber, then it goes green again with the new resolution set. If request to get full screen windows from GD comes at that exact moment the window might be placed on a secondary display which does not change. I do not know how to force OS not to reassign window to another display in this case.

In the scenario above what will happen if the window is jumped from one screen to another? Will it be full screen or it will be in the normal mode? Which (old or new) graphics device will report that the window is full screen on it? I guess we should move the window back to the old device in full-screen mode, or we should move the window to the new device but in the normal mode, in both cases, the resize event should be generated, isn't it?

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

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


From kizune at openjdk.java.net  Wed Nov  3 04:34:10 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 3 Nov 2021 04:34:10 GMT
Subject: RFR: 8169468: NoResizeEventOnDMChangeTest.java fails because FS
 Window didn't receive all resizes!
In-Reply-To: <tUaqwq_xewm0mS66byKEtEQP2_vwypi4C4f3Mq00S-4=.37c6c3b9-9fd2-494a-bb02-07bd4fd3f649@github.com>
References: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
 <KZ4Qk6OZ4u1oaky_ywd-eRJLhwNWVIqS_NsalpSwMP4=.59da0922-c57d-4cd2-990a-eb8c7f02e502@github.com>
 <_boEo0RRPZZQ4Bf4Lwe9sMf0YJ33JSApg_2-HB2lKis=.c045acdb-662e-4b68-9a93-6c22f6681d60@github.com>
 <tUaqwq_xewm0mS66byKEtEQP2_vwypi4C4f3Mq00S-4=.37c6c3b9-9fd2-494a-bb02-07bd4fd3f649@github.com>
Message-ID: <4Ig_kkTRHkQaFpjKUnmerjDfD9ggdEuGcAf3Sfrdw08=.dbed9437-de40-4b05-892d-d18b8b3bd954@github.com>

On Wed, 3 Nov 2021 01:47:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In the scenario above what will happen if the window is jumped from one screen to another? Will it be full screen or it will be in the normal mode? Which (old or new) graphics device will report that the window is full screen on it? I guess we should move the window back to the old device in full-screen mode, or we should move the window to the new device but in the normal mode, in both cases, the resize event should be generated, isn't it?

It opens up as a full screen window on the secondary display, i can't check which device reports it because when i add debug output i can not reproduce the failure. If two displays have different resolution then moving window from one GD to another it should generate the resize event on both window and the component inside it.

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

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


From duke at openjdk.java.net  Wed Nov  3 07:35:37 2021
From: duke at openjdk.java.net (Jeremy)
Date: Wed, 3 Nov 2021 07:35:37 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes Bezier
 pts
Message-ID: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>

This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)

The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
B. Updating the unit test to forgive the discrepancy.

I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.

Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.

This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

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

Commit messages:
 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box

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

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


From lbourges at openjdk.java.net  Wed Nov  3 08:57:14 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 3 Nov 2021 08:57:14 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier pts
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <QwPWiEobxSPsWIvSpi9vWEGCMQXoMg4he-26TS2mdo4=.916804e3-8dee-4170-ab53-c4d0b1a5550b@github.com>

On Wed, 3 Nov 2021 07:27:03 GMT, Jeremy <duke at openjdk.java.net> wrote:

> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
> 
> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
> B. Updating the unit test to forgive the discrepancy.
> 
> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
> 
> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
> 
> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

I will have a look at your maths. 
I improved cubic/quad extrema solver in the marlin renderer (curve monotonizer) and may propose few optimizations.

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

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


From duke at openjdk.java.net  Wed Nov  3 09:17:17 2021
From: duke at openjdk.java.net (Jeremy)
Date: Wed, 3 Nov 2021 09:17:17 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier pts
In-Reply-To: <QwPWiEobxSPsWIvSpi9vWEGCMQXoMg4he-26TS2mdo4=.916804e3-8dee-4170-ab53-c4d0b1a5550b@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <QwPWiEobxSPsWIvSpi9vWEGCMQXoMg4he-26TS2mdo4=.916804e3-8dee-4170-ab53-c4d0b1a5550b@github.com>
Message-ID: <SRTXv0dZIofPf9Zi9iX7xHcWicPAfiMAkGVRKjnpF9o=.03604965-2d53-4047-ae5d-3c66f718443c@github.com>

On Wed, 3 Nov 2021 08:53:53 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> I will have a look at your maths. I improved cubic/quad extrema solver in the marlin renderer (curve monotonizer) and may propose few optimizations.

Thanks. And this is my first attempt at an openjdk contribution, so please feel free to be patronizing if necessary. It's very likely I'll accidentally breach etiquette sooner or later.

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

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


From mdoerr at openjdk.java.net  Wed Nov  3 13:33:10 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 3 Nov 2021 13:33:10 GMT
Subject: RFR: JDK-8274977: Remove expandPacked and extendEdge from
 awt_ImagingLib.c
In-Reply-To: <1tSvf8JjhHG7crHsLOqHpNOsCcBziywqBBG6Q4SgYZk=.fec63717-09a4-4812-8e30-bdf86536cf4c@github.com>
References: <1tSvf8JjhHG7crHsLOqHpNOsCcBziywqBBG6Q4SgYZk=.fec63717-09a4-4812-8e30-bdf86536cf4c@github.com>
Message-ID: <2BRkvMNGQkKObaZy6bf6f_nArNgmhdX93NT3CHMZDL4=.1990a685-e887-4752-bcaf-48f7bdd69680@github.com>

On Fri, 8 Oct 2021 14:25:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small cleanup change.
> Looks like expandPacked and extendEdge from awt_ImagingLib.c are unreferenced/unused and can be removed.
> 
> Thanks, Matthias

Looks good and trivial.

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

Marked as reviewed by mdoerr (Reviewer).

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


From prr at openjdk.java.net  Wed Nov  3 16:26:20 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 3 Nov 2021 16:26:20 GMT
Subject: Integrated: 8276385: Re-run blessed-modifier-order script on
 java.desktop and jdk.accessibility
In-Reply-To: <vqzFVVDjA7a7Wh0Ejbs60tuptjgLUH_zghc91NoJz7M=.893dc063-c76d-4214-a491-deea8e42a76f@github.com>
References: <vqzFVVDjA7a7Wh0Ejbs60tuptjgLUH_zghc91NoJz7M=.893dc063-c76d-4214-a491-deea8e42a76f@github.com>
Message-ID: <GvcnmAV1o13cqii4E_pRqYYio1h2iuj4Es82rYvq1FM=.6dab7b34-b486-4888-83e6-d19f24eb42f4@github.com>

On Tue, 2 Nov 2021 21:27:59 GMT, Phil Race <prr at openjdk.org> wrote:

> Fix the non-blessed modifier order cases that have crept in since back when this was first fixed in JDK 9
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html
> Similar clean up is happening in java.base https://git.openjdk.java.net/jdk/pull/6213

This pull request has now been integrated.

Changeset: 0ef8cbe3
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0ef8cbe32540814d4c0be9c7b0f78486408657a7
Stats:     135 lines in 17 files changed: 0 ins; 0 del; 135 mod

8276385: Re-run blessed-modifier-order script on java.desktop and jdk.accessibility

Reviewed-by: serb

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

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


From prr at openjdk.java.net  Wed Nov  3 16:37:09 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 3 Nov 2021 16:37:09 GMT
Subject: RFR: JDK-8274977: Remove expandPacked and extendEdge from
 awt_ImagingLib.c
In-Reply-To: <1tSvf8JjhHG7crHsLOqHpNOsCcBziywqBBG6Q4SgYZk=.fec63717-09a4-4812-8e30-bdf86536cf4c@github.com>
References: <1tSvf8JjhHG7crHsLOqHpNOsCcBziywqBBG6Q4SgYZk=.fec63717-09a4-4812-8e30-bdf86536cf4c@github.com>
Message-ID: <SMUO_uGubB9AHSVNc0psqE_jKhGCgmYrL-IjeuqwQMQ=.a8731a15-806c-42c6-966a-dc51bd63d1df@github.com>

On Fri, 8 Oct 2021 14:25:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small cleanup change.
> Looks like expandPacked and extendEdge from awt_ImagingLib.c are unreferenced/unused and can be removed.
> 
> Thanks, Matthias

There's unresolved discussion here so it needs review and approval from some one who works in this area

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

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


From lbourges at openjdk.java.net  Wed Nov  3 17:30:11 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 3 Nov 2021 17:30:11 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier pts
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <KkUiD_-ZAogcDm6Ubxy6IYvj0Ik4bPG-Ay42QhFDwPE=.fbd788ef-e1dc-4810-8633-8006fa43fd0c@github.com>

On Wed, 3 Nov 2021 07:27:03 GMT, Jeremy <duke at openjdk.java.net> wrote:

> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
> 
> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
> B. Updating the unit test to forgive the discrepancy.
> 
> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
> 
> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
> 
> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

This issue relates to improving the bounding box of curves and general paths (Path2D). The former approach was based on the simple convex hull of curves (enclosing control points) but I agree it is sub-optimal for curves.
To obtain the more-close bounding box, finding curve extrema (cubic or quad only) is necessary, so I agree the problem consists in finding roots of the (dx/dy) curve that is:
- a 2nd order polynom for cubic curves,
- a 1th order polynom for quad curves.

1. I agree CubicCurve2D and QuadCurve2D should be improved too.
2. I looked at your code and tried to compare your approach with the Marlin renderer. 
It looks very similar. See Curve / Helpers class:
https://github.com/openjdk/jdk/blob/684edbb4c884cbc3e05118e4bc9808b5d5b71a74/src/java.desktop/share/classes/sun/java2d/marlin/Curve.java#L115
https://github.com/openjdk/jdk/blob/684edbb4c884cbc3e05118e4bc9808b5d5b71a74/src/java.desktop/share/classes/sun/java2d/marlin/Helpers.java#L56

Your code converts any Cubic or Quad curve to a cubic equation (abcd coefficients) for both x / y equations, then you derive the dx/dy equations and finally find roots of the quadratic equations.
The Marlin renderer approach looks more direct:
- set curve (abcd coefficients + their derivatives da db)
- get derivative roots by calling dxRoots/dyRoots:

     int dxRoots(final double[] roots, final int off) {
        return Helpers.quadraticRoots(dax, dbx, cx, roots, off);
    }

used in Helpers.findSubdivPoints():
see https://github.com/openjdk/jdk/blob/684edbb4c884cbc3e05118e4bc9808b5d5b71a74/src/java.desktop/share/classes/sun/java2d/marlin/Helpers.java#L238

I suggest your solution could be more direct and rename Curve.getPossibleExtremaInCubicEquation() to Curve.findExtrema():
- use the convention t for the parametric variable x(t),y(t)
- determine the derivatives da / db
- solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
- degenerated cases are causing troubles: t must in ]0,1[ so do not use any threshold like 0.1 or 10^-4 like in Marlin.

Syntax / typos:
- always use braces for x = (a < b) ? ...
- always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)

Hope it helps,
Laurent

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

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


From duke at openjdk.java.net  Wed Nov  3 18:13:17 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Wed, 3 Nov 2021 18:13:17 GMT
Subject: RFR: 8185429: [macos] After the dialog is closed,
 there is no window become active. [v2]
In-Reply-To: <tEATq14iJT26W-MdZMdqyB9vIEVhyAElDvPoKndKkGs=.9a2c8c48-314f-47db-9dbd-f463fd137099@github.com>
References: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
 <tEATq14iJT26W-MdZMdqyB9vIEVhyAElDvPoKndKkGs=.9a2c8c48-314f-47db-9dbd-f463fd137099@github.com>
Message-ID: <7seVX_QYs2AUvF3iYY_1G7A9VjOeOsjsl1fB_DvCp_E=.328e826f-4344-4183-a36e-2d7878e675ed@github.com>

On Fri, 15 Oct 2021 17:05:10 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

>> After a modal dialog is closed, its parent window should be pushed to the front and made key.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replaced nativePushNSWindowToFront() with orderAboveSiblings()

@prrace @azvegint please review

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

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


From kizune at openjdk.java.net  Wed Nov  3 18:37:10 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 3 Nov 2021 18:37:10 GMT
Subject: RFR: 8169474: KeyCharTest: Wrong number of key events: 0
In-Reply-To: <cDgEIg0qebfhX6q7LGjRrjiqbIzZRbGJcRnJx1uR1hM=.d9ebc43b-f432-47d7-a6d5-7d071822e6d8@github.com>
References: <1fyY3RSMw8l0Xjcq3JFZ88qM7ert_bmJcnXPuW9qmNw=.09e8d110-40bd-4654-a268-40033ab93340@github.com>
 <cDgEIg0qebfhX6q7LGjRrjiqbIzZRbGJcRnJx1uR1hM=.d9ebc43b-f432-47d7-a6d5-7d071822e6d8@github.com>
Message-ID: <XjJ-ILvaoieyV32cJpFea-OpzpEQZmbm_xWBi6y_9k4=.106a6c0c-4380-4666-ac24-3cd271f1640b@github.com>

On Tue, 2 Nov 2021 03:13:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> When i reproduced the test failures locally on Ubuntu 18 it seems like AWT Frame
>> that appeared on the screen had not received focus and keyboard events went to the
>> Window Manager which ignored them for having no meaning in the current context.
>> Added explicit toFront and requestFocus calls so window gets focused.
>
> test/jdk/java/awt/event/KeyEvent/KeyChar/KeyCharTest.java line 90:
> 
>> 88:                     BufferedImage capture = robot.createScreenCapture(gd.getDefaultConfiguration().getBounds());
>> 89:                     File captureFile = new File("capture.png");
>> 90:                     ImageIO.write(capture, "png", captureFile);
> 
> Can you confirm this png gets written somewhere that isn't scratch spaced deleted at the end of testing ?
> I don't think we do this multi-screen dance in most tests since the default screen should be good enough.
> Why isn't it here ?

I can confirm that in case of the failure the file is accessible in the work directory for download. I added this multi-monitor just in case if test fails because window is in the strange spot on multi-monitor configuration so i want to capture which screen it is on. That's not necessary since in 99.99% cases it will stay on the default display, but it does not hurt either.

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

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


From lbourges at openjdk.java.net  Wed Nov  3 18:49:10 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 3 Nov 2021 18:49:10 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier pts
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <7EqTlgMDw0q1Qsy0EhBTlgDb5SJEdL-5vxJ72uL0XPw=.daffad27-3235-42a8-839e-13c507cfd934@github.com>

On Wed, 3 Nov 2021 07:27:03 GMT, Jeremy <duke at openjdk.java.net> wrote:

> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
> 
> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
> B. Updating the unit test to forgive the discrepancy.
> 
> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
> 
> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
> 
> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

First change the PR title to fix the bot warning: Title mismatch between PR and JBS for issue JDK-8176501

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

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


From duke at openjdk.java.net  Wed Nov  3 18:52:26 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Wed, 3 Nov 2021 18:52:26 GMT
Subject: RFR: 8233568: [TESTBUG] AWT event tests failing on MacOS
Message-ID: <wuww34-8VarDB4XRQ0sUI17MFpOyWa4DKOZSRckNcqo=.a72bed71-3776-4eab-8eca-e029bde09ed0@github.com>

Tests passing on macos, so removing from ProblemList

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

Commit messages:
 - 8233568: [TESTBUG] AWT event tests failing on MacOS

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

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


From duke at openjdk.java.net  Wed Nov  3 18:53:25 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Wed, 3 Nov 2021 18:53:25 GMT
Subject: RFR: 8233557: [TESTBUG] DoubleClickTitleBarTest.java fails on macOs
Message-ID: <FlbcsGEw0gRYy4oDcsVp_1RzCoIClrRjXgRj4GkoGzY=.3d5fd803-2ee0-4073-9624-7188eb834935@github.com>

test passed, removing from ProblemList.txt

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

Commit messages:
 - 8233557: [TESTBUG] DoubleClickTitleBarTest.java fails on macOs

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

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


From prr at openjdk.java.net  Wed Nov  3 19:14:09 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 3 Nov 2021 19:14:09 GMT
Subject: RFR: 8233557: [TESTBUG] DoubleClickTitleBarTest.java fails on
 macOs
In-Reply-To: <FlbcsGEw0gRYy4oDcsVp_1RzCoIClrRjXgRj4GkoGzY=.3d5fd803-2ee0-4073-9624-7188eb834935@github.com>
References: <FlbcsGEw0gRYy4oDcsVp_1RzCoIClrRjXgRj4GkoGzY=.3d5fd803-2ee0-4073-9624-7188eb834935@github.com>
Message-ID: <OjGFsBTQKHWGKWecHJSZqB_NR9FcLzCnACfwjSk6-0E=.28fc6426-a5b9-4c87-bcb3-ef0a05e610e2@github.com>

On Mon, 25 Oct 2021 18:07:15 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

> test passed, removing from ProblemList.txt

Was this verified in mach 5 ? How many times in a row did these tests pass ?

Was this verified in mach 5 ? How many times in a row did it pass ?

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

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


From avu at openjdk.java.net  Wed Nov  3 21:08:23 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 3 Nov 2021 21:08:23 GMT
Subject: RFR: JDK-8272392 Lanai: SwingSet2. Black background on expanding
 tree node
In-Reply-To: <TQsP5ddyfnqWKK4YVlTwqErFXRjdFGvfKhVuhbr9vQc=.0f9a0b06-696b-4fdf-95a2-a38e23f38408@github.com>
References: <TQsP5ddyfnqWKK4YVlTwqErFXRjdFGvfKhVuhbr9vQc=.0f9a0b06-696b-4fdf-95a2-a38e23f38408@github.com>
Message-ID: <0wyyN1xm9UJm1A6o-SABEgeHLRgKTOYcZ42v1pZiZtA=.14a314dd-24e5-4743-87db-50665481db5b@github.com>

On Sun, 10 Oct 2021 18:26:13 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Handled SRC composite mode in MTLBlitLoops_IsoBlit

I've found the actual reason for this problem. MTLBlitLoops_IsoBlit just copies texture with garbage inside. The garbage comes from deallocated MTLBuffer in replaceTextureRegion()

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

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


From avu at openjdk.java.net  Wed Nov  3 21:08:23 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 3 Nov 2021 21:08:23 GMT
Subject: Withdrawn: JDK-8272392 Lanai: SwingSet2. Black background on expanding
 tree node
In-Reply-To: <TQsP5ddyfnqWKK4YVlTwqErFXRjdFGvfKhVuhbr9vQc=.0f9a0b06-696b-4fdf-95a2-a38e23f38408@github.com>
References: <TQsP5ddyfnqWKK4YVlTwqErFXRjdFGvfKhVuhbr9vQc=.0f9a0b06-696b-4fdf-95a2-a38e23f38408@github.com>
Message-ID: <ShofzrGz02Ra7FfCUkWOmD3nuJHbSFAtixji02YynI8=.7767fa37-a69d-40f2-b21a-39a4be4229b7@github.com>

On Sun, 10 Oct 2021 18:26:13 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Handled SRC composite mode in MTLBlitLoops_IsoBlit

This pull request has been closed without being integrated.

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

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


From avu at openjdk.java.net  Wed Nov  3 21:45:30 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 3 Nov 2021 21:45:30 GMT
Subject: RFR: 8272392: Lanai: SwingSet2. Black background on expanding tree
 node
Message-ID: <1Oh8lq9xv8lYKhZhkRg5BICIimeW1_-9tX0v0P535SQ=.37d7e7ba-c0ae-4d9e-99bb-213eaba6cfc7@github.com>

Corrected memory allocation problem in replaceTextureRegion()

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

Commit messages:
 - 8272392: Lanai: SwingSet2. Black background on expanding tree node

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

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


From avu at openjdk.java.net  Wed Nov  3 21:51:17 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 3 Nov 2021 21:51:17 GMT
Subject: Withdrawn: 8272392: Lanai: SwingSet2. Black background on expanding
 tree node
In-Reply-To: <1Oh8lq9xv8lYKhZhkRg5BICIimeW1_-9tX0v0P535SQ=.37d7e7ba-c0ae-4d9e-99bb-213eaba6cfc7@github.com>
References: <1Oh8lq9xv8lYKhZhkRg5BICIimeW1_-9tX0v0P535SQ=.37d7e7ba-c0ae-4d9e-99bb-213eaba6cfc7@github.com>
Message-ID: <xi9FPZxFUbfdmuxiF9BVnrSGFcg0VHeLppKHfzBabeY=.6382070d-894b-48ca-90a0-3ad8413a7adf@github.com>

On Wed, 3 Nov 2021 21:38:41 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Corrected memory allocation problem in replaceTextureRegion()

This pull request has been closed without being integrated.

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

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


From serb at openjdk.java.net  Thu Nov  4 00:46:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 4 Nov 2021 00:46:37 GMT
Subject: RFR: 8275843: Random crashes while the UI code is executed
Message-ID: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>

Please take a look to one more wagon in this train:
[JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795)->[JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931)->[JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579)->[JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392)->[Current issue](https://bugs.openjdk.java.net/browse/JDK-8275843). 

#### The short description:

We have an inconsistent between xrender java code and the x11 window. The java code thinks that all our windows support only two types of color models: IntRgbX11 and IntArgbPreX11, but the x11 window supports more types. If such inconsistency occurs we render some garbage, or just crash since our "blits" will assume the wrong data layout. This issue was reported and fixed [before](http://hg.openjdk.java.net/jdk/jdk/rev/c53905e7dc57) but it was not realized why the rendering was wrong and that it can cause a crash. The fix is similar to the old one.

#### The long description:

 * Once upon a time this bug was filed [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) it was about the rendering of colors to the volatile image, the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8176795?focusedCommentId=14138323&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14138323) In short: the volatile images in the xrender use intArgbPre color model, it means that the SunGraphics2D object [convert](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1753) the argb value to the argbPre before passing it to the pipeline, and the xrender pipeline [convert](http://hg.openjdk.java.net/jdk/jdk/rev/e4b03365ddbf) this value to the argbPre one more time -> double-conversion-> the bug is reproduced. The fix for that bug disabled the second conversion in the xrender. but it does not take into account that this code path is use
 d for rendering to the ARGB X11 window where the shared code does not convert the color, so the next bug was filed.
 * The second bug is [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931), the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8204931?focusedCommentId=14199800&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14199800). In short the bug was about rendering directly to the window and missing color conversion removed previously. The fix for that bug changed the surface type used by the window, so the shared code start to convert the color from ARGB to argbPre, but it does not take into account that we do not control the color model of the window, see how many of them we actually [support](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceData.java#L501) Also note in the link above that if we do not recognize the type we do not fallback to something but throw InvalidPipeException, this is because the blits(and other primitives) may use thi
 s type to access the data directly. So the next bug was reported:
 * This is the third issue [JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579). The fix for that issue tried to roll back the previous one but does not take into account that the conversion removed by the first issue should be rollback as well, so the last bug was filed.
 * The "last" issue is [JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392) rollback the previous one. So the bug reported in the third report come back.

#### Fix description

The fix for the current issue contains a few parts:
 * Rollback of the [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931) so we will use the proper surface data for the window.
 * Return conversion in the xrender pipeline removed by the [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) So we will convert it when we render to the volatile image(argbPre) and to the window(argb). We need to convert in both cases since the xrender API which we use expects the argbPre colors.
 * Start to use the [eargb](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1752) value( instead of pixel) stored in the SunGraphics2D so we did not get the double conversion.

Some tests are updated and one more is added.

### Note
I have checked the performance implication of this change and it looks like after this change the sequence window.setvisible(true)/window.dispose() will work 30% faster, this may affect the tests which does not wait enough time to make the window visible. Probably this is the reason why some of our tests became more stable at some point in jdk11.


I have tested this by the jck and jdk_desktop tests. But any additional verification/testing is welcome.

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

Commit messages:
 - Merge branch 'master' into alpha
 - Merge branch 'master' into alpha
 - Update DrawCustomColorModel.java
 - fix space
 - Validate color for the new eargb only
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/6199/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6199&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275843
  Stats: 142 lines in 6 files changed: 91 ins; 19 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6199.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6199/head:pull/6199

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


From lbourges at openjdk.java.net  Thu Nov  4 09:44:14 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 4 Nov 2021 09:44:14 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <pMw7uETHZQ8IPuzP06nnPLvXjpgzeKdPrkbIRGve0gM=.c0a27502-d49f-462d-a54e-b1f5fab4dfe5@github.com>

On Wed, 3 Nov 2021 07:27:03 GMT, Jeremy <duke at openjdk.java.net> wrote:

> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
> 
> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
> B. Updating the unit test to forgive the discrepancy.
> 
> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
> 
> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
> 
> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

Jeremy, please enable github actions on your forked repository:
see https://wiki.openjdk.java.net/display/SKARA/Testing

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

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


From duke at openjdk.java.net  Thu Nov  4 20:46:13 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Thu, 4 Nov 2021 20:46:13 GMT
Subject: RFR: 8233557: [TESTBUG] DoubleClickTitleBarTest.java fails on
 macOs
In-Reply-To: <OjGFsBTQKHWGKWecHJSZqB_NR9FcLzCnACfwjSk6-0E=.28fc6426-a5b9-4c87-bcb3-ef0a05e610e2@github.com>
References: <FlbcsGEw0gRYy4oDcsVp_1RzCoIClrRjXgRj4GkoGzY=.3d5fd803-2ee0-4073-9624-7188eb834935@github.com>
 <OjGFsBTQKHWGKWecHJSZqB_NR9FcLzCnACfwjSk6-0E=.28fc6426-a5b9-4c87-bcb3-ef0a05e610e2@github.com>
Message-ID: <_lNTB4M9_CuJixTKh7sAt_gePISshW_kFKJxptfp_Ro=.78a9dbef-a963-4f31-bff3-60f1630918a1@github.com>

On Wed, 3 Nov 2021 19:11:15 GMT, Phil Race <prr at openjdk.org> wrote:

> Was this verified in mach 5 ? How many times in a row did it pass ?

The test passes

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

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


From prr at openjdk.java.net  Thu Nov  4 20:58:09 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 4 Nov 2021 20:58:09 GMT
Subject: RFR: 8233557: [TESTBUG] DoubleClickTitleBarTest.java fails on
 macOs
In-Reply-To: <FlbcsGEw0gRYy4oDcsVp_1RzCoIClrRjXgRj4GkoGzY=.3d5fd803-2ee0-4073-9624-7188eb834935@github.com>
References: <FlbcsGEw0gRYy4oDcsVp_1RzCoIClrRjXgRj4GkoGzY=.3d5fd803-2ee0-4073-9624-7188eb834935@github.com>
Message-ID: <3n2_jhUzvBoa1Fg84mlf9JiHjwOIvrmCuCzTo9yY8RU=.2abfde4e-d473-4b9e-b690-e78531e929aa@github.com>

On Mon, 25 Oct 2021 18:07:15 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

> test passed, removing from ProblemList.txt

Marked as reviewed by prr (Reviewer).

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

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


From serb at openjdk.java.net  Thu Nov  4 21:22:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 4 Nov 2021 21:22:10 GMT
Subject: RFR: 8169468: NoResizeEventOnDMChangeTest.java fails because FS
 Window didn't receive all resizes!
In-Reply-To: <4Ig_kkTRHkQaFpjKUnmerjDfD9ggdEuGcAf3Sfrdw08=.dbed9437-de40-4b05-892d-d18b8b3bd954@github.com>
References: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
 <KZ4Qk6OZ4u1oaky_ywd-eRJLhwNWVIqS_NsalpSwMP4=.59da0922-c57d-4cd2-990a-eb8c7f02e502@github.com>
 <_boEo0RRPZZQ4Bf4Lwe9sMf0YJ33JSApg_2-HB2lKis=.c045acdb-662e-4b68-9a93-6c22f6681d60@github.com>
 <tUaqwq_xewm0mS66byKEtEQP2_vwypi4C4f3Mq00S-4=.37c6c3b9-9fd2-494a-bb02-07bd4fd3f649@github.com>
 <4Ig_kkTRHkQaFpjKUnmerjDfD9ggdEuGcAf3Sfrdw08=.dbed9437-de40-4b05-892d-d18b8b3bd954@github.com>
Message-ID: <Az63FA3YHuzPkC4Ou3abjDMXS6t6_Q83g1VajY4oJuw=.bf37ad03-cbcd-4cce-85aa-4bff3cfed237@github.com>

On Wed, 3 Nov 2021 04:31:20 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> In the scenario above what will happen if the window is jumped from one screen to another? Will it be full screen or it will be in the normal mode? Which (old or new) graphics device will report that the window is full screen on it? I guess we should move the window back to the old device in full-screen mode, or we should move the window to the new device but in the normal mode, in both cases, the resize event should be generated, isn't it?
>
>> In the scenario above what will happen if the window is jumped from one screen to another? Will it be full screen or it will be in the normal mode? Which (old or new) graphics device will report that the window is full screen on it? I guess we should move the window back to the old device in full-screen mode, or we should move the window to the new device but in the normal mode, in both cases, the resize event should be generated, isn't it?
> 
> It opens up as a full screen window on the secondary display, i can't check which device reports it because when i add debug output i can not reproduce the failure. If two displays have different resolution then moving window from one GD to another it should generate the resize event on both window and the component inside it.

Then you can check that the window jumped to a different screen and the size counter should not be increased if the requested mode and the size of the new screen are the same. You do not need to skip the whole test in this case. But it also looks like a bug that the window is jumped to the other screen and is not returned back.

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

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


From serb at openjdk.java.net  Thu Nov  4 21:35:13 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 4 Nov 2021 21:35:13 GMT
Subject: RFR: 8169474: KeyCharTest: Wrong number of key events: 0
In-Reply-To: <XjJ-ILvaoieyV32cJpFea-OpzpEQZmbm_xWBi6y_9k4=.106a6c0c-4380-4666-ac24-3cd271f1640b@github.com>
References: <1fyY3RSMw8l0Xjcq3JFZ88qM7ert_bmJcnXPuW9qmNw=.09e8d110-40bd-4654-a268-40033ab93340@github.com>
 <cDgEIg0qebfhX6q7LGjRrjiqbIzZRbGJcRnJx1uR1hM=.d9ebc43b-f432-47d7-a6d5-7d071822e6d8@github.com>
 <XjJ-ILvaoieyV32cJpFea-OpzpEQZmbm_xWBi6y_9k4=.106a6c0c-4380-4666-ac24-3cd271f1640b@github.com>
Message-ID: <mnNNj3csraxkg3TPmaJ3_dhPpGTnu4ch87DK--M4gY8=.7f04a847-ceaf-45fb-9eb4-c95dac7fd6e4@github.com>

On Wed, 3 Nov 2021 18:34:33 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> test/jdk/java/awt/event/KeyEvent/KeyChar/KeyCharTest.java line 90:
>> 
>>> 88:                     BufferedImage capture = robot.createScreenCapture(gd.getDefaultConfiguration().getBounds());
>>> 89:                     File captureFile = new File("capture.png");
>>> 90:                     ImageIO.write(capture, "png", captureFile);
>> 
>> Can you confirm this png gets written somewhere that isn't scratch spaced deleted at the end of testing ?
>> I don't think we do this multi-screen dance in most tests since the default screen should be good enough.
>> Why isn't it here ?
>
> I can confirm that in case of the failure the file is accessible in the work directory for download. I added this multi-monitor just in case if test fails because window is in the strange spot on multi-monitor configuration so i want to capture which screen it is on. That's not necessary since in 99.99% cases it will stay on the default display, but it does not hurt either.

You can ask the GraphcsDevice where the Frame is located from the Frame itself, not necessary to check the bounds etc.

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

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


From serb at openjdk.java.net  Thu Nov  4 21:35:12 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 4 Nov 2021 21:35:12 GMT
Subject: RFR: 8169474: KeyCharTest: Wrong number of key events: 0
In-Reply-To: <1fyY3RSMw8l0Xjcq3JFZ88qM7ert_bmJcnXPuW9qmNw=.09e8d110-40bd-4654-a268-40033ab93340@github.com>
References: <1fyY3RSMw8l0Xjcq3JFZ88qM7ert_bmJcnXPuW9qmNw=.09e8d110-40bd-4654-a268-40033ab93340@github.com>
Message-ID: <zkDS_bxrYVZYpdTo4kS7o-9Azhk6c--UNHtuQRlBd24=.ec3b2df7-9b94-48dc-92b3-452d329ddcba@github.com>

On Thu, 28 Oct 2021 17:02:45 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> When i reproduced the test failures locally on Ubuntu 18 it seems like AWT Frame
> that appeared on the screen had not received focus and keyboard events went to the
> Window Manager which ignored them for having no meaning in the current context.
> Added explicit toFront and requestFocus calls so window gets focused.

test/jdk/java/awt/event/KeyEvent/KeyChar/KeyCharTest.java line 48:

> 46: 
> 47:         Toolkit.getDefaultToolkit().addAWTEventListener(new AWTEventListener() {
> 48: 

This test was excluded on macOS because it leaves some buttons pressed. I think the reason was an exception on EDT, then the jtreg stops the test when we get an exception below but before we release the delete button on the main thread.

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

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


From duke at openjdk.java.net  Thu Nov  4 21:49:25 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Thu, 4 Nov 2021 21:49:25 GMT
Subject: RFR: 8233557: [TESTBUG] DoubleClickTitleBarTest.java fails on
 macOs [v2]
In-Reply-To: <FlbcsGEw0gRYy4oDcsVp_1RzCoIClrRjXgRj4GkoGzY=.3d5fd803-2ee0-4073-9624-7188eb834935@github.com>
References: <FlbcsGEw0gRYy4oDcsVp_1RzCoIClrRjXgRj4GkoGzY=.3d5fd803-2ee0-4073-9624-7188eb834935@github.com>
Message-ID: <yOZu71qmFydLwjOluStOA1M1i_m3cbbqrfGQ_4KAy-M=.e027ffd6-b8dc-4440-9e99-28dcb17f6323@github.com>

> test passed, removing from ProblemList.txt

Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - merged ProblemList
 - 8233557: [TESTBUG] DoubleClickTitleBarTest.java fails on macOs
   
   Reviewed-by: alichung

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

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

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


From duke at openjdk.java.net  Thu Nov  4 21:57:17 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Thu, 4 Nov 2021 21:57:17 GMT
Subject: Integrated: 8233557: [TESTBUG] DoubleClickTitleBarTest.java fails on
 macOs
In-Reply-To: <FlbcsGEw0gRYy4oDcsVp_1RzCoIClrRjXgRj4GkoGzY=.3d5fd803-2ee0-4073-9624-7188eb834935@github.com>
References: <FlbcsGEw0gRYy4oDcsVp_1RzCoIClrRjXgRj4GkoGzY=.3d5fd803-2ee0-4073-9624-7188eb834935@github.com>
Message-ID: <ij8YpD6AEY99ElwyKcFt8T7SiKw67eL7DiWdLGhWJMs=.779adaec-42ba-4bcd-8f97-a939fa634c7a@github.com>

On Mon, 25 Oct 2021 18:07:15 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

> test passed, removing from ProblemList.txt

This pull request has now been integrated.

Changeset: 7b1916ef
Author:    Alisen Chung <alisen.chung at oracle.com>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7b1916efda95a46439cf42e006593361d12a8823
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8233557: [TESTBUG] DoubleClickTitleBarTest.java fails on macOs

Reviewed-by: prr

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

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


From duke at openjdk.java.net  Fri Nov  5 04:41:34 2021
From: duke at openjdk.java.net (Jeremy)
Date: Fri, 5 Nov 2021 04:41:34 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>

> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
> 
> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
> B. Updating the unit test to forgive the discrepancy.
> 
> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
> 
> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
> 
> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

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

  8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
  
  Addressing some of Laurent's code review recommendations/comments:
  
  1. use the convention t for the parametric variable x(t),y(t)
  2. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
  3. always use braces for x = (a < b) ? ...
  4. always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)
  
  (There are two additional recommendations not in this commit that I'll ask about shortly.)
  
  See https://github.com/openjdk/jdk/pull/6227#issuecomment-959757954

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6227/files
  - new: https://git.openjdk.java.net/jdk/pull/6227/files/0da9594d..5a0e2bd0

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

  Stats: 84 lines in 2 files changed: 6 ins; 26 del; 52 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6227.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6227/head:pull/6227

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


From duke at openjdk.java.net  Fri Nov  5 04:49:09 2021
From: duke at openjdk.java.net (Jeremy)
Date: Fri, 5 Nov 2021 04:49:09 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
Message-ID: <6YZ10klkjmkjSrLhHTzAZIj7FD52g4Fm77ty_d4ECRo=.5d250d27-40b2-4a79-8854-d318479ce5d5@github.com>

On Fri, 5 Nov 2021 04:41:34 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   Addressing some of Laurent's code review recommendations/comments:
>   
>   1. use the convention t for the parametric variable x(t),y(t)
>   2. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
>   3. always use braces for x = (a < b) ? ...
>   4. always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)
>   
>   (There are two additional recommendations not in this commit that I'll ask about shortly.)
>   
>   See https://github.com/openjdk/jdk/pull/6227#issuecomment-959757954

Thanks for your feedback. I just pushed a commit addressing 4 of those points (and I turned on actions). Can you elaborate on these recommendations:

A. determine the derivatives da / db
B. degenerated cases are causing troubles: t must in ]0,1[ so do not use any threshold like 0.1 or 10^-4 like in Marlin.

I'm not sure what you mean. Especially regarding the second point: if there are known problem areas I'd like to represent them with a unit test. (By which I mean: if I can understand what we're talking about I'll be sure it's covered in a unit test or write a new one as needed.)

FWIW: this branch includes a new shape in the UnitTest.java class (an ellipse rotated 45 degrees) that should cover a novel degenerated cubic curve. In this case the coefficient for the t^3 term is *practically* zero. I can go into that more if you want, but I'm unclear if that's straying off-topic or not...

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

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


From lbourges at openjdk.java.net  Fri Nov  5 08:38:09 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 5 Nov 2021 08:38:09 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
Message-ID: <bf3al7LV7hPeZXDlzUHSv4rO9aC1cUORoCb5UjLEK6o=.d092a397-4828-48d2-850f-a28060a371ed@github.com>

On Fri, 5 Nov 2021 04:41:34 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   Addressing some of Laurent's code review recommendations/comments:
>   
>   1. use the convention t for the parametric variable x(t),y(t)
>   2. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
>   3. always use braces for x = (a < b) ? ...
>   4. always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)
>   
>   (There are two additional recommendations not in this commit that I'll ask about shortly.)
>   
>   See https://github.com/openjdk/jdk/pull/6227#issuecomment-959757954

First comments, I will review carefully the code changes later:
A. You should compute directly the curve derivatives ie da, db and const coefficients only, like my curve impl. 
Then the function findExtrema() becomes useless as QuadCurve2d.solveQuadratic() handles all cases (2nd & 1th order polynoms).
So your algo is:
- check endpoint bounds
- if line: done
- If cubic/quad: 
- get dx dy coeffs
- get roots 
- check roots in ]0 - 1 [, then compute point (cubic or quad), check point bounds

B. As you pointed out, degenerated cases are causing problems as computer precision is limited ~ 10^-15 x magnitude in double-precision ! If magnitude is 10^20, the ulp ~ 100 000 !

Solving roots and computing coeffs and points may give numerical errors ~ few ulps, so it may be necessary to refine roots...
I will check later numerical accuracy issues and how to minimize them.

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

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


From lbourges at openjdk.java.net  Fri Nov  5 08:59:11 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 5 Nov 2021 08:59:11 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
Message-ID: <fPr0dvgVI4NXHG_Iu0rpt3ahMqv-h84Or5CW5Jgh5-E=.fa3fb6c2-c5f9-4f72-9345-fdc619decf7a@github.com>

On Fri, 5 Nov 2021 04:41:34 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   Addressing some of Laurent's code review recommendations/comments:
>   
>   1. use the convention t for the parametric variable x(t),y(t)
>   2. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
>   3. always use braces for x = (a < b) ? ...
>   4. always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)
>   
>   (There are two additional recommendations not in this commit that I'll ask about shortly.)
>   
>   See https://github.com/openjdk/jdk/pull/6227#issuecomment-959757954

For math reference, this page explains how to use curve derivatives to find extrema:
https://pomax.github.io/bezierinfo/#extremities

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

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


From lbourges at openjdk.java.net  Fri Nov  5 10:08:20 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 5 Nov 2021 10:08:20 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
Message-ID: <CeEMRyzppq2-yaby7fFDWT3ekeWJfRfD3Sp-dhY3scA=.723fad96-6c84-4583-a691-57152e3ec3dc@github.com>

On Fri, 5 Nov 2021 04:41:34 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   Addressing some of Laurent's code review recommendations/comments:
>   
>   1. use the convention t for the parametric variable x(t),y(t)
>   2. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
>   3. always use braces for x = (a < b) ? ...
>   4. always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)
>   
>   (There are two additional recommendations not in this commit that I'll ask about shortly.)
>   
>   See https://github.com/openjdk/jdk/pull/6227#issuecomment-959757954

src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2105:

> 2103:         // define x and y parametric coefficients where:
> 2104:         // x(t) = x_coeff[0] + x_coeff[1] * t + x_coeff[2] * t^2 + x_coeff[3] * t^3
> 2105:         double[] x_coeff = new double[4];

make arrays final to be obvious (dirty arrays)

src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2118:

> 2116:         double lastY = 0.0;
> 2117: 
> 2118:         pathIteratorLoop : while (!pi.isDone()) {

remove the label `pathIteratorLoop` (trivial)

src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2152:

> 2150:             }
> 2151: 
> 2152:             // here's the slightly trickier part: examine quadratic and cubic

add a shortcut test for better readability:
`if ((type == PathIterator.SEG_QUADTO) || (type == PathIterator.SEG_CUBICTO)) {`

src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2155:

> 2153:             // segments for extrema where t is between (0, 1):
> 2154: 
> 2155:             boolean definedParametricEquations;

useless with the shortcut test

src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2159:

> 2157:                 definedParametricEquations = true;
> 2158: 
> 2159:                 x_coeff[3] = 0.0;

after computing coefficients (abcd), also compute (da db c) needed by root finding next

src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2188:

> 2186:                 for(int i = 0; i < tExtremaCount; i++) {
> 2187:                     double t = tExtrema[i];
> 2188:                     if (t > 0 && t < 1) {

use `if (t > 0.0 && t < 1.0) {`

src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2189:

> 2187:                     double t = tExtrema[i];
> 2188:                     if (t > 0 && t < 1) {
> 2189:                         double x = x_coeff[0] + t * (x_coeff[1] + t * (x_coeff[2] + t * x_coeff[3]));

using 3rd order polynom is only useful for cubic curves, for quads 2nd order is enough.
How to improve precision on (abcd) or (bcd) polynomial evaluation ?

src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2205:

> 2203:                 }
> 2204:             }
> 2205: 

close the shortcut test
`}`

src/java.desktop/share/classes/sun/awt/geom/Curve.java line 759:

> 757:         }
> 758: 
> 759:         if (coefficients[3] > -.01 && coefficients[3] < .01 && coefficients[2] != 0.0) {

do not test coefficients[3] within 0.1 !
Always use QuadCurve2D.solveQuadratic() that handles the case coefficient(x^2) = 0.
Finally this method findExtrema() is only necessary if control points (x or y) are given to determine the dx , dy polynoms and return roots... I prefer moving this code directly in getBounds2D() to have a more efficient implementation (= 1 method with 1 loop) to avoid allocation of the array double[] eqn = new double[].

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

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


From lbourges at openjdk.java.net  Fri Nov  5 10:15:14 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 5 Nov 2021 10:15:14 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
Message-ID: <ooo8nCYGmR7tnIimN9TnDnub6KQuGieTaFUL_X6vVKI=.14de86ed-0d8a-4e80-b93c-b2d462e8b0bb@github.com>

On Fri, 5 Nov 2021 04:41:34 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   Addressing some of Laurent's code review recommendations/comments:
>   
>   1. use the convention t for the parametric variable x(t),y(t)
>   2. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
>   3. always use braces for x = (a < b) ? ...
>   4. always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)
>   
>   (There are two additional recommendations not in this commit that I'll ask about shortly.)
>   
>   See https://github.com/openjdk/jdk/pull/6227#issuecomment-959757954

src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2171:

> 2169:                 definedParametricEquations = true;
> 2170: 
> 2171:                 x_coeff[3] = -lastX + 3.0 * coords[0] - 3.0 * coords[2] + coords[4];

To improve coefficient accuracy ~ few ulps, it should be written explicitely as differences (= vector notation).
See Marlin DCurve formula:

    void set(final double x1, final double y1,
             final double x2, final double y2,
             final double x3, final double y3,
             final double x4, final double y4)
    {
        final double dx32 = 3.0 * (x3 - x2);
        final double dx21 = 3.0 * (x2 - x1);
        ax = (x4 - x1) - dx32;  // A = P3 - P0 - 3 (P2 - P1) = (P3 - P0) + 3 (P1 - P2)
        bx = (dx32 - dx21);     // B = 3 (P2 - P1) - 3(P1 - P0) = 3 (P2 + P0) - 6 P1
        cx = dx21;              // C = 3 (P1 - P0)
        dx = x1;                // D = P0
        dax = 3.0 * ax;
        dbx = 2.0 * bx;

        final double dy32 = 3.0 * (y3 - y2);
        final double dy21 = 3.0 * (y2 - y1);
        ay = (y4 - y1) - dy32;
        by = (dy32 - dy21);
        cy = dy21;
        dy = y1;
        day = 3.0 * ay;
        dby = 2.0 * by;
    }

    void set(final double x1, final double y1,
             final double x2, final double y2,
             final double x3, final double y3)
    {
        final double dx21 = (x2 - x1);
        ax = 0.0;              // A = 0
        bx = (x3 - x2) - dx21;  // B = P3 - P0 - 2 P2
        cx = 2.0 * dx21;       // C = 2 (P2 - P1)
        dx = x1;                // D = P1
        dax = 0.0;
        dbx = 2.0 * bx;

        final double dy21 = (y2 - y1);
        ay = 0.0;
        by = (y3 - y2) - dy21;
        cy = 2.0 * dy21;
        dy = y1;
        day = 0.0;
        dby = 2.0 * by;
    }

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

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


From pbansal at openjdk.java.net  Fri Nov  5 10:35:30 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 5 Nov 2021 10:35:30 GMT
Subject: RFR: 8198626:
 java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac
Message-ID: <QUccyFKKaCbrwGgCHWtZKoA_4pGH1m6gROE0g70H4Ss=.6540a021-5fac-4e85-b9f3-3b9948692516@github.com>

Test java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac fails on Mac. The test fails on my local machine (macOS BigSur) always and on mach5 also. The test uses Robot for mouse clicks and there is no delay or autoDelay set on Robot.

The fix adds set autoDelay on the robot. Along with this, some other cleanup is done. The test passes after the changes on my local mac and mach5 (Link in the JBS)

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

Commit messages:
 - 8198626: java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac

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

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


From lbourges at openjdk.java.net  Fri Nov  5 10:48:12 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 5 Nov 2021 10:48:12 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <CeEMRyzppq2-yaby7fFDWT3ekeWJfRfD3Sp-dhY3scA=.723fad96-6c84-4583-a691-57152e3ec3dc@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
 <CeEMRyzppq2-yaby7fFDWT3ekeWJfRfD3Sp-dhY3scA=.723fad96-6c84-4583-a691-57152e3ec3dc@github.com>
Message-ID: <Avz2wQZCKv326m9PzSSHluqWfDYgNjW5itQZ3VX57Vg=.4b1f0f73-65c3-4cfc-81e8-75f513e5d1a0@github.com>

On Fri, 5 Nov 2021 09:59:09 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>>   
>>   Addressing some of Laurent's code review recommendations/comments:
>>   
>>   1. use the convention t for the parametric variable x(t),y(t)
>>   2. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
>>   3. always use braces for x = (a < b) ? ...
>>   4. always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)
>>   
>>   (There are two additional recommendations not in this commit that I'll ask about shortly.)
>>   
>>   See https://github.com/openjdk/jdk/pull/6227#issuecomment-959757954
>
> src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2118:
> 
>> 2116:         double lastY = 0.0;
>> 2117: 
>> 2118:         pathIteratorLoop : while (!pi.isDone()) {
> 
> remove the label `pathIteratorLoop` (trivial)

I prefer also for loops:
for (final PathIterator it = shape.getPathIterator(null); !it.isDone(); it.next()) {
            int type = it.currentSegment(coords);
...
}

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

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


From lbourges at openjdk.java.net  Fri Nov  5 10:48:13 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 5 Nov 2021 10:48:13 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
Message-ID: <HUVQMS92Ro4IrBPqb7JQt8HbuOWx06TR6_GMEPxE6L4=.1685726a-bede-4050-892e-656cc1242fe1@github.com>

On Fri, 5 Nov 2021 04:41:34 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   Addressing some of Laurent's code review recommendations/comments:
>   
>   1. use the convention t for the parametric variable x(t),y(t)
>   2. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
>   3. always use braces for x = (a < b) ? ...
>   4. always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)
>   
>   (There are two additional recommendations not in this commit that I'll ask about shortly.)
>   
>   See https://github.com/openjdk/jdk/pull/6227#issuecomment-959757954

src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2135:

> 2133:                     endY = coords[5];
> 2134:                     break;
> 2135:                 default:

add explicitely the SEG_CLOSE case (skip = continue) before the default case (impossible case)

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

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


From lbourges at openjdk.java.net  Fri Nov  5 11:10:11 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 5 Nov 2021 11:10:11 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <CeEMRyzppq2-yaby7fFDWT3ekeWJfRfD3Sp-dhY3scA=.723fad96-6c84-4583-a691-57152e3ec3dc@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
 <CeEMRyzppq2-yaby7fFDWT3ekeWJfRfD3Sp-dhY3scA=.723fad96-6c84-4583-a691-57152e3ec3dc@github.com>
Message-ID: <7FgkHca8tdzn8chwJ6RsYWyuFVmtAQOl3xN17BiFhrg=.924d80dc-3171-45b4-a601-448bf3194aca@github.com>

On Fri, 5 Nov 2021 10:05:41 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>>   
>>   Addressing some of Laurent's code review recommendations/comments:
>>   
>>   1. use the convention t for the parametric variable x(t),y(t)
>>   2. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
>>   3. always use braces for x = (a < b) ? ...
>>   4. always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)
>>   
>>   (There are two additional recommendations not in this commit that I'll ask about shortly.)
>>   
>>   See https://github.com/openjdk/jdk/pull/6227#issuecomment-959757954
>
> src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2189:
> 
>> 2187:                     double t = tExtrema[i];
>> 2188:                     if (t > 0 && t < 1) {
>> 2189:                         double x = x_coeff[0] + t * (x_coeff[1] + t * (x_coeff[2] + t * x_coeff[3]));
> 
> using 3rd order polynom is only useful for cubic curves, for quads 2nd order is enough.
> How to improve precision on (abcd) or (bcd) polynomial evaluation ?

Ideally the compensated-horner scheme should be used to guarantee optimal precision (2x slower):
paper: 
https://www-pequan.lip6.fr/~jmc/polycopies/Compensation-horner.pdf

See julia code: 
https://discourse.julialang.org/t/more-accurate-evalpoly/45932/6

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

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


From myano at openjdk.java.net  Fri Nov  5 12:24:14 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 5 Nov 2021 12:24:14 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails [v2]
In-Reply-To: <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>
 <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
Message-ID: <G5_FvdQcECgNHrsBJVUzYYkps-lnQjAK3iO1r6JQma0=.0b2ab911-56c7-48bb-ab71-34d99b30f909@github.com>

On Tue, 26 Oct 2021 04:52:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Masanori Yano 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:
>> 
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - Merge branch 'master' of https://github.com/masyano/jdk into 7001973
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>
> I'll check it, let me some time.

@mrserb Could you please reply to the above comment?

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

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


From myano at openjdk.java.net  Fri Nov  5 12:30:17 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 5 Nov 2021 12:30:17 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <aZX6pJkrGOTYLlAHRl9WlEGtoahiInx4QzelDWpV2b0=.c9a736f9-5dd5-4382-8513-94a0233105dc@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <-hj0v7RZ0HPpP9GND5csZsZ1Vz7oxaufOAC0-ZygtwM=.6a5ae7a8-52d6-4e3e-a166-2fae2c23dbe0@github.com>
 <cTqTWZsK6uJI_Kw9nUymKQnYxxzWBRrk52qJAKpAc9I=.18f7dffd-3ebe-4bd0-bc2f-d61b55437036@github.com>
 <aZX6pJkrGOTYLlAHRl9WlEGtoahiInx4QzelDWpV2b0=.c9a736f9-5dd5-4382-8513-94a0233105dc@github.com>
Message-ID: <AZSTQLLRsOIxaEO3wtGdEgp2VPWduQY7FNVhcBg4LD0=.195929f1-6eb6-46f8-bc43-22d9d9a05ab2@github.com>

On Thu, 28 Oct 2021 09:03:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yes, this run() is called on "D3D Screen Updater" thread. It is reasonable that a new PaintEvent is posted when SurfaceData is replaced on this thread. I would limit posting new PaintEvent via createGraphics() only.
>
> Probably I should clarify my question, you added a parameter to the validate method and pass the "true" so the "validate" method will post a paint event, but just a few lines below there is a comment that the next code line "sd.getPeer().replaceSurfaceDataLater();" also will post an event. Is the comment outdated, or we will post two of them?

@mrserb Could you please review and reply to the above comment?

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

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


From lbourges at openjdk.java.net  Fri Nov  5 15:15:15 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 5 Nov 2021 15:15:15 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
Message-ID: <d-czf-c1U5HzUtmFtGMgIGa0c_1zGP66KHnfz3kdH58=.a4dd5b01-1fba-4f0f-9c3a-51e710e14b50@github.com>

On Fri, 5 Nov 2021 04:41:34 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   Addressing some of Laurent's code review recommendations/comments:
>   
>   1. use the convention t for the parametric variable x(t),y(t)
>   2. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
>   3. always use braces for x = (a < b) ? ...
>   4. always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)
>   
>   (There are two additional recommendations not in this commit that I'll ask about shortly.)
>   
>   See https://github.com/openjdk/jdk/pull/6227#issuecomment-959757954

Finally I inspected OpenJFX code and Shape has such algorithm:
https://github.com/openjdk/jfx/blob/4d8e12d231476fe72742cf10c223d8baf5028677/modules/javafx.graphics/src/main/java/com/sun/javafx/geom/Shape.java#L1036

it looks very close to your approach, but I am not sure about precision or accuracy.

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

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


From duke at openjdk.java.net  Fri Nov  5 19:51:18 2021
From: duke at openjdk.java.net (Jeremy)
Date: Fri, 5 Nov 2021 19:51:18 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v3]
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <iaBKIcGhEkTuDmNN5LcfGcGWZxlY15V8TJUM-Izgcs0=.e8d00c34-1e83-4d77-a8cd-18cd423d776a@github.com>

> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
> 
> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
> B. Updating the unit test to forgive the discrepancy.
> 
> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
> 
> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
> 
> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

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

  8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
  
  Addressing more of Laurent's code review recommendations/comments:
  
  1. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
  
  (I was pleasantly surprised to see QuadCurve2D.solveQuadratic(..) does well for the unit test where the t^2 coefficient approaches zero. We still get an extra root, but it's greater than 10^13, so it is ignored by our (0,1) bounds check later.)
  
  2. determine the derivatives da / db
  
  We now define x_deriv_coeff and y_deriv_coeff.
  
  3. remove the label pathIteratorLoop
  
  4. use `for (final PathIterator it = shape.getPathIterator(null); !it.isDone(); it.next()) {`
  
  (The initial statement is empty in this case because PathIterator is an argument.)
  
  5. make arrays final to be obvious
  
  6. add a shortcut test for better readability / close the shortcut test
  
  7. after computing coefficients (abcd), also compute (da db c) needed by root finding next
  
  8. useless with the shortcut test (re "definedParametricEquations" boolean)
  
  9. use if (t > 0.0 && t < 1.0)
  
  (Sorry, that got lost in the prev refactor.)
  
  10. add explicitely the SEG_CLOSE case (skip = continue) before the default case
  
  This commit does not address comments about accuracy/precision. I'll explore those separately later.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6227/files
  - new: https://git.openjdk.java.net/jdk/pull/6227/files/5a0e2bd0..410cd6ce

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

  Stats: 121 lines in 2 files changed: 9 ins; 70 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6227.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6227/head:pull/6227

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


From lbourges at openjdk.java.net  Fri Nov  5 21:21:39 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 5 Nov 2021 21:21:39 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v3]
In-Reply-To: <iaBKIcGhEkTuDmNN5LcfGcGWZxlY15V8TJUM-Izgcs0=.e8d00c34-1e83-4d77-a8cd-18cd423d776a@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <iaBKIcGhEkTuDmNN5LcfGcGWZxlY15V8TJUM-Izgcs0=.e8d00c34-1e83-4d77-a8cd-18cd423d776a@github.com>
Message-ID: <26iLY0O57bsuCZDZGqpQneSTBaw310fDOcmrcd7-wL4=.04e68de6-d384-4cce-9d99-f56622a7e23e@github.com>

On Fri, 5 Nov 2021 19:51:18 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   Addressing more of Laurent's code review recommendations/comments:
>   
>   1. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
>   
>   (I was pleasantly surprised to see QuadCurve2D.solveQuadratic(..) does well for the unit test where the t^2 coefficient approaches zero. We still get an extra root, but it's greater than 10^13, so it is ignored by our (0,1) bounds check later.)
>   
>   2. determine the derivatives da / db
>   
>   We now define x_deriv_coeff and y_deriv_coeff.
>   
>   3. remove the label pathIteratorLoop
>   
>   4. use `for (final PathIterator it = shape.getPathIterator(null); !it.isDone(); it.next()) {`
>   
>   (The initial statement is empty in this case because PathIterator is an argument.)
>   
>   5. make arrays final to be obvious
>   
>   6. add a shortcut test for better readability / close the shortcut test
>   
>   7. after computing coefficients (abcd), also compute (da db c) needed by root finding next
>   
>   8. useless with the shortcut test (re "definedParametricEquations" boolean)
>   
>   9. use if (t > 0.0 && t < 1.0)
>   
>   (Sorry, that got lost in the prev refactor.)
>   
>   10. add explicitely the SEG_CLOSE case (skip = continue) before the default case
>   
>   This commit does not address comments about accuracy/precision. I'll explore those separately later.

Looks going in good shape !
I agree accuracy is tricky as bbox may be smaller (undershoot) than ideal curve as roots or computed points are approximations != exact values. Maybe adding a small margin could help ...

I noticed javafx uses an optimization to only process quad / cubic curves if control points are out of the current bbox,  it can reduce a lot the extra overhead to find extrema... if useless.
See the test:

if (bbox[0] > coords[0] || bbox[2] < coords[0] ||
                        bbox[0] > coords[2] || bbox[2] < coords[2])
                    {
                        accumulateCubic(bbox, 0, x0, coords[0], coords[2], x1);
                    }

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

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


From serb at openjdk.java.net  Mon Nov  8 04:27:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 8 Nov 2021 04:27:41 GMT
Subject: RFR: 8198626:
 java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac
In-Reply-To: <QUccyFKKaCbrwGgCHWtZKoA_4pGH1m6gROE0g70H4Ss=.6540a021-5fac-4e85-b9f3-3b9948692516@github.com>
References: <QUccyFKKaCbrwGgCHWtZKoA_4pGH1m6gROE0g70H4Ss=.6540a021-5fac-4e85-b9f3-3b9948692516@github.com>
Message-ID: <I09v8I95RyVGL2AgudR6TdfQxK1oe4GSbN6vIzMTU6Q=.7f435229-901b-4948-a6f5-1022671a88d8@github.com>

On Fri, 5 Nov 2021 10:26:07 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> Test java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac fails on Mac. The test fails on my local machine (macOS BigSur) always and on mach5 also. The test uses Robot for mouse clicks and there is no delay or autoDelay set on Robot.
> 
> The fix adds set autoDelay on the robot. Along with this, some other cleanup is done. The test passes after the changes on my local mac and mach5 (Link in the JBS)

test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.java line 119:

> 117:                 public void actionPerformed(ActionEvent e) {
> 118:                     System.err.println("B pressed");
> 119:                     d.setVisible(true);

I think the d.setVisible(true) will be blocked and the next "EventQueue.invokeLater" will be executed after the dialog will be closed, unlike the old code where the invokeLater was executed after dialog became visible.

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

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


From serb at openjdk.java.net  Mon Nov  8 04:35:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 8 Nov 2021 04:35:37 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the
 java.util.logging
In-Reply-To: <DHI5YMCid9Tv-5Fd4KuFDA6i8GXIn0t5FJRGciK3KIE=.76d5b585-ec04-4d7e-8364-e2f07d888df4@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
 <DHI5YMCid9Tv-5Fd4KuFDA6i8GXIn0t5FJRGciK3KIE=.76d5b585-ec04-4d7e-8364-e2f07d888df4@github.com>
Message-ID: <3Syn0sjGIcKaxYy3wFdgsXE4UCxDTvG2YoY3iiEx4QI=.37471059-6ffb-4577-8f54-7bd38a281503@github.com>

On Fri, 29 Oct 2021 16:32:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The change looks okay. My suggestion is to get 1-6 all ready to push around the same time. It's okay to have separate JBS issues and PRs.

ok, I'll continue to work using the plan from the description.

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

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


From serb at openjdk.java.net  Mon Nov  8 06:08:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 8 Nov 2021 06:08:07 GMT
Subject: RFR: 8276794: Change nested classes in java.desktop to static
 nested classes
In-Reply-To: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
Message-ID: <xvbPBOA3Ki-QU1wXE8zPURCluZXWpiOQNhRtFlbIwq4=.5e622a74-60f8-46f2-b0db-c0e01ab79350@github.com>

On Thu, 14 Oct 2021 07:47:33 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)

Changes looks fine.

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

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


From duke at openjdk.java.net  Mon Nov  8 06:08:06 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 8 Nov 2021 06:08:06 GMT
Subject: RFR: 8276794: Change nested classes in java.desktop to static nested
 classes
Message-ID: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>

Non-static classes hold a link to their parent classes, which in many cases can be avoided.
I updated only private and package-private classes. Didn't touch public/protected to not break external code.
Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)

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

Commit messages:
 - [PATCH] Change nested classes in java.desktop to static nested classes

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

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


From psadhukhan at openjdk.java.net  Mon Nov  8 08:05:51 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 8 Nov 2021 08:05:51 GMT
Subject: RFR: 8276679: Malformed Javadoc inline tags in JDK source in
 javax/swing
Message-ID: <V7G2CnK7rFu8LIUpyZF0BZBC5Jhdrj4r5ubKNNywvoI=.bbc579a5-1cdd-4827-a752-916f90874d0f@github.com>

Fixed multiple malformed Javadoc inline tags where the `@` is placed in front of the opening curly bracket (instead of behind).

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

Commit messages:
 - 8276679: Malformed Javadoc inline tags in JDK source in javax/swing

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

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


From duke at openjdk.java.net  Mon Nov  8 09:19:48 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Mon, 8 Nov 2021 09:19:48 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html
Message-ID: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>

This change introduces no visual difference, but improves a11y.

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

Commit messages:
 - Fix table headers in NumericShaper.html

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

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


From psadhukhan at openjdk.java.net  Mon Nov  8 11:56:36 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 8 Nov 2021 11:56:36 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v3]
In-Reply-To: <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
Message-ID: <V_OdeRV0Zk7fy32nVnrQMna99sgTMf94z306oas9nWc=.54832411-541e-44ef-bead-1603ae9f63ee@github.com>

On Fri, 29 Oct 2021 06:43:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review fix
>  - Fix

I have removed the tolerance change and PL-ed the test....Any more comments on this PR?

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

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


From pbansal at openjdk.java.net  Mon Nov  8 12:22:07 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 8 Nov 2021 12:22:07 GMT
Subject: RFR: 8198626:
 java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac
 [v2]
In-Reply-To: <QUccyFKKaCbrwGgCHWtZKoA_4pGH1m6gROE0g70H4Ss=.6540a021-5fac-4e85-b9f3-3b9948692516@github.com>
References: <QUccyFKKaCbrwGgCHWtZKoA_4pGH1m6gROE0g70H4Ss=.6540a021-5fac-4e85-b9f3-3b9948692516@github.com>
Message-ID: <xz0M7OpieAOp5zxeTZI5Sevuo_--t1b3lXJeoNPWWQ8=.cc7d015b-0af7-4de4-955a-6750440ace90@github.com>

> Test java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac fails on Mac. The test fails on my local machine (macOS BigSur) always and on mach5 also. The test uses Robot for mouse clicks and there is no delay or autoDelay set on Robot.
> 
> The fix adds set autoDelay on the robot. Along with this, some other cleanup is done. The test passes after the changes on my local mac and mach5 (Link in the JBS)

Pankaj Bansal has updated the pull request incrementally with two additional commits since the last revision:

 - Review comments
 - Review Comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6273/files
  - new: https://git.openjdk.java.net/jdk/pull/6273/files/841ecaa8..c98c3793

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

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

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


From shade at openjdk.java.net  Mon Nov  8 13:20:50 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 8 Nov 2021 13:20:50 GMT
Subject: RFR: 8276805: java/awt/print/PrinterJob/CheckPrivilege.java fails due
 to disabled SecurityManager
Message-ID: <9q-Pbq4hsAxcRRzVBKTMu3DLnY-Pgczz_6ZEqL1U6ok=.76ab3fd1-8183-4882-bcca-af4ea4e7a971@github.com>

Current test fails on SecurityManager installation. See the bug for failure details. The fix is to allow SM for this test, until SM is removed wholesale.

Additional testing:
 - [x] Affected test now passes

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

Commit messages:
 - Fix

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

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


From duke at openjdk.java.net  Mon Nov  8 13:58:44 2021
From: duke at openjdk.java.net (Nikita Gubarkov)
Date: Mon, 8 Nov 2021 13:58:44 GMT
Subject: RFR: 8269806: Emoji rendering on Linux
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <DtY15IZ41-BXKg0guB1NrYP8DuqcC6_S6bxQokcmxPI=.513e647a-e5e3-47fb-8983-19ae278609dc@github.com>

On Thu, 15 Jul 2021 17:29:01 GMT, Nikita Gubarkov <duke at openjdk.java.net> 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

Hi! Sorry, just was busy with other work, but I'm going to get back to this in 1-2 weeks. BTW in the meantime I implemented emoji for JetBrains Runtime on Windows and will create a PR here after I deal with this one.

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

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


From pbansal at openjdk.java.net  Mon Nov  8 14:05:34 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 8 Nov 2021 14:05:34 GMT
Subject: RFR: 8198626:
 java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac
 [v2]
In-Reply-To: <I09v8I95RyVGL2AgudR6TdfQxK1oe4GSbN6vIzMTU6Q=.7f435229-901b-4948-a6f5-1022671a88d8@github.com>
References: <QUccyFKKaCbrwGgCHWtZKoA_4pGH1m6gROE0g70H4Ss=.6540a021-5fac-4e85-b9f3-3b9948692516@github.com>
 <I09v8I95RyVGL2AgudR6TdfQxK1oe4GSbN6vIzMTU6Q=.7f435229-901b-4948-a6f5-1022671a88d8@github.com>
Message-ID: <GKEJ1dm6iy5SmLqrFdTN1U5o27wojOVO_j0oggMuKgM=.357dc5b4-5b4b-4063-840e-737e2e71fdc0@github.com>

On Mon, 8 Nov 2021 04:24:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Pankaj Bansal has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Review comments
>>  - Review Comments
>
> test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.java line 119:
> 
>> 117:                 public void actionPerformed(ActionEvent e) {
>> 118:                     System.err.println("B pressed");
>> 119:                     d.setVisible(true);
> 
> I think the d.setVisible(true) will be blocked and the next "EventQueue.invokeLater" will be executed after the dialog will be closed, unlike the old code where the invokeLater was executed after dialog became visible.

Yes, looks like that. I have reverted this change and ran the test in CI multiple times. Link in JBS

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

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


From aivanov at openjdk.java.net  Mon Nov  8 15:00:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 8 Nov 2021 15:00:39 GMT
Subject: RFR: 8276679: Malformed Javadoc inline tags in JDK source in
 javax/swing
In-Reply-To: <V7G2CnK7rFu8LIUpyZF0BZBC5Jhdrj4r5ubKNNywvoI=.bbc579a5-1cdd-4827-a752-916f90874d0f@github.com>
References: <V7G2CnK7rFu8LIUpyZF0BZBC5Jhdrj4r5ubKNNywvoI=.bbc579a5-1cdd-4827-a752-916f90874d0f@github.com>
Message-ID: <facSFBsmPUB5CBqhonYebhlEgt9a66DrVnjrgPjVw7o=.81557d3a-593b-4d9c-aaa1-363ddd976e51@github.com>

On Mon, 8 Nov 2021 07:56:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fixed multiple malformed Javadoc inline tags where the `@` is placed in front of the opening curly bracket (instead of behind).

Marked as reviewed by aivanov (Reviewer).

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

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


From pbansal at openjdk.java.net  Mon Nov  8 15:39:32 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 8 Nov 2021 15:39:32 GMT
Subject: RFR: 8276679: Malformed Javadoc inline tags in JDK source in
 javax/swing
In-Reply-To: <V7G2CnK7rFu8LIUpyZF0BZBC5Jhdrj4r5ubKNNywvoI=.bbc579a5-1cdd-4827-a752-916f90874d0f@github.com>
References: <V7G2CnK7rFu8LIUpyZF0BZBC5Jhdrj4r5ubKNNywvoI=.bbc579a5-1cdd-4827-a752-916f90874d0f@github.com>
Message-ID: <FaN2AnfZuUZUSBuu3kWzrZgrxxy_axID2WZoC1jvlQ8=.8335eed1-f46c-42f4-a7e3-2d7ace87eb69@github.com>

On Mon, 8 Nov 2021 07:56:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fixed multiple malformed Javadoc inline tags where the `@` is placed in front of the opening curly bracket (instead of behind).

Marked as reviewed by pbansal (Reviewer).

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

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


From duke at openjdk.java.net  Mon Nov  8 17:17:00 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Mon, 8 Nov 2021 17:17:00 GMT
Subject: RFR: 8276678: Malformed Javadoc inline tags in JDK source in
 com/sun/beans/decoder/DocumentHandler.java
Message-ID: <Cj5hn3zbefTQkuvrEF_vDvCEQVEVu3bpDl7_mJRiDD0=.066875af-5883-4aaa-bc4d-05af0798902c@github.com>

fixed malformed inline tags

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

Commit messages:
 - 8276678: Malformed Javadoc inline tags in JDK source in com/sun/beans/decoder/DocumentHandler.java

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

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


From aivanov at openjdk.java.net  Mon Nov  8 18:27:33 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 8 Nov 2021 18:27:33 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html
In-Reply-To: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
Message-ID: <-mPmS4DOUQJOPOXW78o387Pvln3o3UHsJh5JSfq13aM=.77126688-c532-45db-9e38-f2246b30b5c1@github.com>

On Mon, 8 Nov 2021 09:13:35 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> This change introduces no visual difference, but improves a11y.

Ludvig, could you please elaborate on how this change improves accessibility?

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

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


From serb at openjdk.java.net  Mon Nov  8 18:48:32 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 8 Nov 2021 18:48:32 GMT
Subject: RFR: 8276678: Malformed Javadoc inline tags in JDK source in
 com/sun/beans/decoder/DocumentHandler.java
In-Reply-To: <Cj5hn3zbefTQkuvrEF_vDvCEQVEVu3bpDl7_mJRiDD0=.066875af-5883-4aaa-bc4d-05af0798902c@github.com>
References: <Cj5hn3zbefTQkuvrEF_vDvCEQVEVu3bpDl7_mJRiDD0=.066875af-5883-4aaa-bc4d-05af0798902c@github.com>
Message-ID: <CodQO7YtQT-QEc3BCakskcBQegreETX0yzPjLUppgCU=.fce4d8f4-2a5a-4c31-b3c7-15af1448399d@github.com>

On Mon, 8 Nov 2021 17:08:36 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

> fixed malformed inline tags

Please check other classes in the jdk desktop module as well. There are 7 such issues.

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

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


From aivanov at openjdk.java.net  Mon Nov  8 19:03:34 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 8 Nov 2021 19:03:34 GMT
Subject: RFR: 8276678: Malformed Javadoc inline tags in JDK source in
 com/sun/beans/decoder/DocumentHandler.java
In-Reply-To: <CodQO7YtQT-QEc3BCakskcBQegreETX0yzPjLUppgCU=.fce4d8f4-2a5a-4c31-b3c7-15af1448399d@github.com>
References: <Cj5hn3zbefTQkuvrEF_vDvCEQVEVu3bpDl7_mJRiDD0=.066875af-5883-4aaa-bc4d-05af0798902c@github.com>
 <CodQO7YtQT-QEc3BCakskcBQegreETX0yzPjLUppgCU=.fce4d8f4-2a5a-4c31-b3c7-15af1448399d@github.com>
Message-ID: <cDut_0cyvuzkE2Ugt_GCzR-leYgp3DDGd_-56kYxZHE=.6592a742-e89d-4151-925f-1b1e17708f05@github.com>

On Mon, 8 Nov 2021 18:45:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please check other classes in the jdk desktop module as well. There are 7 such issues.

A similar issue is being reviewed as #6290, it includes 4 files.
Are these split between JBS subcomponents?

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

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


From serb at openjdk.java.net  Mon Nov  8 19:13:34 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 8 Nov 2021 19:13:34 GMT
Subject: RFR: 8276679: Malformed Javadoc inline tags in JDK source in
 javax/swing
In-Reply-To: <V7G2CnK7rFu8LIUpyZF0BZBC5Jhdrj4r5ubKNNywvoI=.bbc579a5-1cdd-4827-a752-916f90874d0f@github.com>
References: <V7G2CnK7rFu8LIUpyZF0BZBC5Jhdrj4r5ubKNNywvoI=.bbc579a5-1cdd-4827-a752-916f90874d0f@github.com>
Message-ID: <wipnykRtWKrohYOT7bZFtbrRtKpvpDNVdy0Ooi0z7oI=.3d6ebac6-6ac4-4205-a1ec-89d99b903005@github.com>

On Mon, 8 Nov 2021 07:56:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fixed multiple malformed Javadoc inline tags where the `@` is placed in front of the opening curly bracket (instead of behind).

Probably I have asked this in some other PR, did you check all JDK desktop module for the same typos?

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

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


From aivanov at openjdk.java.net  Mon Nov  8 19:18:37 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 8 Nov 2021 19:18:37 GMT
Subject: RFR: 8276679: Malformed Javadoc inline tags in JDK source in
 javax/swing
In-Reply-To: <wipnykRtWKrohYOT7bZFtbrRtKpvpDNVdy0Ooi0z7oI=.3d6ebac6-6ac4-4205-a1ec-89d99b903005@github.com>
References: <V7G2CnK7rFu8LIUpyZF0BZBC5Jhdrj4r5ubKNNywvoI=.bbc579a5-1cdd-4827-a752-916f90874d0f@github.com>
 <wipnykRtWKrohYOT7bZFtbrRtKpvpDNVdy0Ooi0z7oI=.3d6ebac6-6ac4-4205-a1ec-89d99b903005@github.com>
Message-ID: <H8OR1dJV4GkcpdH5SEX246wYvvbuhZALg_N5WmjoNBg=.e8739447-6f26-4ce2-9686-8b5ebdef8de7@github.com>

On Mon, 8 Nov 2021 19:10:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Probably I have asked this in some other PR, did you check all JDK desktop module for the same typos?

You did.

I can see 10 clones of [JDK-8276686](https://bugs.openjdk.java.net/browse/JDK-8276686) for different areas of the JDK. Likely the updates are separated by subcomponent.

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

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


From serb at openjdk.java.net  Mon Nov  8 19:21:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 8 Nov 2021 19:21:37 GMT
Subject: RFR: 8276805: java/awt/print/PrinterJob/CheckPrivilege.java fails
 due to disabled SecurityManager
In-Reply-To: <9q-Pbq4hsAxcRRzVBKTMu3DLnY-Pgczz_6ZEqL1U6ok=.76ab3fd1-8183-4882-bcca-af4ea4e7a971@github.com>
References: <9q-Pbq4hsAxcRRzVBKTMu3DLnY-Pgczz_6ZEqL1U6ok=.76ab3fd1-8183-4882-bcca-af4ea4e7a971@github.com>
Message-ID: <T3L6tECdZ8YXjkss483DEwdc6gX9RYB6wYXz-O4h09Y=.1ba131e6-6bd4-4d9b-806c-0af389389fa8@github.com>

On Mon, 8 Nov 2021 13:13:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current test fails on SecurityManager installation. See the bug for failure details. The fix is to allow SM for this test, until SM is removed wholesale.
> 
> Additional testing:
>  - [x] Affected test now passes

Marked as reviewed by serb (Reviewer).

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

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


From kizune at openjdk.java.net  Mon Nov  8 22:32:59 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 8 Nov 2021 22:32:59 GMT
Subject: RFR: 8169468: NoResizeEventOnDMChangeTest.java fails because FS
 Window didn't receive all resizes! [v2]
In-Reply-To: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
References: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
Message-ID: <Q0KoI03rJu4gT5mVvH0xtzSJQcav4pdpkThkWAe2yZU=.dbf102ef-1368-439c-8356-35c1c0d27e96@github.com>

> I was able to reproduce this issue locally 2 times out of 100 runs on multi-monitor
> configuration. Both times due to the screen resolution change is so slow window got
> accidentally moved to the secondary screen by the display driver.
> Can not reproduce this bug with ATI card at all.
> Since there is nothing we can do to stop graphics driver from reassigning
> the window if it decides that promary monitor is not on at the moment the
> only way is to check if this has had happened and if so then we can not trust the test
> since we changing resolution of one display and window not getting resized
> because it is placed on another display and test should be skept.
> 
> After that i ran this test locally about a thousand times on all platforms
> and has not seen the failure again.

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

  Check that setting the new display mode ended up with window
  residing on the screen with resolution different than one it was before,
  even if it the different display - window and components still have to
  receive the resize event. Only skipping the iteration where that did not
  happened instead of skipping the entire test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6186/files
  - new: https://git.openjdk.java.net/jdk/pull/6186/files/cfd1efa4..da325c4f

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

  Stats: 20 lines in 1 file changed: 7 ins; 7 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6186.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6186/head:pull/6186

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


From kizune at openjdk.java.net  Mon Nov  8 22:32:59 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 8 Nov 2021 22:32:59 GMT
Subject: RFR: 8169468: NoResizeEventOnDMChangeTest.java fails because FS
 Window didn't receive all resizes! [v2]
In-Reply-To: <Az63FA3YHuzPkC4Ou3abjDMXS6t6_Q83g1VajY4oJuw=.bf37ad03-cbcd-4cce-85aa-4bff3cfed237@github.com>
References: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
 <KZ4Qk6OZ4u1oaky_ywd-eRJLhwNWVIqS_NsalpSwMP4=.59da0922-c57d-4cd2-990a-eb8c7f02e502@github.com>
 <_boEo0RRPZZQ4Bf4Lwe9sMf0YJ33JSApg_2-HB2lKis=.c045acdb-662e-4b68-9a93-6c22f6681d60@github.com>
 <tUaqwq_xewm0mS66byKEtEQP2_vwypi4C4f3Mq00S-4=.37c6c3b9-9fd2-494a-bb02-07bd4fd3f649@github.com>
 <4Ig_kkTRHkQaFpjKUnmerjDfD9ggdEuGcAf3Sfrdw08=.dbed9437-de40-4b05-892d-d18b8b3bd954@github.com>
 <Az63FA3YHuzPkC4Ou3abjDMXS6t6_Q83g1VajY4oJuw=.bf37ad03-cbcd-4cce-85aa-4bff3cfed237@github.com>
Message-ID: <ZlyeBTV2Yx-DroUDO3orkxOG-g61F5B8rrfxikmd6CU=.d4fa1c32-d6ec-4a90-900d-fc8f2869ce10@github.com>

On Thu, 4 Nov 2021 21:19:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Then you can check that the window jumped to a different screen and the size counter should not be increased if the requested mode and the size of the new screen are the same.

Ok, done exactly that.

> But it also looks like a bug that the window is jumped to the other screen and is not returned back.

Yes but that might be the issue with the Windows itself and i do not think there is anything that can be done on this test level.

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

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


From naoto at openjdk.java.net  Mon Nov  8 23:19:37 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 8 Nov 2021 23:19:37 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html
In-Reply-To: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
Message-ID: <EBik5K6eSZHvV0QnRlmMKyR7REyfRTUlyuW0RwpWkDs=.2d7baa5d-a53f-40f3-820a-9bd2bca6a452@github.com>

On Mon, 8 Nov 2021 09:13:35 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> This change introduces no visual difference, but improves a11y.

Marked as reviewed by naoto (Reviewer).

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

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


From duke at openjdk.java.net  Tue Nov  9 04:08:09 2021
From: duke at openjdk.java.net (Jeremy)
Date: Tue, 9 Nov 2021 04:08:09 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v4]
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <odXfn1vUD7JB-Q5xetNyIUlDkklrhxhcIJinreZEod8=.45c63cf7-58ed-4858-b6d8-1de6e976caff@github.com>

> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
> 
> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
> B. Updating the unit test to forgive the discrepancy.
> 
> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
> 
> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
> 
> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

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

  8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
  
  Addressing code review recommendation to copy javafx's optimization: we can avoid looking at the derivative and polynomial if the control points are inside our existing bounds. This involved refactoring the method getBounds2D(PathIterator) more generally. It should now be a little more efficient (and perhaps a little less readable). Since we don't have concrete performance or readability goals this is a subjective trade-off that's hard to assess.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6227/files
  - new: https://git.openjdk.java.net/jdk/pull/6227/files/410cd6ce..e617c722

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

  Stats: 179 lines in 1 file changed: 98 ins; 72 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6227.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6227/head:pull/6227

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


From mbaesken at openjdk.java.net  Tue Nov  9 08:05:57 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 9 Nov 2021 08:05:57 GMT
Subject: RFR: JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java
 shows JNI warning on Windows
Message-ID: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>

The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni to an awt related test, and shows on Windows server 2019 the following JNI warning , so the test  JNICheck/FreeTypeScalerJNICheck.java fails on this Windows version.

:stdErr:
Thu Oct 28 01:27:10 CEST 2021
stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV
               at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 18.0.0.1-internal/Native Method)
               at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:95)
               at sun.awt.Win32GraphicsEnvironment.<clinit>(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:63)
               at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 18.0.0.1-internal/PlatformGraphicsInfo.java:34)
               at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:93)
               at java.awt.GraphicsEnvironment$LocalGE.<clinit>(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:84)
               at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:106)
               at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53)
               at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)

We can get rid of the warning by adjusting a JNU_CallStaticMethodByName call in awt_Win32GraphicsEnv.cpp .

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

Commit messages:
 - JDK-8276809

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

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


From duke at openjdk.java.net  Tue Nov  9 10:03:14 2021
From: duke at openjdk.java.net (Jeremy)
Date: Tue, 9 Nov 2021 10:03:14 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v5]
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <MSkEUKcb6PeZ9IuHaoSOpaefJDdbViAxK0XAzb6vL-s=.02f4f130-d8c0-4b3c-a108-dcb5df7a129a@github.com>

> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
> 
> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
> B. Updating the unit test to forgive the discrepancy.
> 
> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
> 
> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
> 
> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

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

  8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
  
  Addressing code review recommendation to calculate polynomial coefficients using differences / vector notation.
  
  https://github.com/openjdk/jdk/pull/6227#discussion_r743534560
  
  I generally understand the intention of this change, but I don't know exactly how to test/evaluate it.
  
  The unit tests still pass. I ran some sample calculations involving a 100x100 Ellipse2D as it was rotated, and the two getBounds2D(..) implementations (before and after this commit) only differed by a few ulps (usually around 10^-15), as expected.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6227/files
  - new: https://git.openjdk.java.net/jdk/pull/6227/files/e617c722..b7ca69c8

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

  Stats: 19 lines in 1 file changed: 10 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6227.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6227/head:pull/6227

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


From duke at openjdk.java.net  Tue Nov  9 10:31:35 2021
From: duke at openjdk.java.net (Jeremy)
Date: Tue, 9 Nov 2021 10:31:35 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <7FgkHca8tdzn8chwJ6RsYWyuFVmtAQOl3xN17BiFhrg=.924d80dc-3171-45b4-a601-448bf3194aca@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
 <CeEMRyzppq2-yaby7fFDWT3ekeWJfRfD3Sp-dhY3scA=.723fad96-6c84-4583-a691-57152e3ec3dc@github.com>
 <7FgkHca8tdzn8chwJ6RsYWyuFVmtAQOl3xN17BiFhrg=.924d80dc-3171-45b4-a601-448bf3194aca@github.com>
Message-ID: <2qVmqXHwGTEu7-fREZKtL8CBTnkgTf2pDpA1rFo5CVI=.7868c3ec-d91c-4d31-9751-28750be11968@github.com>

On Fri, 5 Nov 2021 11:06:40 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2189:
>> 
>>> 2187:                     double t = tExtrema[i];
>>> 2188:                     if (t > 0 && t < 1) {
>>> 2189:                         double x = x_coeff[0] + t * (x_coeff[1] + t * (x_coeff[2] + t * x_coeff[3]));
>> 
>> using 3rd order polynom is only useful for cubic curves, for quads 2nd order is enough.
>> How to improve precision on (abcd) or (bcd) polynomial evaluation ?
>
> Ideally the compensated-horner scheme should be used to guarantee optimal precision (2x slower):
> paper: 
> https://www-pequan.lip6.fr/~jmc/polycopies/Compensation-horner.pdf
> 
> See julia code: 
> https://discourse.julialang.org/t/more-accurate-evalpoly/45932/6

I don't think I can implement that on my own. Even if I fully understood the julia code, I assume I'd want to use the Math.fma(..) method. That method uses BigDecimals, which I assume (?) we don't want to use in a loop like this for performance reasons.

If this level of high-precision is considered essential to resolving this bug: then personally I'm at an impasse and we should either close this PR or I'll need some external help.

Or possible compromises might include:

A. Add a method like this in Curve.java:

public double evaluateCubicPolynomial(double a, double b, double c, double d, double t) {
    return d + t * (c + t * (b + t * a)));
}


And add a ticket that someone else can address separately to improve the accuracy of that method. (Also maybe other areas in the AWT codebase should use the same method? Like `Order3#XforT`?)

B. We can modify my new method signature from:
`public static Rectangle2D getBounds2D(PathIterator pi)`
to:
`public static Rectangle2D getBounds2D(PathIterator pi, boolean highPrecision)`

Where if `highPrecision` is true we use the new implementation *which may suffer rounding errors and be a few ulps too small*. And if it is false then we use the old implementation which suffers from the original bug. This has the benefit of definitely not breaking any existing code in existence. The downside is it puts the responsibility on developers to learn about and implement this new method. But at least it would exist.

Thoughts?

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

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


From lbourges at openjdk.java.net  Tue Nov  9 10:37:40 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Tue, 9 Nov 2021 10:37:40 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v5]
In-Reply-To: <MSkEUKcb6PeZ9IuHaoSOpaefJDdbViAxK0XAzb6vL-s=.02f4f130-d8c0-4b3c-a108-dcb5df7a129a@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <MSkEUKcb6PeZ9IuHaoSOpaefJDdbViAxK0XAzb6vL-s=.02f4f130-d8c0-4b3c-a108-dcb5df7a129a@github.com>
Message-ID: <1bsoBtuyINX0C5ApYsOUoh78rEkjt4WEQumU4qf_pkk=.591c47a7-20b1-4dbf-a3d3-2b1d47345c4f@github.com>

On Tue, 9 Nov 2021 10:03:14 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   Addressing code review recommendation to calculate polynomial coefficients using differences / vector notation.
>   
>   https://github.com/openjdk/jdk/pull/6227#discussion_r743534560
>   
>   I generally understand the intention of this change, but I don't know exactly how to test/evaluate it.
>   
>   The unit tests still pass. I ran some sample calculations involving a 100x100 Ellipse2D as it was rotated, and the two getBounds2D(..) implementations (before and after this commit) only differed by a few ulps (usually around 10^-15), as expected.

Great !
I see many duplicated lines, probably it is time to add 2 small methods to processCubic() and processQuad() that can be called on x and y equations => only 2 arrays needed for coeff and deriv_coeff. 
Maybe I prefer the previous unified solution relying on QuadCurve2D.solveQuadratic() that handles both case.

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

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


From duke at openjdk.java.net  Tue Nov  9 10:46:40 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Tue, 9 Nov 2021 10:46:40 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html
In-Reply-To: <-mPmS4DOUQJOPOXW78o387Pvln3o3UHsJh5JSfq13aM=.77126688-c532-45db-9e38-f2246b30b5c1@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
 <-mPmS4DOUQJOPOXW78o387Pvln3o3UHsJh5JSfq13aM=.77126688-c532-45db-9e38-f2246b30b5c1@github.com>
Message-ID: <zyFv7EFnjc2cVTRCdClSs0l8Z8LV44T2csFBdrgjjPY=.978e4148-9621-47d7-a035-5d6e7c9dcc69@github.com>

On Mon, 8 Nov 2021 18:25:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This change introduces no visual difference, but improves a11y.
>
> Ludvig, could you please elaborate on how this change improves accessibility?

@aivanov-jdk Gladly. [Doccheck](https://openjdk.java.net/projects/code-tools/doccheck/) flagged it, my understanding is that every row needs to have a unique row header to aid screen readers. The previous code had one cell work as header for two rows. 

One could perhaps look at [the standards](https://html.spec.whatwg.org/multipage/tables.html#attr-tdth-headers) and implement something even better, but this is what I came up with.

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

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


From lbourges at openjdk.java.net  Tue Nov  9 10:46:39 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Tue, 9 Nov 2021 10:46:39 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <2qVmqXHwGTEu7-fREZKtL8CBTnkgTf2pDpA1rFo5CVI=.7868c3ec-d91c-4d31-9751-28750be11968@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
 <CeEMRyzppq2-yaby7fFDWT3ekeWJfRfD3Sp-dhY3scA=.723fad96-6c84-4583-a691-57152e3ec3dc@github.com>
 <7FgkHca8tdzn8chwJ6RsYWyuFVmtAQOl3xN17BiFhrg=.924d80dc-3171-45b4-a601-448bf3194aca@github.com>
 <2qVmqXHwGTEu7-fREZKtL8CBTnkgTf2pDpA1rFo5CVI=.7868c3ec-d91c-4d31-9751-28750be11968@github.com>
Message-ID: <xIRXpvayrwFFU_Wo5XoLtHeKb5HUqNxxLcW3dE1h9Cc=.a7b379fa-b418-48b0-8714-b8182f81f950@github.com>

On Tue, 9 Nov 2021 10:28:45 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> Ideally the compensated-horner scheme should be used to guarantee optimal precision (2x slower):
>> paper: 
>> https://www-pequan.lip6.fr/~jmc/polycopies/Compensation-horner.pdf
>> 
>> See julia code: 
>> https://discourse.julialang.org/t/more-accurate-evalpoly/45932/6
>
> I don't think I can implement that on my own. Even if I fully understood the julia code, I assume I'd want to use the Math.fma(..) method. That method uses BigDecimals, which I assume (?) we don't want to use in a loop like this for performance reasons.
> 
> If this level of high-precision is considered essential to resolving this bug: then personally I'm at an impasse and we should either close this PR or I'll need some external help.
> 
> Or possible compromises might include:
> 
> A. Add a method like this in Curve.java:
> 
> public double evaluateCubicPolynomial(double a, double b, double c, double d, double t) {
>     return d + t * (c + t * (b + t * a)));
> }
> 
> 
> And add a ticket that someone else can address separately to improve the accuracy of that method. (Also maybe other areas in the AWT codebase should use the same method? Like `Order3#XforT`?)
> 
> B. We can modify my new method signature from:
> `public static Rectangle2D getBounds2D(PathIterator pi)`
> to:
> `public static Rectangle2D getBounds2D(PathIterator pi, boolean highPrecision)`
> 
> Where if `highPrecision` is true we use the new implementation *which may suffer rounding errors and be a few ulps too small*. And if it is false then we use the old implementation which suffers from the original bug. This has the benefit of definitely not breaking any existing code in existence. The downside is it puts the responsibility on developers to learn about and implement this new method. But at least it would exist.
> 
> Thoughts?

I agree it is out of the scope of this issue to implement high-precision polynom evaluation (compensated horder scheme), that I or anybody else could implement it later.
To ensure bounds2D are enclosing the shape entirely, I propose to add a small margin (10 ulps or more) to ascertain precision is good enough.
To determine the precision level, using fuzzy testing is the good approach : generate lots ofrandom paths => check bounds2D accuracy in ulp units.

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

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


From aivanov at openjdk.java.net  Tue Nov  9 11:45:30 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 9 Nov 2021 11:45:30 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html
In-Reply-To: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
Message-ID: <I_SfCpSrHmO3ffkPZxJpw4aKKQp1U4CQX2-jM5LBzU4=.42d0331c-faab-44a7-9ccb-590e143213e5@github.com>

On Mon, 8 Nov 2021 09:13:35 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> This change introduces no visual difference, but improves a11y.

> /integrate

I believe this is preliminary as our discussion isn't over yet.

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

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


From aivanov at openjdk.java.net  Tue Nov  9 12:06:33 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 9 Nov 2021 12:06:33 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html
In-Reply-To: <I_SfCpSrHmO3ffkPZxJpw4aKKQp1U4CQX2-jM5LBzU4=.42d0331c-faab-44a7-9ccb-590e143213e5@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
 <I_SfCpSrHmO3ffkPZxJpw4aKKQp1U4CQX2-jM5LBzU4=.42d0331c-faab-44a7-9ccb-590e143213e5@github.com>
Message-ID: <7fBikeEmztWG1zJ_2wDb4KsIFNYUP559Hd4HYB2WB6c=.523f16c0-512d-49bc-822a-0aa9c0074de7@github.com>

On Tue, 9 Nov 2021 11:42:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This change introduces no visual difference, but improves a11y.
>
>> /integrate
> 
> I believe this is preliminary as our discussion isn't over yet.

> @aivanov-jdk Gladly. [Doccheck](https://openjdk.java.net/projects/code-tools/doccheck/) flagged it, my understanding is that every row needs to have a unique row header to aid screen readers. The previous code had one cell work as header for two rows.
> 
> One could perhaps look at [the standards](https://html.spec.whatwg.org/multipage/tables.html#attr-tdth-headers) and implement something even better, but this is what I came up with.

This information should be added both to the JBS bug description and to this PR description, otherwise this comes out of nowhere.

I think this approach is wrong. However, to satisfy this requirement of Doccheck dummy column with numbers was added to many tables which _logically_ have no row headers.

You change the semantics of the table by moving the header to another column. The rendering should rather change too, otherwise visual representation becomes misleading.

To me, the table looks correct currently: *Arabic* Unicode range serves as the title for both rows. I wonder how it's read by a screen reader: the original version and the updated version. What we should strive for is for clarity of the read table rather than blindly following the rule where each row should have a title, provided that the title is available in this particular case.

@jonathan-gibbons, Can this error be marked as false positive in the Doccheck report? Can the tool be smarter?

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

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


From duke at openjdk.java.net  Tue Nov  9 12:20:56 2021
From: duke at openjdk.java.net (Emmanuel Bourg)
Date: Tue, 9 Nov 2021 12:20:56 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes
Message-ID: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>

When a list of icons is set on a window, the most appropiate icon is selected depending on the graphics configuration. But if the graphics configuration changes (because the window is moved to a different screen, or because the DPI settings of the screen is changed), the frame icon isn't updated.

Here is an example illustrating the issue:

    public static void main(String[] args) throws Exception {
        SwingUtilities.invokeLater(() -> {
            JFrame frame = new JFrame("Window Icon Test");
            frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
            frame.setSize(400, 300);
            frame.setVisible(true);

            List<Image> images = new ArrayList<>();
            for (int size = 16; size <= 32; size++) {
                // create an image displaying the size used
                BufferedImage image = new BufferedImage(size, size, BufferedImage.TYPE_INT_ARGB);
                Graphics2D g = image.createGraphics();
                g.setFont(new Font("dialog", Font.BOLD, 12));
                g.setColor(Color.BLACK);
                g.drawString(String.valueOf(size), 0, size - (size - g.getFont().getSize()) / 2);
                images.add(image);
            }

            frame.setIconImages(images);
        });
    }

On Windows if the screen scaling is set to 100% the 16x16 icon is picked from the list. If the scaling of the screen is set to 150% while the application is running, the 16x16 icon is upscaled and looks blurry.

A way to work around this issue is to listen for graphics configuration changes with:

    frame.addPropertyChangeListener("graphicsConfiguration", event -> frame.setIconImages(frame.getIconImages()));


Ideally this should be done automatically by the JDK. Maybe the `WindowPeer` could call `updateIconImages()` when `updateGraphicsData()` or `displayChanged()` is invoked?

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

Commit messages:
 - Refresh the window icon on graphics configuration changes

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

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


From shade at openjdk.java.net  Tue Nov  9 12:20:56 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 9 Nov 2021 12:20:56 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes
In-Reply-To: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
Message-ID: <XTYoL7_gMY15S1sgmCHVY0lLyAbLmKkIoTMNElEs_Jk=.daca28c3-82f5-4040-a72f-01fba3760323@github.com>

On Sun, 31 Oct 2021 08:21:58 GMT, Emmanuel Bourg <duke at openjdk.java.net> wrote:

> When a list of icons is set on a window, the most appropiate icon is selected depending on the graphics configuration. But if the graphics configuration changes (because the window is moved to a different screen, or because the DPI settings of the screen is changed), the frame icon isn't updated.
> 
> Here is an example illustrating the issue:
> 
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeLater(() -> {
>             JFrame frame = new JFrame("Window Icon Test");
>             frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>             frame.setSize(400, 300);
>             frame.setVisible(true);
> 
>             List<Image> images = new ArrayList<>();
>             for (int size = 16; size <= 32; size++) {
>                 // create an image displaying the size used
>                 BufferedImage image = new BufferedImage(size, size, BufferedImage.TYPE_INT_ARGB);
>                 Graphics2D g = image.createGraphics();
>                 g.setFont(new Font("dialog", Font.BOLD, 12));
>                 g.setColor(Color.BLACK);
>                 g.drawString(String.valueOf(size), 0, size - (size - g.getFont().getSize()) / 2);
>                 images.add(image);
>             }
> 
>             frame.setIconImages(images);
>         });
>     }
> 
> On Windows if the screen scaling is set to 100% the 16x16 icon is picked from the list. If the scaling of the screen is set to 150% while the application is running, the 16x16 icon is upscaled and looks blurry.
> 
> A way to work around this issue is to listen for graphics configuration changes with:
> 
>     frame.addPropertyChangeListener("graphicsConfiguration", event -> frame.setIconImages(frame.getIconImages()));
> 
> 
> Ideally this should be done automatically by the JDK. Maybe the `WindowPeer` could call `updateIconImages()` when `updateGraphicsData()` or `displayChanged()` is invoked?

Submitted the bug for it, please change the PR title to "8276849: Refresh the window icon on graphics configuration changes" to get it hooked and resolve the jcheck complaint.

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

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


From duke at openjdk.java.net  Tue Nov  9 12:20:56 2021
From: duke at openjdk.java.net (Emmanuel Bourg)
Date: Tue, 9 Nov 2021 12:20:56 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes
In-Reply-To: <XTYoL7_gMY15S1sgmCHVY0lLyAbLmKkIoTMNElEs_Jk=.daca28c3-82f5-4040-a72f-01fba3760323@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
 <XTYoL7_gMY15S1sgmCHVY0lLyAbLmKkIoTMNElEs_Jk=.daca28c3-82f5-4040-a72f-01fba3760323@github.com>
Message-ID: <3U4MdctZRow1bcRa64EkcY0nUcOfO-NBtcLfqM7ULtI=.f8511272-bdff-4574-9feb-10a8f3daf891@github.com>

On Tue, 9 Nov 2021 11:17:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When a list of icons is set on a window, the most appropiate icon is selected depending on the graphics configuration. But if the graphics configuration changes (because the window is moved to a different screen, or because the DPI settings of the screen is changed), the frame icon isn't updated.
>> 
>> Here is an example illustrating the issue:
>> 
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeLater(() -> {
>>             JFrame frame = new JFrame("Window Icon Test");
>>             frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>>             frame.setSize(400, 300);
>>             frame.setVisible(true);
>> 
>>             List<Image> images = new ArrayList<>();
>>             for (int size = 16; size <= 32; size++) {
>>                 // create an image displaying the size used
>>                 BufferedImage image = new BufferedImage(size, size, BufferedImage.TYPE_INT_ARGB);
>>                 Graphics2D g = image.createGraphics();
>>                 g.setFont(new Font("dialog", Font.BOLD, 12));
>>                 g.setColor(Color.BLACK);
>>                 g.drawString(String.valueOf(size), 0, size - (size - g.getFont().getSize()) / 2);
>>                 images.add(image);
>>             }
>> 
>>             frame.setIconImages(images);
>>         });
>>     }
>> 
>> On Windows if the screen scaling is set to 100% the 16x16 icon is picked from the list. If the scaling of the screen is set to 150% while the application is running, the 16x16 icon is upscaled and looks blurry.
>> 
>> A way to work around this issue is to listen for graphics configuration changes with:
>> 
>>     frame.addPropertyChangeListener("graphicsConfiguration", event -> frame.setIconImages(frame.getIconImages()));
>> 
>> 
>> Ideally this should be done automatically by the JDK. Maybe the `WindowPeer` could call `updateIconImages()` when `updateGraphicsData()` or `displayChanged()` is invoked?
>
> Submitted the bug for it, please change the PR title to "8276849: Refresh the window icon on graphics configuration changes" to get it hooked and resolve the jcheck complaint.

@shipilev Thank you for filing the JDK bug

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

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


From aivanov at openjdk.java.net  Tue Nov  9 12:33:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 9 Nov 2021 12:33:39 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html
In-Reply-To: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
Message-ID: <h69ZxPIqvI9G0R2JqI3SWePcLOptqHuvrL4SkzQGvhc=.f0a1844f-99b2-4393-963b-c0410c3bb68c@github.com>

On Mon, 8 Nov 2021 09:13:35 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> This change introduces no visual difference, but improves a11y.

> To me, the table looks correct currently: _Arabic_ Unicode range serves as the title for both rows. I wonder how it's read by a screen reader: the original version and the updated version. What we should strive for is for clarity of the read table rather than blindly following the rule where each row should have a title, provided that the title is available in this particular case.

You may be right, the description of [`rowgroup`](https://html.spec.whatwg.org/dev/tables.html#attr-th-scope-rowgroup) keyword says such a header applies to all the cells in the group: _?The row group state means the header cell applies to all the remaining cells in the row group.?_

> You change the semantics of the table by moving the header to another column. The rendering should rather change too, otherwise visual representation becomes misleading.

Maybe a better way would be to make the second column a row column as you're suggesting but still keeping the existing row groups and changing the `scope` of the *Tai Tham* header cell to `rowgroup`: that is `<th scope="rowgroup">Tai Tham</th>`; and then for consistency with the rows above mark the second column with `<th scope="row">`.

Does it make any sense?

Is the third column a better candidate for the row header?

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

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


From duke at openjdk.java.net  Tue Nov  9 13:32:41 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Tue, 9 Nov 2021 13:32:41 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html
In-Reply-To: <h69ZxPIqvI9G0R2JqI3SWePcLOptqHuvrL4SkzQGvhc=.f0a1844f-99b2-4393-963b-c0410c3bb68c@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
 <h69ZxPIqvI9G0R2JqI3SWePcLOptqHuvrL4SkzQGvhc=.f0a1844f-99b2-4393-963b-c0410c3bb68c@github.com>
Message-ID: <isv1B1fGcH0ll5czaQd7hkh9KWc7VZTXeYrq5ugllqw=.59c8c0dc-bc30-4cf7-bca7-0307768eec09@github.com>

On Tue, 9 Nov 2021 12:30:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This change introduces no visual difference, but improves a11y.
>
>> To me, the table looks correct currently: _Arabic_ Unicode range serves as the title for both rows. I wonder how it's read by a screen reader: the original version and the updated version. What we should strive for is for clarity of the read table rather than blindly following the rule where each row should have a title, provided that the title is available in this particular case.
> 
> You may be right, the description of [`rowgroup`](https://html.spec.whatwg.org/dev/tables.html#attr-th-scope-rowgroup) keyword says such a header applies to all the cells in the group: _?The row group state means the header cell applies to all the remaining cells in the row group.?_
> 
>> You change the semantics of the table by moving the header to another column. The rendering should rather change too, otherwise visual representation becomes misleading.
> 
> Maybe a better way would be to make the second column a row column as you're suggesting but still keeping the existing row groups and changing the `scope` of the *Tai Tham* header cell to `rowgroup`: that is `<th scope="rowgroup">Tai Tham</th>`; and then for consistency with the rows above mark the second column with `<th scope="row">`.
> 
> Does it make any sense?
> 
> Is the third column a better candidate for the row header?

@aivanov-jdk I apologize, I haven't learned the etiquette around here yet.

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

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


From clanger at openjdk.java.net  Tue Nov  9 15:22:36 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 9 Nov 2021 15:22:36 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows
In-Reply-To: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
Message-ID: <4JVvkq0XghJ8tKd_0x6DJ2YpHzCHVsrT7BHO9SxbH8s=.0887acdf-a367-4e72-bee0-0b033efba135@github.com>

On Tue, 9 Nov 2021 07:57:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni to an awt related test, and shows on Windows server 2019 the following JNI warning , so the test  JNICheck/FreeTypeScalerJNICheck.java fails on this Windows version.
> 
> :stdErr:
> Thu Oct 28 01:27:10 CEST 2021
> stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV
>                at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 18.0.0.1-internal/Native Method)
>                at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:95)
>                at sun.awt.Win32GraphicsEnvironment.<clinit>(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:63)
>                at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 18.0.0.1-internal/PlatformGraphicsInfo.java:34)
>                at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:93)
>                at java.awt.GraphicsEnvironment$LocalGE.<clinit>(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:84)
>                at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:106)
>                at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53)
>                at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)
> 
> We can get rid of the warning by adjusting a JNU_CallStaticMethodByName call in awt_Win32GraphicsEnv.cpp .

LGTM

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

Marked as reviewed by clanger (Reviewer).

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


From shade at openjdk.java.net  Tue Nov  9 15:27:36 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 9 Nov 2021 15:27:36 GMT
Subject: RFR: 8276805: java/awt/print/PrinterJob/CheckPrivilege.java fails
 due to disabled SecurityManager
In-Reply-To: <T3L6tECdZ8YXjkss483DEwdc6gX9RYB6wYXz-O4h09Y=.1ba131e6-6bd4-4d9b-806c-0af389389fa8@github.com>
References: <9q-Pbq4hsAxcRRzVBKTMu3DLnY-Pgczz_6ZEqL1U6ok=.76ab3fd1-8183-4882-bcca-af4ea4e7a971@github.com>
 <T3L6tECdZ8YXjkss483DEwdc6gX9RYB6wYXz-O4h09Y=.1ba131e6-6bd4-4d9b-806c-0af389389fa8@github.com>
Message-ID: <BwHrooMRKq2XXHugTmIpQ8gEjZh4jQM2u_ffBQa12AM=.77b58a31-eb39-4a84-adfe-6cfd83ec88fd@github.com>

On Mon, 8 Nov 2021 19:18:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Current test fails on SecurityManager installation. See the bug for failure details. The fix is to allow SM for this test, until SM is removed wholesale.
>> 
>> Additional testing:
>>  - [x] Affected test now passes
>
> Marked as reviewed by serb (Reviewer).

Thanks @mrserb! No more reviewers needs for this simple patch, right?

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

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


From aivanov at openjdk.java.net  Tue Nov  9 16:59:57 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 9 Nov 2021 16:59:57 GMT
Subject: RFR: 8276805: java/awt/print/PrinterJob/CheckPrivilege.java fails
 due to disabled SecurityManager
In-Reply-To: <9q-Pbq4hsAxcRRzVBKTMu3DLnY-Pgczz_6ZEqL1U6ok=.76ab3fd1-8183-4882-bcca-af4ea4e7a971@github.com>
References: <9q-Pbq4hsAxcRRzVBKTMu3DLnY-Pgczz_6ZEqL1U6ok=.76ab3fd1-8183-4882-bcca-af4ea4e7a971@github.com>
Message-ID: <_69ZYt0FzBmpqU5H2ZMeERG9CXgDwTh1Mfov94UHbV0=.369758ab-2cc1-4189-a66d-2e2ef716b4af@github.com>

On Mon, 8 Nov 2021 13:13:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current test fails on SecurityManager installation. See the bug for failure details. The fix is to allow SM for this test, until SM is removed wholesale.
> 
> Additional testing:
>  - [x] Affected test now passes

Marked as reviewed by aivanov (Reviewer).

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

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


From duke at openjdk.java.net  Tue Nov  9 17:49:04 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Tue, 9 Nov 2021 17:49:04 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html [v2]
In-Reply-To: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
Message-ID: <kBc5yJxF1e4jJCKFZTp5gsn_IKoD1gwDVvmNplPMH5c=.4ae75834-20b3-4ba4-958e-b9f8a152fcb6@github.com>

> This change introduces no visual difference, but improves a11y.

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

  Achieve correct row headers without header change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6291/files
  - new: https://git.openjdk.java.net/jdk/pull/6291/files/71f26cd7..acc9edec

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

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

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


From duke at openjdk.java.net  Tue Nov  9 17:49:06 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Tue, 9 Nov 2021 17:49:06 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html
In-Reply-To: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
Message-ID: <n528TAqywAbbBiwiv9xC-08xWtOLGpcPI2SS7JCemr8=.acfdaa62-0752-472f-8e42-55c5fa944beb@github.com>

On Mon, 8 Nov 2021 09:13:35 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> This change introduces no visual difference, but improves a11y.

I've pushed a change which "ticks the boxes without introducing so much change". I keep the first column as the row header, and simply specify it explicitly on the `td` elements. Doccheck is fine with it.

@aivanov-jdk If you thinks this works, I'd ask you to review and sponsor (if the review is necessary given the existing, outdated one).

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

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


From serb at openjdk.java.net  Tue Nov  9 19:25:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 9 Nov 2021 19:25:43 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows
In-Reply-To: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
Message-ID: <gVSUXx-iZ3g_7ImZWlonOSJ975OA3JRvaGZqYs79XoU=.f2d7e04a-bf03-4cd6-88af-6609f5368633@github.com>

On Tue, 9 Nov 2021 07:57:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni to an awt related test, and shows on Windows server 2019 the following JNI warning , so the test  JNICheck/FreeTypeScalerJNICheck.java fails on this Windows version.
> 
> :stdErr:
> Thu Oct 28 01:27:10 CEST 2021
> stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV
>                at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 18.0.0.1-internal/Native Method)
>                at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:95)
>                at sun.awt.Win32GraphicsEnvironment.<clinit>(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:63)
>                at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 18.0.0.1-internal/PlatformGraphicsInfo.java:34)
>                at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:93)
>                at java.awt.GraphicsEnvironment$LocalGE.<clinit>(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:84)
>                at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:106)
>                at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53)
>                at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)
> 
> We can get rid of the warning by adjusting a JNU_CallStaticMethodByName call in awt_Win32GraphicsEnv.cpp .

src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp line 129:

> 127: 
> 128:     JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2);
> 129:     JNU_CallStaticMethodByName(env, &ignoreException,

As far as understand from the previous fix the "ignoreException" parameter does not suppress the currently raised exception, it just suppresses the warning in the XCheck:jni. So it will be good to propagate an exception to the user if this code is executed on the "java" thread, and log it by the trace macro if it is executed on a toolkit thread.

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

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


From serb at openjdk.java.net  Tue Nov  9 19:28:34 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 9 Nov 2021 19:28:34 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v3]
In-Reply-To: <V_OdeRV0Zk7fy32nVnrQMna99sgTMf94z306oas9nWc=.54832411-541e-44ef-bead-1603ae9f63ee@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
 <V_OdeRV0Zk7fy32nVnrQMna99sgTMf94z306oas9nWc=.54832411-541e-44ef-bead-1603ae9f63ee@github.com>
Message-ID: <2iQg2RTFoClo1MEwy1CTJIfFcfsqOxYxrcKM29NmY-A=.9a7a861f-0e80-49c3-b09d-766d3661bc88@github.com>

On Mon, 8 Nov 2021 11:53:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I have removed the tolerance change and PL-ed the test....Any more comments on this PR?

If tolerance is not needed and the only issue we have is the visible cursor on the screenshot then why do we try to update the tests, maybe we can try to update the jdk instead?

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

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


From achung at openjdk.java.net  Tue Nov  9 19:31:34 2021
From: achung at openjdk.java.net (Alisen Chung)
Date: Tue, 9 Nov 2021 19:31:34 GMT
Subject: RFR: 8276678: Malformed Javadoc inline tags in JDK source in
 com/sun/beans/decoder/DocumentHandler.java
In-Reply-To: <cDut_0cyvuzkE2Ugt_GCzR-leYgp3DDGd_-56kYxZHE=.6592a742-e89d-4151-925f-1b1e17708f05@github.com>
References: <Cj5hn3zbefTQkuvrEF_vDvCEQVEVu3bpDl7_mJRiDD0=.066875af-5883-4aaa-bc4d-05af0798902c@github.com>
 <CodQO7YtQT-QEc3BCakskcBQegreETX0yzPjLUppgCU=.fce4d8f4-2a5a-4c31-b3c7-15af1448399d@github.com>
 <cDut_0cyvuzkE2Ugt_GCzR-leYgp3DDGd_-56kYxZHE=.6592a742-e89d-4151-925f-1b1e17708f05@github.com>
Message-ID: <MfJydjKsntx--q1Nb1LoYXX9jbX0_x9M2TC4GpggLCs=.574d731b-b676-49bb-bbbf-8d3162dd7454@github.com>

On Mon, 8 Nov 2021 19:00:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > Please check other classes in the jdk desktop module as well. There are 7 such issues.
> 
> A similar issue is being reviewed as #6290, it includes 4 files. Are these split between JBS subcomponents?

Looks like Prasanta already fixed the other 5 issues

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

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


From aivanov at openjdk.java.net  Tue Nov  9 19:41:36 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 9 Nov 2021 19:41:36 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html [v2]
In-Reply-To: <kBc5yJxF1e4jJCKFZTp5gsn_IKoD1gwDVvmNplPMH5c=.4ae75834-20b3-4ba4-958e-b9f8a152fcb6@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
 <kBc5yJxF1e4jJCKFZTp5gsn_IKoD1gwDVvmNplPMH5c=.4ae75834-20b3-4ba4-958e-b9f8a152fcb6@github.com>
Message-ID: <lawM9GydemIPMh1_oBD-FnJmf8XHeqrpMbXciv2fKYk=.fa3c3369-ce52-47fa-8b4a-ec4584e5e9c6@github.com>

On Tue, 9 Nov 2021 17:49:04 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

>> This change introduces no visual difference, but improves a11y.
>
> Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Achieve correct row headers without header change

I'm fine with the 2nd version yet I'm pretty DocChecker won't be happy unless you create additional row header with `<th>` element.

Shall the third column of the table be converted to `<th>` to compensate for that?

src/java.desktop/share/classes/java/awt/font/NumericShaper.java line 117:

> 115:  *     <th scope="col" id="colheader1">Unicode Range
> 116:  *     <th scope="col" id="colheader2">{@code NumericShaper} Constants
> 117:  *     <th scope="col" id="colheader3">Precedence

Shall we use more descriptive ids?
Suggestion:

 *     <th scope="col" id="nsUnicodeRangeHeader">Unicode Range
 *     <th scope="col" id="nsConstantsHeader">{@code NumericShaper} Constants
 *     <th scope="col" id="nsPrecedence">Precedence

src/java.desktop/share/classes/java/awt/font/NumericShaper.java line 132:

> 130:  *     <td headers="rowheader1 colheader3">{@link NumericShaper.Range#EASTERN_ARABIC}
> 131:  *   <tr>
> 132:  *     <th scope="row">Tai Tham

Does it make sense to use `<th scope="rowgroup">` for consistency?

src/java.desktop/share/classes/java/awt/font/NumericShaper.java line 133:

> 131:  *     <td>{@link NumericShaper.Range#EASTERN_ARABIC}
> 132:  * </tbody>
> 133:  * <tbody>

You need to preserve both `<tbody>` to have two row groups.

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

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


From prr at openjdk.java.net  Tue Nov  9 19:48:35 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 9 Nov 2021 19:48:35 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows
In-Reply-To: <gVSUXx-iZ3g_7ImZWlonOSJ975OA3JRvaGZqYs79XoU=.f2d7e04a-bf03-4cd6-88af-6609f5368633@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
 <gVSUXx-iZ3g_7ImZWlonOSJ975OA3JRvaGZqYs79XoU=.f2d7e04a-bf03-4cd6-88af-6609f5368633@github.com>
Message-ID: <669N85kj3NJ9LBmLySry9gncEzHOLsxmyTSgSJ9iuKA=.84146bec-e572-43a4-a260-c771e709caea@github.com>

On Tue, 9 Nov 2021 19:22:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni to an awt related test, and shows on Windows server 2019 the following JNI warning , so the test  JNICheck/FreeTypeScalerJNICheck.java fails on this Windows version.
>> 
>> :stdErr:
>> Thu Oct 28 01:27:10 CEST 2021
>> stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV
>>                at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 18.0.0.1-internal/Native Method)
>>                at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:95)
>>                at sun.awt.Win32GraphicsEnvironment.<clinit>(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:63)
>>                at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 18.0.0.1-internal/PlatformGraphicsInfo.java:34)
>>                at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:93)
>>                at java.awt.GraphicsEnvironment$LocalGE.<clinit>(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:84)
>>                at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:106)
>>                at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53)
>>                at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)
>> 
>> We can get rid of the warning by adjusting a JNU_CallStaticMethodByName call in awt_Win32GraphicsEnv.cpp .
>
> src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp line 129:
> 
>> 127: 
>> 128:     JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2);
>> 129:     JNU_CallStaticMethodByName(env, &ignoreException,
> 
> As far as understand from the previous fix the "ignoreException" parameter does not suppress the currently raised exception, it just suppresses the warning in the XCheck:jni. So it will be good to propagate an exception to the user if this code is executed on the "java" thread, and log it by the trace macro if it is executed on a toolkit thread.

Yeah this looks like the wrong fix.
-Xcheck:jni only warns like this if there are actual exceptions, doesn't it ?
So if we had one, where was it ?

Note that Windows Server 2019 is a staple of the CI testing at Oracle and the test hasn't failed in the > 2 months since it was integrated, so I'm wondering why it fails in your case ?
Was this a debug build perhaps ?

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

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


From serb at openjdk.java.net  Tue Nov  9 19:56:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 9 Nov 2021 19:56:40 GMT
Subject: RFR: 8169468: NoResizeEventOnDMChangeTest.java fails because FS
 Window didn't receive all resizes! [v2]
In-Reply-To: <Q0KoI03rJu4gT5mVvH0xtzSJQcav4pdpkThkWAe2yZU=.dbf102ef-1368-439c-8356-35c1c0d27e96@github.com>
References: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
 <Q0KoI03rJu4gT5mVvH0xtzSJQcav4pdpkThkWAe2yZU=.dbf102ef-1368-439c-8356-35c1c0d27e96@github.com>
Message-ID: <NHTErwS0YImz0IL0aHsXl0u1TFw6vVrCa3TlwJ1ivHg=.97dacd87-2a7d-4bba-829d-8f9849b35d52@github.com>

On Mon, 8 Nov 2021 22:32:59 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> I was able to reproduce this issue locally 2 times out of 100 runs on multi-monitor
>> configuration. Both times due to the screen resolution change is so slow window got
>> accidentally moved to the secondary screen by the display driver.
>> Can not reproduce this bug with ATI card at all.
>> Since there is nothing we can do to stop graphics driver from reassigning
>> the window if it decides that promary monitor is not on at the moment the
>> only way is to check if this has had happened and if so then we can not trust the test
>> since we changing resolution of one display and window not getting resized
>> because it is placed on another display and test should be skept.
>> 
>> After that i ran this test locally about a thousand times on all platforms
>> and has not seen the failure again.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check that setting the new display mode ended up with window
>   residing on the screen with resolution different than one it was before,
>   even if it the different display - window and components still have to
>   receive the resize event. Only skipping the iteration where that did not
>   happened instead of skipping the entire test.

test/jdk/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java line 158:

> 156:                                 Frame f = fsWin instanceof Frame ? (Frame) fsWin : (Frame) fsWin.getOwner();
> 157:                                 DisplayMode oldMode = f.getGraphicsConfiguration().getDevice().getDisplayMode();
> 158:                                 gd.setDisplayMode(dm1);

probably it will be good to add a delay here? What is the longest display switch on the system where the bug is reproduced? a few seconds?

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

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


From serb at openjdk.java.net  Tue Nov  9 19:57:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 9 Nov 2021 19:57:31 GMT
Subject: RFR: 8276678: Malformed Javadoc inline tags in JDK source in
 com/sun/beans/decoder/DocumentHandler.java
In-Reply-To: <Cj5hn3zbefTQkuvrEF_vDvCEQVEVu3bpDl7_mJRiDD0=.066875af-5883-4aaa-bc4d-05af0798902c@github.com>
References: <Cj5hn3zbefTQkuvrEF_vDvCEQVEVu3bpDl7_mJRiDD0=.066875af-5883-4aaa-bc4d-05af0798902c@github.com>
Message-ID: <lq7bnuGzHOKrSL-O4nbDBuuwqsF6IqDdHSfDQTt41ug=.77ee542a-cf9a-4d8f-805f-27b2a830933e@github.com>

On Mon, 8 Nov 2021 17:08:36 GMT, Alisen Chung <achung at openjdk.org> wrote:

> fixed malformed inline tags

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Tue Nov  9 19:58:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 9 Nov 2021 19:58:40 GMT
Subject: RFR: 8198626:
 java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac
 [v2]
In-Reply-To: <xz0M7OpieAOp5zxeTZI5Sevuo_--t1b3lXJeoNPWWQ8=.cc7d015b-0af7-4de4-955a-6750440ace90@github.com>
References: <QUccyFKKaCbrwGgCHWtZKoA_4pGH1m6gROE0g70H4Ss=.6540a021-5fac-4e85-b9f3-3b9948692516@github.com>
 <xz0M7OpieAOp5zxeTZI5Sevuo_--t1b3lXJeoNPWWQ8=.cc7d015b-0af7-4de4-955a-6750440ace90@github.com>
Message-ID: <ymARS26Uj8mbwnmhhjhaW--YsYa4CnWt1F2ifJF6Fvw=.466c8dde-0420-44c7-a5a5-fa78c9796767@github.com>

On Mon, 8 Nov 2021 12:22:07 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Test java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac fails on Mac. The test fails on my local machine (macOS BigSur) always and on mach5 also. The test uses Robot for mouse clicks and there is no delay or autoDelay set on Robot.
>> 
>> The fix adds set autoDelay on the robot. Along with this, some other cleanup is done. The test passes after the changes on my local mac and mach5 (Link in the JBS)
>
> Pankaj Bansal has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review comments
>  - Review Comments

Marked as reviewed by serb (Reviewer).

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

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


From aivanov at openjdk.java.net  Tue Nov  9 20:05:42 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 9 Nov 2021 20:05:42 GMT
Subject: RFR: 8276678: Malformed Javadoc inline tags in JDK source in
 com/sun/beans/decoder/DocumentHandler.java
In-Reply-To: <Cj5hn3zbefTQkuvrEF_vDvCEQVEVu3bpDl7_mJRiDD0=.066875af-5883-4aaa-bc4d-05af0798902c@github.com>
References: <Cj5hn3zbefTQkuvrEF_vDvCEQVEVu3bpDl7_mJRiDD0=.066875af-5883-4aaa-bc4d-05af0798902c@github.com>
Message-ID: <GEyV5g-WlsIGgIxSd1mfqrcO3zlQzNAfgdXdO9PfKEk=.174b8e34-9ec5-47d0-81a5-57319c6aeb0b@github.com>

On Mon, 8 Nov 2021 17:08:36 GMT, Alisen Chung <achung at openjdk.org> wrote:

> fixed malformed inline tags

Marked as reviewed by aivanov (Reviewer).

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

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


From pbansal at openjdk.java.net  Tue Nov  9 20:13:43 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 9 Nov 2021 20:13:43 GMT
Subject: Integrated: 8198626:
 java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac
In-Reply-To: <QUccyFKKaCbrwGgCHWtZKoA_4pGH1m6gROE0g70H4Ss=.6540a021-5fac-4e85-b9f3-3b9948692516@github.com>
References: <QUccyFKKaCbrwGgCHWtZKoA_4pGH1m6gROE0g70H4Ss=.6540a021-5fac-4e85-b9f3-3b9948692516@github.com>
Message-ID: <_vpNV0gWCm5-dvbVN3pXgoHdSeNGN1LAj-Ods4xweqM=.5394d321-520b-43f5-a09e-6042cea42e8e@github.com>

On Fri, 5 Nov 2021 10:26:07 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> Test java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac fails on Mac. The test fails on my local machine (macOS BigSur) always and on mach5 also. The test uses Robot for mouse clicks and there is no delay or autoDelay set on Robot.
> 
> The fix adds set autoDelay on the robot. Along with this, some other cleanup is done. The test passes after the changes on my local mac and mach5 (Link in the JBS)

This pull request has now been integrated.

Changeset: a60e9125
Author:    Pankaj Bansal <pbansal at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a60e91259ba83d2a525b612b2c7a1fd7934b88a2
Stats:     50 lines in 2 files changed: 34 ins; 8 del; 8 mod

8198626: java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac

Reviewed-by: serb

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

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


From serb at openjdk.java.net  Tue Nov  9 20:55:39 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 9 Nov 2021 20:55:39 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows
In-Reply-To: <669N85kj3NJ9LBmLySry9gncEzHOLsxmyTSgSJ9iuKA=.84146bec-e572-43a4-a260-c771e709caea@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
 <gVSUXx-iZ3g_7ImZWlonOSJ975OA3JRvaGZqYs79XoU=.f2d7e04a-bf03-4cd6-88af-6609f5368633@github.com>
 <669N85kj3NJ9LBmLySry9gncEzHOLsxmyTSgSJ9iuKA=.84146bec-e572-43a4-a260-c771e709caea@github.com>
Message-ID: <TNIzf3oTslrWSF2fiNjyFZSRy9FQlKe0B85EFYilqRk=.6a62544f-dd0f-4684-9971-b6d132029310@github.com>

On Tue, 9 Nov 2021 19:45:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp line 129:
>> 
>>> 127: 
>>> 128:     JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2);
>>> 129:     JNU_CallStaticMethodByName(env, &ignoreException,
>> 
>> As far as understand from the previous fix the "ignoreException" parameter does not suppress the currently raised exception, it just suppresses the warning in the XCheck:jni. So it will be good to propagate an exception to the user if this code is executed on the "java" thread, and log it by the trace macro if it is executed on a toolkit thread.
>
> Yeah this looks like the wrong fix.
> -Xcheck:jni only warns like this if there are actual exceptions, doesn't it ?
> So if we had one, where was it ?
> 
> Note that Windows Server 2019 is a staple of the CI testing at Oracle and the test hasn't failed in the > 2 months since it was integrated, so I'm wondering why it fails in your case ?
> Was this a debug build perhaps ?

I think Xcheck:jni raises a warning when two JNI calls are made in a row w/o calling exception check in between. So it is not necessary to have an actual exception to produce a warning.

Probably it is reproduced there, because that system is "true" headless, and the execution code path is just different, or something like that, need to check what is the next/prev JNI call.
Or maybe this method really throw an exception, need some more detail.

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

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


From serb at openjdk.java.net  Wed Nov 10 01:52:45 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 10 Nov 2021 01:52:45 GMT
Subject: RFR: 8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
In-Reply-To: <TTmkbDrcIgizyJFzUgAcRLpcgm6DsJ9DuEn-V9uEouY=.631b4c98-90b0-44ab-8cd7-f8e6dd58d4a9@github.com>
References: <wnm-YKKA9gtMKq75lwgp0FuCT4VbvaC_Fh1eJC3krR8=.4d08ec64-7140-4559-b051-987e3bea0a27@github.com>
 <hmXQnpW3WHN3zyKaYiVac87tk6BFlJSXu-2zA3z9Fj4=.3c89d006-976e-4520-90e3-dc52efb0d9b3@github.com>
 <TTmkbDrcIgizyJFzUgAcRLpcgm6DsJ9DuEn-V9uEouY=.631b4c98-90b0-44ab-8cd7-f8e6dd58d4a9@github.com>
Message-ID: <OzK6KsfF0hCBVAhB1MgY_FjhGoPeo6vKksRo9Vpe78s=.0009aa80-2216-4055-997c-59c4ff69c268@github.com>

On Fri, 29 Oct 2021 09:20:06 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> I have tried to run this test on macOS as a standalone code, and it hangs. The second frame is never disposed and still visible on the screen, not sure why.
>
>> I have tried to run this test on macOS as a standalone code, and it hangs. The second frame is never disposed and still visible on the screen, not sure why.
> 
> Yep, it works fine running from JavaTest but hangs when running from IDE, looks like extra mouseMove event being generated and we create extra frame. Luckily, that's easy to fix.

@azuev-java 
Looks like this test still fails if the 200% dpi is set on the windows, can you please confirm that?

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

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


From psadhukhan at openjdk.java.net  Wed Nov 10 05:08:39 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Nov 2021 05:08:39 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v3]
In-Reply-To: <2iQg2RTFoClo1MEwy1CTJIfFcfsqOxYxrcKM29NmY-A=.9a7a861f-0e80-49c3-b09d-766d3661bc88@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
 <V_OdeRV0Zk7fy32nVnrQMna99sgTMf94z306oas9nWc=.54832411-541e-44ef-bead-1603ae9f63ee@github.com>
 <2iQg2RTFoClo1MEwy1CTJIfFcfsqOxYxrcKM29NmY-A=.9a7a861f-0e80-49c3-b09d-766d3661bc88@github.com>
Message-ID: <3LKQkYE0RGNaeiRX_-HDk1t0Njj2mYuqX1PhmTNQw7g=.8fd39564-e1eb-4bb5-b67f-0a2ab7895aa8@github.com>

On Tue, 9 Nov 2021 19:25:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> 
> 
> 
> If tolerance is not needed and the only issue we have is the visible cursor on the screenshot then why do we try to update the tests, maybe we can try to update the jdk instead?

I guess it was already discussed before as below to have the stability improvement in the tests and you agreed to it also but if the stance is changed, I do not have issue in withdrawing this PR.

> > The test part of the fix has multiple stability improvements, and there's no reason to throw that out. And moving the pixel capture position to a more safe position is fine too. I just think that -10 isn't sa\fe enough.
> 
> Sure, I have no comments about the changes related to stability, but there are suspicious cases like using tolerance.

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

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


From kizune at openjdk.java.net  Wed Nov 10 05:35:12 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 10 Nov 2021 05:35:12 GMT
Subject: RFR: 8169468: NoResizeEventOnDMChangeTest.java fails because FS
 Window didn't receive all resizes! [v3]
In-Reply-To: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
References: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
Message-ID: <ESDcvvz0EfoHXtg5aFV7Xtk7Ax9InIqryoVpvuY_h64=.f5246d99-26bd-4a4a-8cd7-eaf256d08d10@github.com>

> I was able to reproduce this issue locally 2 times out of 100 runs on multi-monitor
> configuration. Both times due to the screen resolution change is so slow window got
> accidentally moved to the secondary screen by the display driver.
> Can not reproduce this bug with ATI card at all.
> Since there is nothing we can do to stop graphics driver from reassigning
> the window if it decides that promary monitor is not on at the moment the
> only way is to check if this has had happened and if so then we can not trust the test
> since we changing resolution of one display and window not getting resized
> because it is placed on another display and test should be skept.
> 
> After that i ran this test locally about a thousand times on all platforms
> and has not seen the failure again.

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

  Added speel for 2 seconds after setting new display mode.
  Removed unneeded imports.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6186/files
  - new: https://git.openjdk.java.net/jdk/pull/6186/files/da325c4f..06b58644

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

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

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


From kizune at openjdk.java.net  Wed Nov 10 05:35:15 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 10 Nov 2021 05:35:15 GMT
Subject: RFR: 8169468: NoResizeEventOnDMChangeTest.java fails because FS
 Window didn't receive all resizes! [v2]
In-Reply-To: <NHTErwS0YImz0IL0aHsXl0u1TFw6vVrCa3TlwJ1ivHg=.97dacd87-2a7d-4bba-829d-8f9849b35d52@github.com>
References: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
 <Q0KoI03rJu4gT5mVvH0xtzSJQcav4pdpkThkWAe2yZU=.dbf102ef-1368-439c-8356-35c1c0d27e96@github.com>
 <NHTErwS0YImz0IL0aHsXl0u1TFw6vVrCa3TlwJ1ivHg=.97dacd87-2a7d-4bba-829d-8f9849b35d52@github.com>
Message-ID: <rmIfQrv-d6bovhPRD8cfPvoCT6pCeRRaCgvLQXZKS5w=.71e486a9-5d4f-4900-b056-da3d73555ca2@github.com>

On Tue, 9 Nov 2021 19:53:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check that setting the new display mode ended up with window
>>   residing on the screen with resolution different than one it was before,
>>   even if it the different display - window and components still have to
>>   receive the resize event. Only skipping the iteration where that did not
>>   happened instead of skipping the entire test.
>
> test/jdk/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java line 158:
> 
>> 156:                                 Frame f = fsWin instanceof Frame ? (Frame) fsWin : (Frame) fsWin.getOwner();
>> 157:                                 DisplayMode oldMode = f.getGraphicsConfiguration().getDevice().getDisplayMode();
>> 158:                                 gd.setDisplayMode(dm1);
> 
> probably it will be good to add a delay here? What is the longest display switch on the system where the bug is reproduced? a few seconds?

Yeah, i think 2 seconds will be enough.

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

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


From prr at openjdk.java.net  Wed Nov 10 05:50:56 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 10 Nov 2021 05:50:56 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v3]
In-Reply-To: <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
Message-ID: <5gKSW29Ah7FkFKAqlcJxZekf1LYkHIVfY-C4rqfkmx4=.d0563bfc-de95-4726-a160-7cbdd22ceb66@github.com>

On Fri, 29 Oct 2021 06:43:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review fix
>  - Fix

I don't see a reason to discard the various stability improvements.
The discussion is long so I may not be summarising correctly but 
- A product fix may resolve most of the issues and yet
- Stability fixes are still valuable
- The one test with a colour tolerance update may be better platform problem listed 
- The offset of -10,-10 for the cursor maybe better if it was parameterised and a bit bigger.

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

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


From psadhukhan at openjdk.java.net  Wed Nov 10 05:54:41 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Nov 2021 05:54:41 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v3]
In-Reply-To: <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
Message-ID: <YMQ2W9cI8FYGhyfizaQ4X8Kx19nFqXCawsO8kt79ezs=.4a22b7d3-b8cd-4aea-8efc-d41568880e63@github.com>

On Fri, 29 Oct 2021 06:43:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review fix
>  - Fix

I guess the last 2 is already taken care of in latest iteration.

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

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


From shade at openjdk.java.net  Wed Nov 10 08:02:44 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 10 Nov 2021 08:02:44 GMT
Subject: RFR: 8276805: java/awt/print/PrinterJob/CheckPrivilege.java fails
 due to disabled SecurityManager
In-Reply-To: <9q-Pbq4hsAxcRRzVBKTMu3DLnY-Pgczz_6ZEqL1U6ok=.76ab3fd1-8183-4882-bcca-af4ea4e7a971@github.com>
References: <9q-Pbq4hsAxcRRzVBKTMu3DLnY-Pgczz_6ZEqL1U6ok=.76ab3fd1-8183-4882-bcca-af4ea4e7a971@github.com>
Message-ID: <tQFMKfv_dF9Pk1evVMynmXbIX8fj1NImjOzL1dShWvs=.b53d2ba4-6776-46d6-afb6-bfa896d2afd2@github.com>

On Mon, 8 Nov 2021 13:13:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current test fails on SecurityManager installation. See the bug for failure details. The fix is to allow SM for this test, until SM is removed wholesale.
> 
> Additional testing:
>  - [x] Affected test now passes

Thank you, folks!

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

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


From shade at openjdk.java.net  Wed Nov 10 08:02:45 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 10 Nov 2021 08:02:45 GMT
Subject: Integrated: 8276805: java/awt/print/PrinterJob/CheckPrivilege.java
 fails due to disabled SecurityManager
In-Reply-To: <9q-Pbq4hsAxcRRzVBKTMu3DLnY-Pgczz_6ZEqL1U6ok=.76ab3fd1-8183-4882-bcca-af4ea4e7a971@github.com>
References: <9q-Pbq4hsAxcRRzVBKTMu3DLnY-Pgczz_6ZEqL1U6ok=.76ab3fd1-8183-4882-bcca-af4ea4e7a971@github.com>
Message-ID: <9XyNHHafEUQDDXmUfx3bQkmcJZH3b-7n3pH0g2pXJiY=.7edeb1e7-62a2-4f49-a0d9-f16199e16ae0@github.com>

On Mon, 8 Nov 2021 13:13:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current test fails on SecurityManager installation. See the bug for failure details. The fix is to allow SM for this test, until SM is removed wholesale.
> 
> Additional testing:
>  - [x] Affected test now passes

This pull request has now been integrated.

Changeset: fd0a25e6
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fd0a25e62b2c8abc3a419c2e80abbcf11c9e882f
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8276805: java/awt/print/PrinterJob/CheckPrivilege.java fails due to disabled SecurityManager

Reviewed-by: serb, aivanov

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

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


From duke at openjdk.java.net  Wed Nov 10 08:04:41 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 10 Nov 2021 08:04:41 GMT
Subject: Withdrawn: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1
In-Reply-To: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
Message-ID: <cwc9xLRdczYMP7lRQanjPSDnNW79PnCqqxaIbafz_Wg=.51e06199-8b30-4318-8e38-25b7f837ba91@github.com>

On Sat, 4 Sep 2021 19:54:55 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Used setOpaque() method to set correct background of platform window

This pull request has been closed without being integrated.

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

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


From psadhukhan at openjdk.java.net  Wed Nov 10 08:37:43 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Nov 2021 08:37:43 GMT
Subject: Integrated: 8276679: Malformed Javadoc inline tags in JDK source in
 javax/swing
In-Reply-To: <V7G2CnK7rFu8LIUpyZF0BZBC5Jhdrj4r5ubKNNywvoI=.bbc579a5-1cdd-4827-a752-916f90874d0f@github.com>
References: <V7G2CnK7rFu8LIUpyZF0BZBC5Jhdrj4r5ubKNNywvoI=.bbc579a5-1cdd-4827-a752-916f90874d0f@github.com>
Message-ID: <U24-6SaiKNkojVv3UvvhjCxJO3vGFh0VTr8NN0WFhE8=.197d1476-2ab0-4ae7-9480-0267958ec24b@github.com>

On Mon, 8 Nov 2021 07:56:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fixed multiple malformed Javadoc inline tags where the `@` is placed in front of the opening curly bracket (instead of behind).

This pull request has now been integrated.

Changeset: e01d6d00
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e01d6d00bc4ab5ca0d38f8894a78e6d911e0fe93
Stats:     5 lines in 4 files changed: 0 ins; 0 del; 5 mod

8276679: Malformed Javadoc inline tags in JDK source in javax/swing

Reviewed-by: aivanov, pbansal

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

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


From mbaesken at openjdk.java.net  Wed Nov 10 08:49:46 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 10 Nov 2021 08:49:46 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows
In-Reply-To: <TNIzf3oTslrWSF2fiNjyFZSRy9FQlKe0B85EFYilqRk=.6a62544f-dd0f-4684-9971-b6d132029310@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
 <gVSUXx-iZ3g_7ImZWlonOSJ975OA3JRvaGZqYs79XoU=.f2d7e04a-bf03-4cd6-88af-6609f5368633@github.com>
 <669N85kj3NJ9LBmLySry9gncEzHOLsxmyTSgSJ9iuKA=.84146bec-e572-43a4-a260-c771e709caea@github.com>
 <TNIzf3oTslrWSF2fiNjyFZSRy9FQlKe0B85EFYilqRk=.6a62544f-dd0f-4684-9971-b6d132029310@github.com>
Message-ID: <_8d2ZM_CXYdT8T9sM-Fo3ukpGfeFwIL1Ja6NnxdtWfM=.b881c420-934a-4bc5-b5d1-020c6cf09710@github.com>

On Tue, 9 Nov 2021 20:51:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yeah this looks like the wrong fix.
>> -Xcheck:jni only warns like this if there are actual exceptions, doesn't it ?
>> So if we had one, where was it ?
>> 
>> Note that Windows Server 2019 is a staple of the CI testing at Oracle and the test hasn't failed in the > 2 months since it was integrated, so I'm wondering why it fails in your case ?
>> Was this a debug build perhaps ?
>
> I think Xcheck:jni raises a warning when two JNI calls are made in a row w/o calling exception check in between. So it is not necessary to have an actual exception to produce a warning.
> 
> Probably it is reproduced there, because that system is "true" headless, and the execution code path is just different, or something like that, need to check what is the next/prev JNI call.
> Or maybe this method really throw an exception, need some more detail.

Hello,  in our central tests it was indeed a fastdbg OpenJDK.   On my local Windows 10 machine I could not reproduce it.
Our central tests run with -Djava.awt.headless=true , but I think the Win2019 server machine itself is not headless .

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

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


From jwilhelm at openjdk.java.net  Wed Nov 10 09:55:06 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 10 Nov 2021 09:55:06 GMT
Subject: RFR: 8276930: Update ProblemList
Message-ID: <dQ6b3JbfcCO0qrnPvLAs0GDzc2T_wVM0FZefMfnfrtA=.17346bb3-b982-4cc1-ab7b-415280cf331e@github.com>

Update a few entries in the problemlist that refer to bugs that have been closed as duplicates.

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

Commit messages:
 - Fixed duplicates

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

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


From lbourges at openjdk.java.net  Wed Nov 10 10:28:39 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 10 Nov 2021 10:28:39 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <xIRXpvayrwFFU_Wo5XoLtHeKb5HUqNxxLcW3dE1h9Cc=.a7b379fa-b418-48b0-8714-b8182f81f950@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
 <CeEMRyzppq2-yaby7fFDWT3ekeWJfRfD3Sp-dhY3scA=.723fad96-6c84-4583-a691-57152e3ec3dc@github.com>
 <7FgkHca8tdzn8chwJ6RsYWyuFVmtAQOl3xN17BiFhrg=.924d80dc-3171-45b4-a601-448bf3194aca@github.com>
 <2qVmqXHwGTEu7-fREZKtL8CBTnkgTf2pDpA1rFo5CVI=.7868c3ec-d91c-4d31-9751-28750be11968@github.com>
 <xIRXpvayrwFFU_Wo5XoLtHeKb5HUqNxxLcW3dE1h9Cc=.a7b379fa-b418-48b0-8714-b8182f81f950@github.com>
Message-ID: <NZ7cYRk4MLJzGcGsu3ZGQOGU8KfCI-W9QheoW-55JC4=.7262f6dd-207b-4b75-bd49-58b7305277f6@github.com>

On Tue, 9 Nov 2021 10:43:40 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> I don't think I can implement that on my own. Even if I fully understood the julia code, I assume I'd want to use the Math.fma(..) method. That method uses BigDecimals, which I assume (?) we don't want to use in a loop like this for performance reasons.
>> 
>> If this level of high-precision is considered essential to resolving this bug: then personally I'm at an impasse and we should either close this PR or I'll need some external help.
>> 
>> Or possible compromises might include:
>> 
>> A. Add a method like this in Curve.java:
>> 
>> public double evaluateCubicPolynomial(double a, double b, double c, double d, double t) {
>>     return d + t * (c + t * (b + t * a)));
>> }
>> 
>> 
>> And add a ticket that someone else can address separately to improve the accuracy of that method. (Also maybe other areas in the AWT codebase should use the same method? Like `Order3#XforT`?)
>> 
>> B. We can modify my new method signature from:
>> `public static Rectangle2D getBounds2D(PathIterator pi)`
>> to:
>> `public static Rectangle2D getBounds2D(PathIterator pi, boolean highPrecision)`
>> 
>> Where if `highPrecision` is true we use the new implementation *which may suffer rounding errors and be a few ulps too small*. And if it is false then we use the old implementation which suffers from the original bug. This has the benefit of definitely not breaking any existing code in existence. The downside is it puts the responsibility on developers to learn about and implement this new method. But at least it would exist.
>> 
>> Thoughts?
>
> I agree it is out of the scope of this issue to implement high-precision polynom evaluation (compensated horder scheme), that I or anybody else could implement it later.
> To ensure bounds2D are enclosing the shape entirely, I propose to add a small margin (10 ulps or more) to ascertain precision is good enough.
> To determine the precision level, using fuzzy testing is the good approach : generate lots ofrandom paths => check bounds2D accuracy in ulp units.

@prrace @mrserb what do you think on this bug in terms of precision requirements?
- should bbox always include control points ?
- should ideal shape always fit in bbox ? So I propose to add a margin > numerical inaccuracies.

I can develop a numerical approach based on fuzzy testing:
- generate random curves (high magnitude changes on control points)
- use both this algorithm (double) and implement the same with BigDecimal
- estimate the extrema error = max distance(pts big decimal, pts double)

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

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


From lbourges at openjdk.java.net  Wed Nov 10 10:28:39 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 10 Nov 2021 10:28:39 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <NZ7cYRk4MLJzGcGsu3ZGQOGU8KfCI-W9QheoW-55JC4=.7262f6dd-207b-4b75-bd49-58b7305277f6@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
 <CeEMRyzppq2-yaby7fFDWT3ekeWJfRfD3Sp-dhY3scA=.723fad96-6c84-4583-a691-57152e3ec3dc@github.com>
 <7FgkHca8tdzn8chwJ6RsYWyuFVmtAQOl3xN17BiFhrg=.924d80dc-3171-45b4-a601-448bf3194aca@github.com>
 <2qVmqXHwGTEu7-fREZKtL8CBTnkgTf2pDpA1rFo5CVI=.7868c3ec-d91c-4d31-9751-28750be11968@github.com>
 <xIRXpvayrwFFU_Wo5XoLtHeKb5HUqNxxLcW3dE1h9Cc=.a7b379fa-b418-48b0-8714-b8182f81f950@github.com>
 <NZ7cYRk4MLJzGcGsu3ZGQOGU8KfCI-W9QheoW-55JC4=.7262f6dd-207b-4b75-bd49-58b7305277f6@github.com>
Message-ID: <Q4-YZst7t1biWjzhw5lvCaAbe9aZ_lklJ-PpiSKKayw=.85696551-6ef8-4e93-a3fc-29590b46de84@github.com>

On Wed, 10 Nov 2021 10:23:53 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> I agree it is out of the scope of this issue to implement high-precision polynom evaluation (compensated horder scheme), that I or anybody else could implement it later.
>> To ensure bounds2D are enclosing the shape entirely, I propose to add a small margin (10 ulps or more) to ascertain precision is good enough.
>> To determine the precision level, using fuzzy testing is the good approach : generate lots ofrandom paths => check bounds2D accuracy in ulp units.
>
> @prrace @mrserb what do you think on this bug in terms of precision requirements?
> - should bbox always include control points ?
> - should ideal shape always fit in bbox ? So I propose to add a margin > numerical inaccuracies.
> 
> I can develop a numerical approach based on fuzzy testing:
> - generate random curves (high magnitude changes on control points)
> - use both this algorithm (double) and implement the same with BigDecimal
> - estimate the extrema error = max distance(pts big decimal, pts double)

Ideally jdk could provide new math methods:
- evalPoly(eqn[])
- find roots...
Based on compensated horner scheme and Math.fma() ~ 0.5 ulp

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

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


From jwilhelm at openjdk.java.net  Wed Nov 10 10:41:56 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 10 Nov 2021 10:41:56 GMT
Subject: RFR: 8276930: Update ProblemList [v2]
In-Reply-To: <dQ6b3JbfcCO0qrnPvLAs0GDzc2T_wVM0FZefMfnfrtA=.17346bb3-b982-4cc1-ab7b-415280cf331e@github.com>
References: <dQ6b3JbfcCO0qrnPvLAs0GDzc2T_wVM0FZefMfnfrtA=.17346bb3-b982-4cc1-ab7b-415280cf331e@github.com>
Message-ID: <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com>

> Update a few entries in the problemlist that refer to bugs that have been closed as duplicates.

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

  Moved non-instrument tests to the right place

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6328/files
  - new: https://git.openjdk.java.net/jdk/pull/6328/files/e0498532..38186d0a

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

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

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


From duke at openjdk.java.net  Wed Nov 10 10:58:08 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Wed, 10 Nov 2021 10:58:08 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html [v3]
In-Reply-To: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
Message-ID: <KHZ40DO2aMz5K-7Fisvw4DFcgZFXY8-HZt3mIzt34sg=.b4a60280-c657-4e43-9ad7-29bea56c7766@github.com>

> This change introduces no visual difference, but improves a11y.

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

  Most idiomatic version so far

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6291/files
  - new: https://git.openjdk.java.net/jdk/pull/6291/files/acc9edec..718e36ca

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

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

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


From duke at openjdk.java.net  Wed Nov 10 11:07:37 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Wed, 10 Nov 2021 11:07:37 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html
In-Reply-To: <h69ZxPIqvI9G0R2JqI3SWePcLOptqHuvrL4SkzQGvhc=.f0a1844f-99b2-4393-963b-c0410c3bb68c@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
 <h69ZxPIqvI9G0R2JqI3SWePcLOptqHuvrL4SkzQGvhc=.f0a1844f-99b2-4393-963b-c0410c3bb68c@github.com>
Message-ID: <iIvh9aJddvff3RxftBKJrWgNupDzLoFOt0t1oM7Tfjk=.f56581c6-881a-4576-9e2d-8ffa5c76e95b@github.com>

On Tue, 9 Nov 2021 12:30:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This change introduces no visual difference, but improves a11y.
>
>> To me, the table looks correct currently: _Arabic_ Unicode range serves as the title for both rows. I wonder how it's read by a screen reader: the original version and the updated version. What we should strive for is for clarity of the read table rather than blindly following the rule where each row should have a title, provided that the title is available in this particular case.
> 
> You may be right, the description of [`rowgroup`](https://html.spec.whatwg.org/dev/tables.html#attr-th-scope-rowgroup) keyword says such a header applies to all the cells in the group: _?The row group state means the header cell applies to all the remaining cells in the row group.?_
> 
>> You change the semantics of the table by moving the header to another column. The rendering should rather change too, otherwise visual representation becomes misleading.
> 
> Maybe a better way would be to make the second column a row column as you're suggesting but still keeping the existing row groups and changing the `scope` of the *Tai Tham* header cell to `rowgroup`: that is `<th scope="rowgroup">Tai Tham</th>`; and then for consistency with the rows above mark the second column with `<th scope="row">`.
> 
> Does it make any sense?
> 
> Is the third column a better candidate for the row header?

@aivanov-jdk Your comment about `<tbody>` made me dig deeper. This [article on MDN ](https://developer.mozilla.org/en-US/docs/Learn/HTML/Tables/Advanced) gives guidance on this specific kind of tables.

Concerning `<tbody>`, quote (emphasis mine): 

> As your tables get a bit more complex in structure, it is useful to give them more structural definition. One clear way to do this is by using `<thead>`, `<tfoot>`, and `<tbody>`, which allow you to mark up a header, footer, and body section for the table.

> **These elements don't make the table any more accessible to screenreader users**, and don't result in any visual enhancement on their own. They are however very useful for styling and layout ? acting as useful hooks for adding CSS to your table.

Based on this, I don't see a foundation for having several tbodies. Am I missing something?

Concerning rowgroups, quote:

> `scope` has two more possible values ? `colgroup` and `rowgroup`. these are used for headings that sit over the top of multiple columns or rows. If you look back at the "Items Sold August 2016" table at the start of this section of the article, you'll see that the "Clothes" cell sits above the "Trousers", "Skirts", and "Dresses" cells. All of these cells should be marked up as headers (<th>), but "Clothes" is a heading that sits over the top and defines the other three subheadings. "Clothes" therefore should get an attribute of scope="colgroup", whereas the others would get an attribute of scope="col".

In our case, it seems most idiomatic to make both column one and two a header. I've pushed a version like that. I am running doccheck locally and it is giving zero errors.

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

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


From duke at openjdk.java.net  Wed Nov 10 11:07:40 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Wed, 10 Nov 2021 11:07:40 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html [v2]
In-Reply-To: <lawM9GydemIPMh1_oBD-FnJmf8XHeqrpMbXciv2fKYk=.fa3c3369-ce52-47fa-8b4a-ec4584e5e9c6@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
 <kBc5yJxF1e4jJCKFZTp5gsn_IKoD1gwDVvmNplPMH5c=.4ae75834-20b3-4ba4-958e-b9f8a152fcb6@github.com>
 <lawM9GydemIPMh1_oBD-FnJmf8XHeqrpMbXciv2fKYk=.fa3c3369-ce52-47fa-8b4a-ec4584e5e9c6@github.com>
Message-ID: <cKWvKczTfPiIGUNh3r788Lw9okU4qzDyusNRnyu4x7c=.e132018a-99f4-4a50-95dd-a3ad3fdaec14@github.com>

On Tue, 9 Nov 2021 19:35:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Achieve correct row headers without header change
>
> src/java.desktop/share/classes/java/awt/font/NumericShaper.java line 117:
> 
>> 115:  *     <th scope="col" id="colheader1">Unicode Range
>> 116:  *     <th scope="col" id="colheader2">{@code NumericShaper} Constants
>> 117:  *     <th scope="col" id="colheader3">Precedence
> 
> Shall we use more descriptive ids?
> Suggestion:
> 
>  *     <th scope="col" id="nsUnicodeRangeHeader">Unicode Range
>  *     <th scope="col" id="nsConstantsHeader">{@code NumericShaper} Constants
>  *     <th scope="col" id="nsPrecedence">Precedence

Not relevant anymore given last change

> src/java.desktop/share/classes/java/awt/font/NumericShaper.java line 132:
> 
>> 130:  *     <td headers="rowheader1 colheader3">{@link NumericShaper.Range#EASTERN_ARABIC}
>> 131:  *   <tr>
>> 132:  *     <th scope="row">Tai Tham
> 
> Does it make sense to use `<th scope="rowgroup">` for consistency?

Not relevant anymore given last change

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

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


From duke at openjdk.java.net  Wed Nov 10 11:07:41 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Wed, 10 Nov 2021 11:07:41 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html [v3]
In-Reply-To: <lawM9GydemIPMh1_oBD-FnJmf8XHeqrpMbXciv2fKYk=.fa3c3369-ce52-47fa-8b4a-ec4584e5e9c6@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
 <kBc5yJxF1e4jJCKFZTp5gsn_IKoD1gwDVvmNplPMH5c=.4ae75834-20b3-4ba4-958e-b9f8a152fcb6@github.com>
 <lawM9GydemIPMh1_oBD-FnJmf8XHeqrpMbXciv2fKYk=.fa3c3369-ce52-47fa-8b4a-ec4584e5e9c6@github.com>
Message-ID: <PsNSHFzG4r82aAzXZFKH_TqDfbt635eCrkIm0b0Yjbo=.209bc5cf-2597-40fa-8d06-366e1d9a2e56@github.com>

On Tue, 9 Nov 2021 19:30:39 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Most idiomatic version so far
>
> src/java.desktop/share/classes/java/awt/font/NumericShaper.java line 133:
> 
>> 131:  *     <td>{@link NumericShaper.Range#EASTERN_ARABIC}
>> 132:  * </tbody>
>> 133:  * <tbody>
> 
> You need to preserve both `<tbody>` to have two row groups.

Could you say where this is specified? See my comment below.

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

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


From kevinw at openjdk.java.net  Wed Nov 10 11:49:47 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 10 Nov 2021 11:49:47 GMT
Subject: RFR: 8276930: Update ProblemList [v2]
In-Reply-To: <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com>
References: <dQ6b3JbfcCO0qrnPvLAs0GDzc2T_wVM0FZefMfnfrtA=.17346bb3-b982-4cc1-ab7b-415280cf331e@github.com>
 <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com>
Message-ID: <AVoOXyYXfyC3DoaBC9bZab1TWlzJqNeHH0CizNx4o-g=.f4a5a3a0-92b6-431e-8fd9-54cc72ba036a@github.com>

On Wed, 10 Nov 2021 10:41:56 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Update a few entries in the problemlist that refer to bugs that have been closed as duplicates.
>
> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved non-instrument tests to the right place

Serviceability tidyup looks good to me.

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

Marked as reviewed by kevinw (Committer).

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


From aivanov at openjdk.java.net  Wed Nov 10 16:15:36 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 10 Nov 2021 16:15:36 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html
In-Reply-To: <iIvh9aJddvff3RxftBKJrWgNupDzLoFOt0t1oM7Tfjk=.f56581c6-881a-4576-9e2d-8ffa5c76e95b@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
 <h69ZxPIqvI9G0R2JqI3SWePcLOptqHuvrL4SkzQGvhc=.f0a1844f-99b2-4393-963b-c0410c3bb68c@github.com>
 <iIvh9aJddvff3RxftBKJrWgNupDzLoFOt0t1oM7Tfjk=.f56581c6-881a-4576-9e2d-8ffa5c76e95b@github.com>
Message-ID: <P8q8EeezP78TSteJwgdjfFKFU04GZcv7Yz7jvkklkAE=.c591fc01-cdd7-4f26-942e-fec585551f0c@github.com>

On Wed, 10 Nov 2021 11:03:23 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> Concerning `<tbody>`, quote (emphasis mine):
> 
> > As your tables get a bit more complex in structure, it is useful to give them more structural definition. One clear way to do this is by using `<thead>`, `<tfoot>`, and `<tbody>`, which allow you to mark up a header, footer, and body section for the table.
> 
> > **These elements don't make the table any more accessible to screenreader users**, and don't result in any visual enhancement on their own. They are however very useful for styling and layout ? acting as useful hooks for adding CSS to your table.
> 
> Based on this, I don't see a foundation for having several tbodies. Am I missing something?

The definition of [`rowgroup` keyword](https://html.spec.whatwg.org/dev/tables.html#attr-th-scope-rowgroup) is as follows:
> The row group state means the header cell applies to all the remaining cells in the row group. A `th` element's `scope` attribute must not be in the row group state if the element is not anchored in a row group.

As I read the definition, having `<th scope="rowgroup">` requires that the corresponding `th` element is in a row group (`tbody`) and such _a heading applies to all the cells in the row group_. Thus, without creating the second row group the cell `<th scope="rowgroup">Arabic` from the first row applies to all the subsequent cells in the table including `<th scope="rowgroup">Tai Tham`.

[The following example](https://html.spec.whatwg.org/dev/tables.html#the-th-element:attr-th-scope-6) on that page discusses the same situation: a heading cell with `scope="rowgroup"` applies to all the cells in a row group defined by `tbody`. Our situation is similar yet the second row group contains only one row.

It's why I think the table must have *two* row groups: for _Arabic_ and for _Tai Tham_, even though it doesn't change the visual presentation.

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

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


From aivanov at openjdk.java.net  Wed Nov 10 16:24:38 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 10 Nov 2021 16:24:38 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html [v2]
In-Reply-To: <cKWvKczTfPiIGUNh3r788Lw9okU4qzDyusNRnyu4x7c=.e132018a-99f4-4a50-95dd-a3ad3fdaec14@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
 <kBc5yJxF1e4jJCKFZTp5gsn_IKoD1gwDVvmNplPMH5c=.4ae75834-20b3-4ba4-958e-b9f8a152fcb6@github.com>
 <lawM9GydemIPMh1_oBD-FnJmf8XHeqrpMbXciv2fKYk=.fa3c3369-ce52-47fa-8b4a-ec4584e5e9c6@github.com>
 <cKWvKczTfPiIGUNh3r788Lw9okU4qzDyusNRnyu4x7c=.e132018a-99f4-4a50-95dd-a3ad3fdaec14@github.com>
Message-ID: <deSQNk5oKjJ7RS2eNcbnDHPEGRhsNCuvkyx4sOGaOus=.be54a800-18f4-44ea-b172-94d93426eed9@github.com>

On Wed, 10 Nov 2021 11:04:54 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

>> src/java.desktop/share/classes/java/awt/font/NumericShaper.java line 117:
>> 
>>> 115:  *     <th scope="col" id="colheader1">Unicode Range
>>> 116:  *     <th scope="col" id="colheader2">{@code NumericShaper} Constants
>>> 117:  *     <th scope="col" id="colheader3">Precedence
>> 
>> Shall we use more descriptive ids?
>> Suggestion:
>> 
>>  *     <th scope="col" id="nsUnicodeRangeHeader">Unicode Range
>>  *     <th scope="col" id="nsConstantsHeader">{@code NumericShaper} Constants
>>  *     <th scope="col" id="nsPrecedence">Precedence
>
> Not relevant anymore given last change

Why is it not relevant? You're still using the ids?
I see you've removed the `header` attribute but I still `id` attributes. Will you be removing the id attributes too?

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

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


From cjplummer at openjdk.java.net  Wed Nov 10 16:46:34 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 10 Nov 2021 16:46:34 GMT
Subject: RFR: 8276930: Update ProblemList [v2]
In-Reply-To: <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com>
References: <dQ6b3JbfcCO0qrnPvLAs0GDzc2T_wVM0FZefMfnfrtA=.17346bb3-b982-4cc1-ab7b-415280cf331e@github.com>
 <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com>
Message-ID: <whobvovE_LgrQNGX6eGBNCnq84AHUTGRIe6H4QAglgA=.e343f8ca-4323-4ed0-a85f-64d5dbb39604@github.com>

On Wed, 10 Nov 2021 10:41:56 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Update a few entries in the problemlist that refer to bugs that have been closed as duplicates.
>
> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved non-instrument tests to the right place

test/jdk/ProblemList.txt line 789:

> 787: # svc_tools
> 788: 
> 789: sun/tools/jhsdb/BasicLauncherTest.java                          8228649 linux-ppc64,linux-ppc64le

8228649 is also resolved. Maybe this isn't an issue anymore. Would need to ask someone on the PPC team.

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

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


From duke at openjdk.java.net  Wed Nov 10 17:34:33 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Wed, 10 Nov 2021 17:34:33 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html [v3]
In-Reply-To: <KHZ40DO2aMz5K-7Fisvw4DFcgZFXY8-HZt3mIzt34sg=.b4a60280-c657-4e43-9ad7-29bea56c7766@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
 <KHZ40DO2aMz5K-7Fisvw4DFcgZFXY8-HZt3mIzt34sg=.b4a60280-c657-4e43-9ad7-29bea56c7766@github.com>
Message-ID: <Pj2n90t_x7GhEgJhnLzSfVGnVa4_2H2eQf0rDNTJGDM=.bf10e73c-dcb2-4883-b0d8-940a23fef26d@github.com>

On Wed, 10 Nov 2021 10:58:08 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

>> This change introduces no visual difference, but improves a11y.
>
> Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Most idiomatic version so far

Ah, I see. In that case, I'll be reintroducing the two tbodies, and removing the ids I forgot to remove.

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

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


From duke at openjdk.java.net  Wed Nov 10 17:41:08 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Wed, 10 Nov 2021 17:41:08 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html [v4]
In-Reply-To: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
Message-ID: <ZuwYlU5eRU1yIDOet1EPOmrJztbBZXbbs7PiIjNBQr0=.c5bf3b3a-0422-46be-8199-8043d94743b0@github.com>

> This change introduces no visual difference, but improves a11y.

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

  remove ids, reintroduce two tbodies

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6291/files
  - new: https://git.openjdk.java.net/jdk/pull/6291/files/718e36ca..207332f8

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

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

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


From aivanov at openjdk.java.net  Wed Nov 10 19:34:35 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 10 Nov 2021 19:34:35 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html [v4]
In-Reply-To: <ZuwYlU5eRU1yIDOet1EPOmrJztbBZXbbs7PiIjNBQr0=.c5bf3b3a-0422-46be-8199-8043d94743b0@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
 <ZuwYlU5eRU1yIDOet1EPOmrJztbBZXbbs7PiIjNBQr0=.c5bf3b3a-0422-46be-8199-8043d94743b0@github.com>
Message-ID: <7uKH6mtUkg_lgn-nZtgV2NSAJeTNxNEQDkT_rv4yKLo=.e5e7e2fe-fa9c-45b1-a824-5437262c00e7@github.com>

On Wed, 10 Nov 2021 17:41:08 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

>> This change introduces no visual difference, but improves a11y.
>
> Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ids, reintroduce two tbodies

Not ideal, but I guess it's the best we can do.

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

Marked as reviewed by aivanov (Reviewer).

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


From achung at openjdk.java.net  Wed Nov 10 20:11:40 2021
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 10 Nov 2021 20:11:40 GMT
Subject: Integrated: 8276678: Malformed Javadoc inline tags in JDK source in
 com/sun/beans/decoder/DocumentHandler.java
In-Reply-To: <Cj5hn3zbefTQkuvrEF_vDvCEQVEVu3bpDl7_mJRiDD0=.066875af-5883-4aaa-bc4d-05af0798902c@github.com>
References: <Cj5hn3zbefTQkuvrEF_vDvCEQVEVu3bpDl7_mJRiDD0=.066875af-5883-4aaa-bc4d-05af0798902c@github.com>
Message-ID: <WfXPcLSm5070Td9kbxx4oBAC6rPKqRP6wI0LcyJSBxg=.ca84cdfc-ea67-4754-a211-7673de3290df@github.com>

On Mon, 8 Nov 2021 17:08:36 GMT, Alisen Chung <achung at openjdk.org> wrote:

> fixed malformed inline tags

This pull request has now been integrated.

Changeset: 2374abda
Author:    Alisen Chung <achung at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2374abda19213d615a72c83f584ea61d5bbba4a3
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8276678: Malformed Javadoc inline tags in JDK source in com/sun/beans/decoder/DocumentHandler.java

Reviewed-by: serb, aivanov

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

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


From aivanov at openjdk.java.net  Wed Nov 10 20:12:37 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 10 Nov 2021 20:12:37 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html [v4]
In-Reply-To: <ZuwYlU5eRU1yIDOet1EPOmrJztbBZXbbs7PiIjNBQr0=.c5bf3b3a-0422-46be-8199-8043d94743b0@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
 <ZuwYlU5eRU1yIDOet1EPOmrJztbBZXbbs7PiIjNBQr0=.c5bf3b3a-0422-46be-8199-8043d94743b0@github.com>
Message-ID: <QbR2ZCzTzCUrgOvHzsjs3TanNhx51XU1TTl4t_R8ef4=.bd400f27-e92c-4c0e-abe5-ff67551d638d@github.com>

On Wed, 10 Nov 2021 17:41:08 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

>> This change introduces no visual difference, but improves a11y.
>
> Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ids, reintroduce two tbodies

As expected, the values in the second row are rendered in bold and are centered. Leave them centered or left-align? I don't have a strong opinion for either.

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

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


From serb at openjdk.java.net  Wed Nov 10 21:37:49 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 10 Nov 2021 21:37:49 GMT
Subject: RFR: 8270874: JFrame paint artifacts when dragged from standard
 monitor to HiDPI monitor
Message-ID: <hPV-NYDHAMhyOviuU89e9Frm1ALNGqn_Uw0i4NDscRE=.e3fcd015-0bc5-4e7a-92f0-8474ee8af548@github.com>

The bug occurs more often if initially the window is moved partly outside of the first screen(let's name this part as the invisible part), and then slowly moved to the second screen where that invisible part became visible on the second screen.

The problem is how we try to repaint the frame. The Windows send us coordinates to repaint in the device space, if the width/height values are less than a unit in the user's space, we round it to the empty rectangle and skip it.

Solution: request to repaint the smallest non-empty bounding box in the user's space around the region of pixels.

Workaround: repaint the whole window on the component resize/move event or at the end of the drag.

Notes:
 * It is not reproducible(at least much less often) when d3d is enabled because the d3d pipeline sends repaint events more often (example https://github.com/openjdk/jdk/pull/6064). That hides the current issue.
 * It started to be reproducible during the drag from one screen to another after JDK-8211999 because before JDK-8211999 we make a resize at the end of the drag, which caused the full repaint of the window.

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

Commit messages:
 - Update WindowResizingOnMovingToAnotherDisplay.java
 - Initial fix JDK-8270874

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

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


From jwilhelm at openjdk.java.net  Thu Nov 11 00:00:35 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 11 Nov 2021 00:00:35 GMT
Subject: RFR: 8276930: Update ProblemList [v2]
In-Reply-To: <whobvovE_LgrQNGX6eGBNCnq84AHUTGRIe6H4QAglgA=.e343f8ca-4323-4ed0-a85f-64d5dbb39604@github.com>
References: <dQ6b3JbfcCO0qrnPvLAs0GDzc2T_wVM0FZefMfnfrtA=.17346bb3-b982-4cc1-ab7b-415280cf331e@github.com>
 <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com>
 <whobvovE_LgrQNGX6eGBNCnq84AHUTGRIe6H4QAglgA=.e343f8ca-4323-4ed0-a85f-64d5dbb39604@github.com>
Message-ID: <QsxDZOhxn3K56I_N58zxtAbTReRLvRknHcHnLDCL3JQ=.06b80eea-7bcf-4463-9a55-c8ac70e2cde4@github.com>

On Wed, 10 Nov 2021 16:42:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved non-instrument tests to the right place
>
> test/jdk/ProblemList.txt line 789:
> 
>> 787: # svc_tools
>> 788: 
>> 789: sun/tools/jhsdb/BasicLauncherTest.java                          8228649 linux-ppc64,linux-ppc64le
> 
> 8228649 is also resolved. Maybe this isn't an issue anymore. Would need to ask someone on the PPC team.

Yes, there were a couple of them that was duplicates of closed bugs, but this change only deals with duplicates. To actually remove the tests from the list I would need to run them for a while to make sure they pass now. That's a later task.

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

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


From dholmes at openjdk.java.net  Thu Nov 11 01:14:39 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 11 Nov 2021 01:14:39 GMT
Subject: RFR: 8276930: Update ProblemList [v2]
In-Reply-To: <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com>
References: <dQ6b3JbfcCO0qrnPvLAs0GDzc2T_wVM0FZefMfnfrtA=.17346bb3-b982-4cc1-ab7b-415280cf331e@github.com>
 <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com>
Message-ID: <u-bfy2KLuzxFur5_wt8_zfAyLrrXUzzzHPIFXBjj46A=.b7522017-054d-4096-9de3-30993f9c94aa@github.com>

On Wed, 10 Nov 2021 10:41:56 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Update a few entries in the problemlist that refer to bugs that have been closed as duplicates.
>
> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved non-instrument tests to the right place

Hi Jesper,

Switching to the alternate bug id looks good.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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


From jwilhelm at openjdk.java.net  Thu Nov 11 01:17:40 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 11 Nov 2021 01:17:40 GMT
Subject: Integrated: 8276930: Update ProblemList
In-Reply-To: <dQ6b3JbfcCO0qrnPvLAs0GDzc2T_wVM0FZefMfnfrtA=.17346bb3-b982-4cc1-ab7b-415280cf331e@github.com>
References: <dQ6b3JbfcCO0qrnPvLAs0GDzc2T_wVM0FZefMfnfrtA=.17346bb3-b982-4cc1-ab7b-415280cf331e@github.com>
Message-ID: <MKs10JGe_5ogt44gA4kCP5f8bLdfo1CrPBpCYHdnG3M=.01ddeb5d-d1cd-4d5d-b72c-aef0ad7280c0@github.com>

On Wed, 10 Nov 2021 09:30:38 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Update a few entries in the problemlist that refer to bugs that have been closed as duplicates.

This pull request has now been integrated.

Changeset: e27a67a9
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e27a67a91647e584411a9ef57c0a028ab37af19b
Stats:     17 lines in 1 file changed: 4 ins; 5 del; 8 mod

8276930: Update ProblemList

Reviewed-by: kevinw, dholmes

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

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


From serb at openjdk.java.net  Thu Nov 11 02:32:33 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 11 Nov 2021 02:32:33 GMT
Subject: RFR: 8079267: [TEST_BUG] Test
 java/awt/Frame/MiscUndecorated/RepaintTest.java fails
In-Reply-To: <D3GP12GLPR9xzPb5FWN42g_HZkqUTUKdgBabiiJOECA=.800914e0-274f-405a-becd-fdd1a9271d1c@github.com>
References: <D3GP12GLPR9xzPb5FWN42g_HZkqUTUKdgBabiiJOECA=.800914e0-274f-405a-becd-fdd1a9271d1c@github.com>
Message-ID: <ETWWv8G-TbYKyEduSCXWoUXWKIQRpxtzM0ZYVwrJtn0=.d60e9323-86e8-44cb-bd24-0fa6012caadb@github.com>

On Thu, 28 Oct 2021 13:24:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test does not fail on Windows and does fail on Linux. 
> 
> After de-iconification we expect to see the button focused:
> ![image](https://user-images.githubusercontent.com/77687766/139171852-54413dba-d58a-46d4-ab83-59d93868e287.png)
> 
> Actual look:
> ![image](https://user-images.githubusercontent.com/77687766/139171775-80e64e58-c49d-489a-8fe0-fb0640fc3be9.png)
> 
> Button loses focus on `frame.to Front()` call, after its removal test passes. There is an [open issue](https://bugs.openjdk.java.net/browse/JDK-7156130) for this.
> 
> 
> Some cleanup was also made. Testing is green for all platforms.
> 
> 
> I am unable to reproduce [8266244 / macosx-aarch64](https://bugs.openjdk.java.net/browse/JDK-8266244), however it is not removed from the problem list due to its intermittent nature which needs more time to investigate.

Marked as reviewed by serb (Reviewer).

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

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


From jdv at openjdk.java.net  Thu Nov 11 06:01:08 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 11 Nov 2021 06:01:08 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS
Message-ID: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>

When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".

Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.

SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.

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

Commit messages:
 - 8276905: Function frag_col has a deployment target which is incompatible with this OS

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

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


From myano at openjdk.java.net  Thu Nov 11 08:41:37 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 11 Nov 2021 08:41:37 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails [v2]
In-Reply-To: <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>
 <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
Message-ID: <zdjnPGIsBk8kCaWzjCoCX1cX5mocG3uMtlv9MA0KZk0=.c48bbd17-ee92-4df1-9c7a-e121b48a0521@github.com>

On Tue, 26 Oct 2021 04:52:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Masanori Yano 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:
>> 
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - Merge branch 'master' of https://github.com/masyano/jdk into 7001973
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>
> I'll check it, let me some time.

@mrserb How is the test running? Could you give me a reply?

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

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


From myano at openjdk.java.net  Thu Nov 11 08:50:34 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 11 Nov 2021 08:50:34 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <aZX6pJkrGOTYLlAHRl9WlEGtoahiInx4QzelDWpV2b0=.c9a736f9-5dd5-4382-8513-94a0233105dc@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <-hj0v7RZ0HPpP9GND5csZsZ1Vz7oxaufOAC0-ZygtwM=.6a5ae7a8-52d6-4e3e-a166-2fae2c23dbe0@github.com>
 <cTqTWZsK6uJI_Kw9nUymKQnYxxzWBRrk52qJAKpAc9I=.18f7dffd-3ebe-4bd0-bc2f-d61b55437036@github.com>
 <aZX6pJkrGOTYLlAHRl9WlEGtoahiInx4QzelDWpV2b0=.c9a736f9-5dd5-4382-8513-94a0233105dc@github.com>
Message-ID: <QPyLlBXqr80h-_OjGxuv6tGNl8_-IZ8IHF-_8QWy894=.b18fd0a2-4497-4aae-87b1-1570531f2862@github.com>

On Thu, 28 Oct 2021 09:03:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yes, this run() is called on "D3D Screen Updater" thread. It is reasonable that a new PaintEvent is posted when SurfaceData is replaced on this thread. I would limit posting new PaintEvent via createGraphics() only.
>
> Probably I should clarify my question, you added a parameter to the validate method and pass the "true" so the "validate" method will post a paint event, but just a few lines below there is a comment that the next code line "sd.getPeer().replaceSurfaceDataLater();" also will post an event. Is the comment outdated, or we will post two of them?

@mrserb How long will it take to review this fix?

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

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


From duke at openjdk.java.net  Thu Nov 11 09:29:34 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Thu, 11 Nov 2021 09:29:34 GMT
Subject: RFR: JDK-8276800 Fix table headers in NumericShaper.html [v4]
In-Reply-To: <ZuwYlU5eRU1yIDOet1EPOmrJztbBZXbbs7PiIjNBQr0=.c5bf3b3a-0422-46be-8199-8043d94743b0@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
 <ZuwYlU5eRU1yIDOet1EPOmrJztbBZXbbs7PiIjNBQr0=.c5bf3b3a-0422-46be-8199-8043d94743b0@github.com>
Message-ID: <Va-pm1HJ4ohq7JjtGRsyb4oNfVpndfBKAOCwWf1nVAA=.689ed8d2-2192-4c64-9ce0-f805002685ab@github.com>

On Wed, 10 Nov 2021 17:41:08 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

>> This change introduces no visual difference, but improves a11y.
>> EDIT: There is a slight visual change regarding centering in a few cells.
>
> Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ids, reintroduce two tbodies

There were arguments in our discussion earlier about letting the rendering reflect the HTML semantics, so I'm inclined to leave it like this.

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

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


From duke at openjdk.java.net  Thu Nov 11 09:44:15 2021
From: duke at openjdk.java.net (Jeremy)
Date: Thu, 11 Nov 2021 09:44:15 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v6]
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <7-hDZ7WMMVfHbExgTa5fSpJC0X1qgVge_T_awtGC2kA=.16410763-6aa4-45e5-94c0-ac9bf0016c0f@github.com>

> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
> 
> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
> B. Updating the unit test to forgive the discrepancy.
> 
> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
> 
> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
> 
> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

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

  8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
  
  This adds an exploratory algorithm that tries to identify how to expand the double-based bounding box. It is currently problematic, but I'm committing it for review/feedback. Maybe this will look like a familiar problem to someone more familiar with this subject? Once we settle on how to address machine error: I'll either adapt this file into a more proper unit test or delete it.
  
  This is an attempt to explore Laurent's comments here:
  https://github.com/openjdk/jdk/pull/6227#discussion_r746450132
  
  The problem is our double-based approach can be a little bit too small because of machine error. We need it to only ever err on the side of being too large.
  
  Currently in this class we're applying a `margin` as follows:
  ```
         double x = coeff[0] + t * (coeff[1] + t * coeff[2]);
         double margin = marginMultiplier * Math.ulp(x);
         if (x - margin < leftX) leftX = x - margin;
         if (x + margin> rightX) rightX = x + margin;
  ```
  
  This class tests a million shapes and tries to identify the smallest constant `marginMultiplier` that always returns an appropriate bounding box.
  
  The current problem is this constant is multiplied by the ulp of a value. So as the value (for ex: the left x-value) approaches zero the ulp becomes increasingly small, so the multiplier has to become extremely large. Currently this algorithm settles on a multiplier of: 7.864956084850002E10
  
  If we treat the constant as a multiplier of the x-value itself (for ex: `margin = multiplier * Math.abs(x)``), then this algorithm settles on 0.000013173867835580114.
  
  What is a good way to evaluate `margin` in the code snippet above?
  
  Or at some point we could switch back to using the bezier control point: what fuzzy sliding scale logic do we use to determine when to use "the old way" and when to use "the new way"?

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6227/files
  - new: https://git.openjdk.java.net/jdk/pull/6227/files/b7ca69c8..4b9d87d6

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

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

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


From duke at openjdk.java.net  Thu Nov 11 09:44:17 2021
From: duke at openjdk.java.net (Jeremy)
Date: Thu, 11 Nov 2021 09:44:17 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <Q4-YZst7t1biWjzhw5lvCaAbe9aZ_lklJ-PpiSKKayw=.85696551-6ef8-4e93-a3fc-29590b46de84@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
 <CeEMRyzppq2-yaby7fFDWT3ekeWJfRfD3Sp-dhY3scA=.723fad96-6c84-4583-a691-57152e3ec3dc@github.com>
 <7FgkHca8tdzn8chwJ6RsYWyuFVmtAQOl3xN17BiFhrg=.924d80dc-3171-45b4-a601-448bf3194aca@github.com>
 <2qVmqXHwGTEu7-fREZKtL8CBTnkgTf2pDpA1rFo5CVI=.7868c3ec-d91c-4d31-9751-28750be11968@github.com>
 <xIRXpvayrwFFU_Wo5XoLtHeKb5HUqNxxLcW3dE1h9Cc=.a7b379fa-b418-48b0-8714-b8182f81f950@github.com>
 <NZ7cYRk4MLJzGcGsu3ZGQOGU8KfCI-W9QheoW-55JC4=.7262f6dd-207b-4b75-bd49-58b7305277f6@github.com>
 <Q4-YZst7t1biWjzhw5lvCaAbe9aZ_lklJ-PpiSKKayw=.85696551-6ef8-4e93-a3fc-29590b46de84@github.com>
Message-ID: <h89bp5udPKNgAOSvGSQg8LnBv9nU9Nm7inhQ1VTcQr8=.d0e7dbcc-d898-495d-81f5-c79fc823ac8d@github.com>

On Wed, 10 Nov 2021 10:25:55 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> @prrace @mrserb what do you think on this bug in terms of precision requirements?
>> - should bbox always include control points ?
>> - should ideal shape always fit in bbox ? So I propose to add a margin > numerical inaccuracies.
>> 
>> I can develop a numerical approach based on fuzzy testing:
>> - generate random curves (high magnitude changes on control points)
>> - use both this algorithm (double) and implement the same with BigDecimal
>> - estimate the extrema error = max distance(pts big decimal, pts double)
>
> Ideally jdk could provide new math methods:
> - evalPoly(eqn[])
> - find roots...
> Based on compensated horner scheme and Math.fma() ~ 0.5 ulp

I attempted to explore a numerical approach to pad the bounding box here 4b9d87d6d03e923bb2663fc8f4f77b7549df6e70 ... but I don't like the results so far. Any suggestions? (Or if you have a better approach in mind we can discard that entire class...)

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

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


From lbourges at openjdk.java.net  Thu Nov 11 10:21:35 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 11 Nov 2021 10:21:35 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <h89bp5udPKNgAOSvGSQg8LnBv9nU9Nm7inhQ1VTcQr8=.d0e7dbcc-d898-495d-81f5-c79fc823ac8d@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
 <CeEMRyzppq2-yaby7fFDWT3ekeWJfRfD3Sp-dhY3scA=.723fad96-6c84-4583-a691-57152e3ec3dc@github.com>
 <7FgkHca8tdzn8chwJ6RsYWyuFVmtAQOl3xN17BiFhrg=.924d80dc-3171-45b4-a601-448bf3194aca@github.com>
 <2qVmqXHwGTEu7-fREZKtL8CBTnkgTf2pDpA1rFo5CVI=.7868c3ec-d91c-4d31-9751-28750be11968@github.com>
 <xIRXpvayrwFFU_Wo5XoLtHeKb5HUqNxxLcW3dE1h9Cc=.a7b379fa-b418-48b0-8714-b8182f81f950@github.com>
 <NZ7cYRk4MLJzGcGsu3ZGQOGU8KfCI-W9QheoW-55JC4=.7262f6dd-207b-4b75-bd49-58b7305277f6@github.com>
 <Q4-YZst7t1biWjzhw5lvCaAbe9aZ_lklJ-PpiSKKayw=.85696551-6ef8-4e93-a3fc-29590b46de84@github.com>
 <h89bp5udPKNgAOSvGSQg8LnBv9nU9Nm7inhQ1VTcQr8=.d0e7dbcc-d898-495d-81f5-c79fc823ac8d@github.com>
Message-ID: <dxSJxjm6ertf9togbKd7XwErlS5O_UR59kgzdjreoas=.20349b5b-674a-4273-9449-997db15fd40e@github.com>

On Thu, 11 Nov 2021 09:40:07 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> Ideally jdk could provide new math methods:
>> - evalPoly(eqn[])
>> - find roots...
>> Based on compensated horner scheme and Math.fma() ~ 0.5 ulp
>
> I attempted to explore a numerical approach to pad the bounding box here 4b9d87d6d03e923bb2663fc8f4f77b7549df6e70 ... but I don't like the results so far. Any suggestions? (Or if you have a better approach in mind we can discard that entire class...)

You made an amazing job !
Your bigdecimal impl looks good.
I will play with your test experiment... asap.
I think numerical accuracies are related to the dynamic /magnitude of values: points.
The test should evaluate(max error) depending on the quick length(curve) ~ manhattan norm(curve arms), so small curves have less numerical error whereas huge curve (10^50 length) means points are wide spread and coeffs... solver...points are less accurate.

I will try making sampled control points vary in log scale: 10^-6 to 10^38 (float max) so curve length will vary in huge range and determine the histogram of max(error) / length ratio.

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

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


From lbourges at openjdk.java.net  Thu Nov 11 10:29:42 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 11 Nov 2021 10:29:42 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <dxSJxjm6ertf9togbKd7XwErlS5O_UR59kgzdjreoas=.20349b5b-674a-4273-9449-997db15fd40e@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
 <CeEMRyzppq2-yaby7fFDWT3ekeWJfRfD3Sp-dhY3scA=.723fad96-6c84-4583-a691-57152e3ec3dc@github.com>
 <7FgkHca8tdzn8chwJ6RsYWyuFVmtAQOl3xN17BiFhrg=.924d80dc-3171-45b4-a601-448bf3194aca@github.com>
 <2qVmqXHwGTEu7-fREZKtL8CBTnkgTf2pDpA1rFo5CVI=.7868c3ec-d91c-4d31-9751-28750be11968@github.com>
 <xIRXpvayrwFFU_Wo5XoLtHeKb5HUqNxxLcW3dE1h9Cc=.a7b379fa-b418-48b0-8714-b8182f81f950@github.com>
 <NZ7cYRk4MLJzGcGsu3ZGQOGU8KfCI-W9QheoW-55JC4=.7262f6dd-207b-4b75-bd49-58b7305277f6@github.com>
 <Q4-YZst7t1biWjzhw5lvCaAbe9aZ_lklJ-PpiSKKayw=.85696551-6ef8-4e93-a3fc-29590b46de84@github.com>
 <h89bp5udPKNgAOSvGSQg8LnBv9nU9Nm7inhQ1VTcQr8=.d0e7dbcc-d898-495d-81f5-c79fc823ac8d@github.com>
 <dxSJxjm6ertf9togbKd7XwErlS5O_UR59kgzdjreoas=.20349b5b-674a-4273-9449-997db15fd40e@github.com>
Message-ID: <UsAaWyanTR2eT5iOWWyMz9txyrMKXoyOxtSWmMgRhZs=.580a6b36-7353-4dbe-b975-a7206bb96a92@github.com>

On Thu, 11 Nov 2021 10:18:29 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> I attempted to explore a numerical approach to pad the bounding box here 4b9d87d6d03e923bb2663fc8f4f77b7549df6e70 ... but I don't like the results so far. Any suggestions? (Or if you have a better approach in mind we can discard that entire class...)
>
> You made an amazing job !
> Your bigdecimal impl looks good.
> I will play with your test experiment... asap.
> I think numerical accuracies are related to the dynamic /magnitude of values: points.
> The test should evaluate(max error) depending on the quick length(curve) ~ manhattan norm(curve arms), so small curves have less numerical error whereas huge curve (10^50 length) means points are wide spread and coeffs... solver...points are less accurate.
> 
> I will try making sampled control points vary in log scale: 10^-6 to 10^38 (float max) so curve length will vary in huge range and determine the histogram of max(error) / length ratio.

see condition number = magnitude range on such plot:
https://github.com/JuliaMath/AccurateArithmetic.jl/blob/master/test/figs/sum_accuracy.svg

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

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


From ihse at openjdk.java.net  Thu Nov 11 13:56:34 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 11 Nov 2021 13:56:34 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS
In-Reply-To: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
Message-ID: <Prz25CF6e1xs0XL9Vc9RpSRQRZ0J0xKOVjw1rNBk8YA=.f1d6f5c7-3225-4378-ada4-e4d8a43c2127@github.com>

On Thu, 11 Nov 2021 05:52:18 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
> 
> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
> 
> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.

We should not hard-code version numbers like that.

Fortunately for you, there already exists a variable $(MACOSX_VERSION_MIN) that you can use.

Also, if you did not create this patch yourself, please make sure to use `/contributor` to give proper credits. Or maybe you mean that Vitaly submitted the bug report, not the patch?

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

Changes requested by ihse (Reviewer).

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


From jdv at openjdk.java.net  Thu Nov 11 15:32:01 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 11 Nov 2021 15:32:01 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
Message-ID: <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>

> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
> 
> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
> 
> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Use Macro for version

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6346/files
  - new: https://git.openjdk.java.net/jdk/pull/6346/files/a9f521a5..7f999650

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

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

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


From jdv at openjdk.java.net  Thu Nov 11 15:32:04 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 11 Nov 2021 15:32:04 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS
In-Reply-To: <Prz25CF6e1xs0XL9Vc9RpSRQRZ0J0xKOVjw1rNBk8YA=.f1d6f5c7-3225-4378-ada4-e4d8a43c2127@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <Prz25CF6e1xs0XL9Vc9RpSRQRZ0J0xKOVjw1rNBk8YA=.f1d6f5c7-3225-4378-ada4-e4d8a43c2127@github.com>
Message-ID: <_FNKFljLEaG0mIWqtPm7vaUUO_UKLMiR2R6tlsu1KNE=.9dc78629-3b4a-4717-bc34-bf270f93e26e@github.com>

On Thu, 11 Nov 2021 13:53:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Also, if you did not create this patch yourself, please make sure to use `/contributor` to give proper credits. Or maybe you mean that Vitaly submitted the bug report, not the patch?

By Submitter i meant submitter of bug in JBS. I was not able to verify the patch in our CI, so i shared the patch with Vitaly so that he can verify the reproducibility of the issue.

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

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


From jdv at openjdk.java.net  Thu Nov 11 15:32:02 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 11 Nov 2021 15:32:02 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <Prz25CF6e1xs0XL9Vc9RpSRQRZ0J0xKOVjw1rNBk8YA=.f1d6f5c7-3225-4378-ada4-e4d8a43c2127@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <Prz25CF6e1xs0XL9Vc9RpSRQRZ0J0xKOVjw1rNBk8YA=.f1d6f5c7-3225-4378-ada4-e4d8a43c2127@github.com>
Message-ID: <htwz_sdjBLjH1sxoVS-b_0efqMSh8gNafCNEPPFuXk4=.153710ee-4989-4a5d-9c89-35cc903da4d5@github.com>

On Thu, 11 Nov 2021 13:52:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We should not hard-code version numbers like that.
> 
> Fortunately for you, there already exists a variable $(MACOSX_VERSION_MIN) that you can use.

Thanks for the review i have updated code to use the Macro.

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

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


From mbaesken at openjdk.java.net  Thu Nov 11 16:02:41 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 11 Nov 2021 16:02:41 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows
In-Reply-To: <_8d2ZM_CXYdT8T9sM-Fo3ukpGfeFwIL1Ja6NnxdtWfM=.b881c420-934a-4bc5-b5d1-020c6cf09710@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
 <gVSUXx-iZ3g_7ImZWlonOSJ975OA3JRvaGZqYs79XoU=.f2d7e04a-bf03-4cd6-88af-6609f5368633@github.com>
 <669N85kj3NJ9LBmLySry9gncEzHOLsxmyTSgSJ9iuKA=.84146bec-e572-43a4-a260-c771e709caea@github.com>
 <TNIzf3oTslrWSF2fiNjyFZSRy9FQlKe0B85EFYilqRk=.6a62544f-dd0f-4684-9971-b6d132029310@github.com>
 <_8d2ZM_CXYdT8T9sM-Fo3ukpGfeFwIL1Ja6NnxdtWfM=.b881c420-934a-4bc5-b5d1-020c6cf09710@github.com>
Message-ID: <X0s8JYNbZUBUTadloGIawVo1foBsKpEK3exh3AVzQFQ=.0562cc15-a19d-4c0c-8aa7-d358f1356316@github.com>

On Wed, 10 Nov 2021 08:47:10 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> I think Xcheck:jni raises a warning when two JNI calls are made in a row w/o calling exception check in between. So it is not necessary to have an actual exception to produce a warning.
>> 
>> Probably it is reproduced there, because that system is "true" headless, and the execution code path is just different, or something like that, need to check what is the next/prev JNI call.
>> Or maybe this method really throw an exception, need some more detail.
>
> Hello,  in our central tests it was indeed a fastdbg OpenJDK.   On my local Windows 10 machine I could not reproduce it.
> Our central tests run with -Djava.awt.headless=true , but I think the Win2019 server machine itself is not headless .

I could add a  J2dTraceLn(J2D_TRACE_ERROR, . . . )  in case an exception occurs.  The J2dTraceLn  is already used at some other places in  DWMIsCompositionEnabled so it might fit better than just ignoring the exception.

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

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


From ihse at openjdk.java.net  Thu Nov 11 16:25:35 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 11 Nov 2021 16:25:35 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
Message-ID: <o87kvDcKEAnNF_WRWiFSgaJmWuzEBsxGP8AUQfYH3qw=.ee318771-2468-497e-a6ff-af47d126522c@github.com>

On Thu, 11 Nov 2021 15:32:01 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
>> 
>> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
>> 
>> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Macro for version

Marked as reviewed by ihse (Reviewer).

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

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


From duke at openjdk.java.net  Thu Nov 11 16:50:47 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Thu, 11 Nov 2021 16:50:47 GMT
Subject: Integrated: JDK-8276800 Fix table headers in NumericShaper.html
In-Reply-To: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
References: <8kvoru3y5o4Ia5r1V5Cy6phfwONhAs7PE9je3AgOgF0=.a46280a2-2802-4d4d-8b7e-eda771bbb947@github.com>
Message-ID: <MpKs71VHsmyK7EoNHhMu_6ruT8MyWUAJ4yDRXCR1-nc=.7bb405a0-2065-4b77-9757-f6b7dd24434b@github.com>

On Mon, 8 Nov 2021 09:13:35 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> This change introduces no visual difference, but improves a11y.
> EDIT: There is a slight visual change regarding centering in a few cells.

This pull request has now been integrated.

Changeset: 5e98f993
Author:    Ludvig Janiuk <ludvig.j.janiuk at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5e98f993b3cd68bb8564ea904f322235f55c4a7c
Stats:     5 lines in 1 file changed: 0 ins; 1 del; 4 mod

8276800: Fix table headers in NumericShaper.html

Reviewed-by: naoto, aivanov

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

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


From azvegint at openjdk.java.net  Thu Nov 11 16:56:40 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 11 Nov 2021 16:56:40 GMT
Subject: Integrated: 8079267: [TEST_BUG] Test
 java/awt/Frame/MiscUndecorated/RepaintTest.java fails
In-Reply-To: <D3GP12GLPR9xzPb5FWN42g_HZkqUTUKdgBabiiJOECA=.800914e0-274f-405a-becd-fdd1a9271d1c@github.com>
References: <D3GP12GLPR9xzPb5FWN42g_HZkqUTUKdgBabiiJOECA=.800914e0-274f-405a-becd-fdd1a9271d1c@github.com>
Message-ID: <-CVu-KE6Jrr6NmJ014eJR6GuQ5vD6rvOyOiUd5BvKIA=.b34a6a15-779b-4c71-93e1-052b3306fdb6@github.com>

On Thu, 28 Oct 2021 13:24:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test does not fail on Windows and does fail on Linux. 
> 
> After de-iconification we expect to see the button focused:
> ![image](https://user-images.githubusercontent.com/77687766/139171852-54413dba-d58a-46d4-ab83-59d93868e287.png)
> 
> Actual look:
> ![image](https://user-images.githubusercontent.com/77687766/139171775-80e64e58-c49d-489a-8fe0-fb0640fc3be9.png)
> 
> Button loses focus on `frame.to Front()` call, after its removal test passes. There is an [open issue](https://bugs.openjdk.java.net/browse/JDK-7156130) for this.
> 
> 
> Some cleanup was also made. Testing is green for all platforms.
> 
> 
> I am unable to reproduce [8266244 / macosx-aarch64](https://bugs.openjdk.java.net/browse/JDK-8266244), however it is not removed from the problem list due to its intermittent nature which needs more time to investigate.

This pull request has now been integrated.

Changeset: 6f35eede
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6f35eede4576b6252544f553c3651312b024e7ea
Stats:     47 lines in 2 files changed: 14 ins; 24 del; 9 mod

8079267: [TEST_BUG] Test java/awt/Frame/MiscUndecorated/RepaintTest.java fails

Reviewed-by: serb

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

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


From serb at openjdk.java.net  Thu Nov 11 19:24:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 11 Nov 2021 19:24:40 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows
In-Reply-To: <X0s8JYNbZUBUTadloGIawVo1foBsKpEK3exh3AVzQFQ=.0562cc15-a19d-4c0c-8aa7-d358f1356316@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
 <gVSUXx-iZ3g_7ImZWlonOSJ975OA3JRvaGZqYs79XoU=.f2d7e04a-bf03-4cd6-88af-6609f5368633@github.com>
 <669N85kj3NJ9LBmLySry9gncEzHOLsxmyTSgSJ9iuKA=.84146bec-e572-43a4-a260-c771e709caea@github.com>
 <TNIzf3oTslrWSF2fiNjyFZSRy9FQlKe0B85EFYilqRk=.6a62544f-dd0f-4684-9971-b6d132029310@github.com>
 <_8d2ZM_CXYdT8T9sM-Fo3ukpGfeFwIL1Ja6NnxdtWfM=.b881c420-934a-4bc5-b5d1-020c6cf09710@github.com>
 <X0s8JYNbZUBUTadloGIawVo1foBsKpEK3exh3AVzQFQ=.0562cc15-a19d-4c0c-8aa7-d358f1356316@github.com>
Message-ID: <2c-WMR1gMWHiUal2JRMhKQnwj9n9ZiuxQnMkYcbOio8=.d265e491-69b8-4f5c-89ff-27151f48f2d2@github.com>

On Thu, 11 Nov 2021 15:58:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Hello,  in our central tests it was indeed a fastdbg OpenJDK.   On my local Windows 10 machine I could not reproduce it.
>> Our central tests run with -Djava.awt.headless=true , but I think the Win2019 server machine itself is not headless .
>
> I could add a  J2dTraceLn(J2D_TRACE_ERROR, . . . )  in case an exception occurs.  The J2dTraceLn  is already used at some other places in  DWMIsCompositionEnabled so it might fit better than just ignoring the exception.

Before ignoring an exception it is better to check why the warning was raised, if that warning is correct then we should try to propogate/report exception to the app, if it is not possible then we should use trace macro.

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

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


From prr at openjdk.java.net  Fri Nov 12 03:59:35 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 12 Nov 2021 03:59:35 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
Message-ID: <KkEKIvVot0bKHgdVKYpHwgKAJmHcTXyFMSKNLyOHD-I=.8a8bd921-ed44-4665-a1cd-abba22003a95@github.com>

On Thu, 11 Nov 2021 15:32:01 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
>> 
>> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
>> 
>> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Macro for version

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

> 848:       COMMAND := $(METAL) -c -std=osx-metal2.0 \
> 849:           -mmacosx-version-min=$(MACOSX_VERSION_MIN) \
> 850:           -o $(SHADERS_AIR) $(SHADERS_SRC), \

No .. we decided metal requires macos 10.14 as a minimum. In fact it won't run (by policy) on earlier releases so settting it to what the broader JDK defines as a minimum is not appropriate right now.
And I've no idea what restrictions we'd be placing on metal saying it can only use 10.12 features.
Nor do I know what the xcode 12.4 used to build JDK 17 defaults to and how much a change to either 10.12 or 10.14 might require in re-testing.

So - 
we should use 10.14 
what's the actual impact of that on a current build using xcode 12.4 - does it change anything we use ?

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

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


From prr at openjdk.java.net  Fri Nov 12 04:02:36 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 12 Nov 2021 04:02:36 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <KkEKIvVot0bKHgdVKYpHwgKAJmHcTXyFMSKNLyOHD-I=.8a8bd921-ed44-4665-a1cd-abba22003a95@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
 <KkEKIvVot0bKHgdVKYpHwgKAJmHcTXyFMSKNLyOHD-I=.8a8bd921-ed44-4665-a1cd-abba22003a95@github.com>
Message-ID: <gp1WP0PFrO2cQaWVhdTAm_8mq1UaVq47FO2iMsIIxks=.440b48a9-9a09-47df-8318-ca2f69c28c65@github.com>

On Fri, 12 Nov 2021 03:56:57 GMT, Phil Race <prr at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Macro for version
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 850:
> 
>> 848:       COMMAND := $(METAL) -c -std=osx-metal2.0 \
>> 849:           -mmacosx-version-min=$(MACOSX_VERSION_MIN) \
>> 850:           -o $(SHADERS_AIR) $(SHADERS_SRC), \
> 
> No .. we decided metal requires macos 10.14 as a minimum. In fact it won't run (by policy) on earlier releases so settting it to what the broader JDK defines as a minimum is not appropriate right now.
> And I've no idea what restrictions we'd be placing on metal saying it can only use 10.12 features.
> Nor do I know what the xcode 12.4 used to build JDK 17 defaults to and how much a change to either 10.12 or 10.14 might require in re-testing.
> 
> So - 
> we should use 10.14 
> what's the actual impact of that on a current build using xcode 12.4 - does it change anything we use ?

bear in mind "impact" might mean metal can't use some new faster code, not just runtime errors

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

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


From duke at openjdk.java.net  Fri Nov 12 05:47:12 2021
From: duke at openjdk.java.net (Jeremy)
Date: Fri, 12 Nov 2021 05:47:12 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v7]
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <cgAWhv1J6wQIciHNQKgwHmTFucfbTGWHrmuijw15wg4=.5153f11f-86f1-4e3d-bf79-286f64801ce8@github.com>

> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
> 
> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
> B. Updating the unit test to forgive the discrepancy.
> 
> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
> 
> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
> 
> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

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

 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
   
   This adds a new unit test that calculates a high-precision bounding box (using BigDecimals), and then makes sure our double-based logic contains that high-precision bounds.
   
   This restores getBounds2D() to its original contract: it should only ever be *larger* than the actual bounds -- it should never be smaller.
   
   Also we want to only apply this margin (aka "padding") when we deal with polynomial-based extrema. We should never apply it to line-based polygons. For ex: a Path2D that represents an int-based rectangle should return the same bounds as before 8176501 was addressed.
   
   This test currently only addresses very small cubic curves.
   
   I experimented with very large cubic & quadratic curves, but I didn't come up with a unit test that failed before and after this commit. Adding unit tests for large curve segments is a possible area of improvement.
 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
   
   Addressing code review comments: given current code structure we don't need separate data structures for x and y equations.
 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
   
   Removing accidental leftover code. This should have been removed in a recent previous commit. The preceding code already defines these values.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6227/files
  - new: https://git.openjdk.java.net/jdk/pull/6227/files/4b9d87d6..40bda064

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

  Stats: 453 lines in 2 files changed: 112 ins; 257 del; 84 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6227.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6227/head:pull/6227

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


From duke at openjdk.java.net  Fri Nov 12 05:50:33 2021
From: duke at openjdk.java.net (Jeremy)
Date: Fri, 12 Nov 2021 05:50:33 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <UsAaWyanTR2eT5iOWWyMz9txyrMKXoyOxtSWmMgRhZs=.580a6b36-7353-4dbe-b975-a7206bb96a92@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
 <CeEMRyzppq2-yaby7fFDWT3ekeWJfRfD3Sp-dhY3scA=.723fad96-6c84-4583-a691-57152e3ec3dc@github.com>
 <7FgkHca8tdzn8chwJ6RsYWyuFVmtAQOl3xN17BiFhrg=.924d80dc-3171-45b4-a601-448bf3194aca@github.com>
 <2qVmqXHwGTEu7-fREZKtL8CBTnkgTf2pDpA1rFo5CVI=.7868c3ec-d91c-4d31-9751-28750be11968@github.com>
 <xIRXpvayrwFFU_Wo5XoLtHeKb5HUqNxxLcW3dE1h9Cc=.a7b379fa-b418-48b0-8714-b8182f81f950@github.com>
 <NZ7cYRk4MLJzGcGsu3ZGQOGU8KfCI-W9QheoW-55JC4=.7262f6dd-207b-4b75-bd49-58b7305277f6@github.com>
 <Q4-YZst7t1biWjzhw5lvCaAbe9aZ_lklJ-PpiSKKayw=.85696551-6ef8-4e93-a3fc-29590b46de84@github.com>
 <h89bp5udPKNgAOSvGSQg8LnBv9nU9Nm7inhQ1VTcQr8=.d0e7dbcc-d898-495d-81f5-c79fc823ac8d@github.com>
 <dxSJxjm6ertf9togbKd7XwErlS5O_UR59kgzdjreoas=.20349b5b-674a-4273-9449-997db15fd40e@github.com>
 <UsAaWyanTR2eT5iOWWyMz9txyrMKXoyOxtS
 WmMgRhZs=.580a6b36-7353-4dbe-b975-a7206bb96a92@github.com>
Message-ID: <CfYjw2-_iTT-a3QJiBXX71AjQp0Eh3yfMq6lDmfyd6g=.f067bb5e-50fd-4b7d-b540-3c62263efb98@github.com>

On Thu, 11 Nov 2021 10:26:30 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> You made an amazing job !
>> Your bigdecimal impl looks good.
>> I will play with your test experiment... asap.
>> I think numerical accuracies are related to the dynamic /magnitude of values: points.
>> The test should evaluate(max error) depending on the quick length(curve) ~ manhattan norm(curve arms), so small curves have less numerical error whereas huge curve (10^50 length) means points are wide spread and coeffs... solver...points are less accurate.
>> 
>> I will try making sampled control points vary in log scale: 10^-6 to 10^38 (float max) so curve length will vary in huge range and determine the histogram of max(error) / length ratio.
>
> see condition number = magnitude range on such plot:
> https://github.com/JuliaMath/AccurateArithmetic.jl/blob/master/test/figs/sum_accuracy.svg

I just pushed a commit ( 40bda06 ) that addresses the machine error problem to my satisfaction. It includes a unit test that failed before that commit and now passes.

At your convenience let me know your thoughts. (That commit continues to focus on very small doubles; it may (?) need help to address very large double errors.)

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

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


From mbaesken at openjdk.java.net  Fri Nov 12 07:57:57 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 12 Nov 2021 07:57:57 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows [v2]
In-Reply-To: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
Message-ID: <rk3QGVEVrD9pHr6p5mwpP4Gxn2Sxd7WXUD0_SwEiSkQ=.545b4b8f-3eb2-49a2-9233-0ce9a90161bc@github.com>

> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni to an awt related test, and shows on Windows server 2019 the following JNI warning , so the test  JNICheck/FreeTypeScalerJNICheck.java fails on this Windows version.
> 
> :stdErr:
> Thu Oct 28 01:27:10 CEST 2021
> stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV
>                at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 18.0.0.1-internal/Native Method)
>                at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:95)
>                at sun.awt.Win32GraphicsEnvironment.<clinit>(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:63)
>                at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 18.0.0.1-internal/PlatformGraphicsInfo.java:34)
>                at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:93)
>                at java.awt.GraphicsEnvironment$LocalGE.<clinit>(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:84)
>                at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:106)
>                at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53)
>                at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)
> 
> We can get rid of the warning by adjusting a JNU_CallStaticMethodByName call in awt_Win32GraphicsEnv.cpp .

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

  Add a J2dTraceLn call

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6306/files
  - new: https://git.openjdk.java.net/jdk/pull/6306/files/5d18a76c..ab1101b3

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

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

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


From mbaesken at openjdk.java.net  Fri Nov 12 08:02:37 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 12 Nov 2021 08:02:37 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows [v2]
In-Reply-To: <2c-WMR1gMWHiUal2JRMhKQnwj9n9ZiuxQnMkYcbOio8=.d265e491-69b8-4f5c-89ff-27151f48f2d2@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
 <gVSUXx-iZ3g_7ImZWlonOSJ975OA3JRvaGZqYs79XoU=.f2d7e04a-bf03-4cd6-88af-6609f5368633@github.com>
 <669N85kj3NJ9LBmLySry9gncEzHOLsxmyTSgSJ9iuKA=.84146bec-e572-43a4-a260-c771e709caea@github.com>
 <TNIzf3oTslrWSF2fiNjyFZSRy9FQlKe0B85EFYilqRk=.6a62544f-dd0f-4684-9971-b6d132029310@github.com>
 <_8d2ZM_CXYdT8T9sM-Fo3ukpGfeFwIL1Ja6NnxdtWfM=.b881c420-934a-4bc5-b5d1-020c6cf09710@github.com>
 <X0s8JYNbZUBUTadloGIawVo1foBsKpEK3exh3AVzQFQ=.0562cc15-a19d-4c0c-8aa7-d358f1356316@github.com>
 <2c-WMR1gMWHiUal2JRMhKQnwj9n9ZiuxQnMkYcbOio8=.d265e491-69b8-4f5c-89ff-27151f48f2d2@github.com>
Message-ID: <XxMCSPzvbmfQMLQMiXKiGIGUipJzaEQH4-tOBarByn4=.d667c185-a42b-4152-840d-70e09ffc4b64@github.com>

On Thu, 11 Nov 2021 19:21:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I could add a  J2dTraceLn(J2D_TRACE_ERROR, . . . )  in case an exception occurs.  The J2dTraceLn  is already used at some other places in  DWMIsCompositionEnabled so it might fit better than just ignoring the exception.
>
> Before ignoring an exception it is better to check why the warning was raised, if that warning is correct then we should try to propogate/report exception to the app, if it is not possible then we should use trace macro.

Hello, I added a trace call.  This is similar to what is done in https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/java2d/d3d/D3DRenderQueue.cpp#L869   .

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

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


From myano at openjdk.java.net  Fri Nov 12 09:12:07 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 12 Nov 2021 09:12:07 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v3]
In-Reply-To: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
Message-ID: <gwA_8ObJLdJifNeXZH96uV_wHvY8TkSJyeqo91tgkhE=.9b578d70-9a44-48ef-a0fc-f10a47ca6418@github.com>

> Could you please review the 8262297 bug fixes?
> 
> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.

Masanori Yano has updated the pull request incrementally with two additional commits since the last revision:

 - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
 - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6151/files
  - new: https://git.openjdk.java.net/jdk/pull/6151/files/08b54fff..0c7bb8d5

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

  Stats: 34 lines in 2 files changed: 3 ins; 5 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6151/head:pull/6151

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


From myano at openjdk.java.net  Fri Nov 12 09:12:10 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 12 Nov 2021 09:12:10 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v2]
In-Reply-To: <lF81OlMpNiQGv1Xa3KbRbZ78ge_0XTCXiFRWjf4iygE=.4bca2e40-255f-4a8d-b6b5-8d1f23d0fd87@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <lF81OlMpNiQGv1Xa3KbRbZ78ge_0XTCXiFRWjf4iygE=.4bca2e40-255f-4a8d-b6b5-8d1f23d0fd87@github.com>
Message-ID: <lKQpmGmfzPG-6fkwj6VEJkBiYHIY9u90UYf3r5t6OUY=.82214cdc-392f-4f5d-8892-2215a0ff9963@github.com>

On Fri, 29 Oct 2021 09:36:37 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8262297 bug fixes?
>> 
>> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8262297: ImageIO.write() method will throw IndexOutOfBoundsException

This problem occurs because the input png image depth is 2 bits per pixel.

Because the png to read is the correct image at 2 bits per pixel, the BufferedImage is generated correctly and no exception is thrown. However, bmp can only create images with a depth of 0, 1, 4, 8, 16, 24, or 32 bits per pixel.
https://docs.microsoft.com/en-us/previous-versions/dd183376(v=vs.85)

Because the BMPImageWriter determines bitsPerPixel in the range of the color palette without checking the depth, images with depths other than 0, 1, 4, 8, 16, 24, 32 are set to the wrong bitsPerPixel and destScanlineBytes. Therefore, an incorrect length reference to the size of the Raster DataBuffer causes IIOBE to be thrown.

So the fix should change the canEncodeImage method to check the color depth and throw an IOException if it is not 0, 1, 4, 8, 16, 24, or 32.

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

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


From martin.pernollet at protonmail.com  Fri Nov 12 12:19:10 2021
From: martin.pernollet at protonmail.com (Martin Pernollet)
Date: Fri, 12 Nov 2021 12:19:10 +0000
Subject: Addding OpenGL support to Java 17 with JEP-412
Message-ID: <RSOczynvRMdXidFz178cAxfdZybVUzt28sCUcBaDEk5UU_VyN180RANR69TcooJYnXmK68IR1uWR3kVSejLoJ9S-l5pvt09Gm3wWuIuRZr4=@protonmail.com>

Hi everyone,

I created and maintained Jzy3D framework allowing to create simple 3D and 2D charts in Java. It is currently using JOGL to access OpenGL and render in AWT, Swing, SWT, etc. JOGL is about to die unfortunatelly so I am studying if and how JEP-412 could be an alternative. I am somehow not in a hurry since I added a CPU fallback OpenGL renderer [1] that does a great job for simple surface/scatter/etc charts. Access to native OpenGL however remains important for fast rendering of large geometries as well as support for modern OpenGL using VBO, shaders, etc.

JEP-412 is promising, I got great examples already working on my mac [2] and I started evaluating this on Windows.

However, before diving in the huge project of building a JOGL-like library, I would like to understand what happened in the history of Sun Microsystem with OpenGL if some of you know it : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way.

[1] https://github.com/jzy3d/jzy3d-api/tree/master/jzy3d-emul-gl-awt
[2] https://github.com/jzy3d/panama-gl

From ihse at openjdk.java.net  Fri Nov 12 14:19:34 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 12 Nov 2021 14:19:34 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
Message-ID: <sEWoms1_xQF0PBfFvhqf1CtTvLVaTameXn-QyI0GQjA=.ea33073e-c526-44c9-8538-4e5f147c07ea@github.com>

On Thu, 11 Nov 2021 15:32:01 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
>> 
>> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
>> 
>> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Macro for version

I'm withdrawing my approval until the issues raised by Phil has been resolved.

It sounds like this change need more thorough discussion about what problems you are experience, and what are acceptable solutions to it.

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

Changes requested by ihse (Reviewer).

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


From erikj at openjdk.java.net  Fri Nov 12 14:52:39 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 12 Nov 2021 14:52:39 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
Message-ID: <J0EiobrbT4mlDkMdk2xq_bng_Cojs-wdvVqJEsuQeK8=.aa0add82-6c00-48b2-a4cd-6b9b4adc966d@github.com>

On Thu, 11 Nov 2021 15:32:01 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
>> 
>> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
>> 
>> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Macro for version

The JDK default of 10.12 is an old and rather conservative choice. I basically picked it as that was the oldest I could get away with at the time. This value is meant to be bumped whenever a need for it arises. Given that the oldest Macos version still getting Apple support is 10.15, I see no issue with raising this to at least 10.14, if that is what any part of the JDK requires. The whole point of defining that value is that it should reflect our requirements.

So I propose, bump the number in configure (and jib-profiles.js) and use it in the client makefiles so we fix the problem.

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

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


From ihse at openjdk.java.net  Fri Nov 12 14:58:42 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 12 Nov 2021 14:58:42 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
Message-ID: <RyfBy5SScXjKyaM8Zgn8IxCkMxyYv7FcmIct8Hns2rg=.f5b8ee34-fdc5-479d-94bf-14a585ffe5b4@github.com>

On Thu, 11 Nov 2021 15:32:01 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
>> 
>> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
>> 
>> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Macro for version

If we leave -mmacosx-version-min unspecified, will metal pick another value by default silently? And if so, might we be actually lowering the min version even if specifying 10.14?

In any case, it seems that any change here will need thorough testing both on Oracle CI systems and to make sure it solves @jayathirthrao's problem.

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

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


From erikj at openjdk.java.net  Fri Nov 12 17:21:36 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 12 Nov 2021 17:21:36 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <RyfBy5SScXjKyaM8Zgn8IxCkMxyYv7FcmIct8Hns2rg=.f5b8ee34-fdc5-479d-94bf-14a585ffe5b4@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
 <RyfBy5SScXjKyaM8Zgn8IxCkMxyYv7FcmIct8Hns2rg=.f5b8ee34-fdc5-479d-94bf-14a585ffe5b4@github.com>
Message-ID: <TpDz455kgYyowSwhVV9q3CGLSxcgWKk5SlZnjN_x-YI=.2a8fa38f-6d6f-460c-bb8e-81ae604f9590@github.com>

On Fri, 12 Nov 2021 14:55:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> If we leave -mmacosx-version-min unspecified, will metal pick another value by default silently? And if so, might we be actually lowering the min version even if specifying 10.14?

I'm not sure how Xcode picks the default target, but in my experience, it's some combination of the SDK bundled with Xcode and the current system the build is running on. I would assume this tool behaves the same way.

At Oracle we are currently using Xcode 12.4 and Macos 10.15.4, so specifying 10.14 would most likely be a step down from the assumed current default of 10.15. As far as Oracle is concerned, we should be fine with going with 10.15 as that's the oldest version that we will officially support for JDK 18 anyway. I have generally tried to be a bit more conservative with this version requirement though.

I agree that testing is required for such a change.

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

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


From prr at openjdk.java.net  Fri Nov 12 17:48:33 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 12 Nov 2021 17:48:33 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
Message-ID: <xwOtkNfkNk-AbOn12hz69oRQBpWHRt8gJDKwY4Bhu9U=.62725109-cb70-4eb6-90f7-3f4fc8815d49@github.com>

On Thu, 11 Nov 2021 15:32:01 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
>> 
>> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
>> 
>> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Macro for version

My understanding is that the flag here affects ONLY the metal compiler - for compiling metal shaders.
And if you don't specify -Dsun.java2d.metal=true (since metal is off by default) its a 100% no-op for the rest of the JDK.
And already, if you specify Dsun.java2d.metal=true and you are on 10.13 or lower, we do not honour the request so we haven't changed what platforms will work at all if we do it this way. So our effective deployment target for metal is already 10.14

And I also would not be surprised if someone wants to backport this to 17u, in which case a config change would have the effect of making 17u no longer run on macos 12 .. which I guess will happen sometime during the life of the LTS but right now ??

So making it a metal-specific change is what I think we should do FOR NOW and we can have a follow-on fix that aligns both of these .. maybe that is a subsequent JDK 18 fix, or perhaps it should be an early JDK 19 fix ?

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

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


From erikj at openjdk.java.net  Fri Nov 12 18:21:37 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 12 Nov 2021 18:21:37 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <xwOtkNfkNk-AbOn12hz69oRQBpWHRt8gJDKwY4Bhu9U=.62725109-cb70-4eb6-90f7-3f4fc8815d49@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
 <xwOtkNfkNk-AbOn12hz69oRQBpWHRt8gJDKwY4Bhu9U=.62725109-cb70-4eb6-90f7-3f4fc8815d49@github.com>
Message-ID: <F187DUFnKgVxwAVMY1XvNubTmIPhNNtZdxVzlLRn5v4=.b93a4cf9-e719-44d6-a86f-8b626390e76f@github.com>

On Fri, 12 Nov 2021 17:45:09 GMT, Phil Race <prr at openjdk.org> wrote:

> My understanding is that the flag here affects ONLY the metal compiler - for compiling metal shaders. And if you don't specify -Dsun.java2d.metal=true (since metal is off by defau?lt) its a 100% no-op for the rest of the JDK. And already, if you specify Dsun.java2d.metal=true and you are on 10.13 or lower, we do not honour the request so we haven't changed what platforms will work at all if we do it this way. So our effective deployment target for metal is already 10.14

This explanation certainly makes a good case for giving this particular tool invocation special treatment. If we don't want to bump the general deployment target version, then this makes sense.

> And I also would not be surprised if someone wants to backport this to 17u, in which case a config change would have the effect of making 17u no longer run on macos 12 .. which I guess will happen sometime during the life of the LTS but right now ??

I would be fine with backporting a general deployment target version change to 10.14 to 17u LTS. Apple are very aggressive with dropping support for older OS versions. We don't really have any obligations to maintain compatibility with legacy versions of macos. We just haven't actively dropped compatibility (which is different from what any particular distributor officially supports) unless there has been some technical limitation before. But, as you have now explained, we already have a runtime guard for this optional feature, so we aren't actually forced to change the global deployment target.

> So making it a metal-specific change is what I think we should do FOR NOW and we can have a follow-on fix that aligns both of these .. maybe that is a subsequent JDK 18 fix, or perhaps it should be an early JDK 19 fix ?

I'm ok with a metal specific change here, targeting 10.14, but it needs a comment referencing the global value and explaining that there is a runtime guard around this. Also note that on aarch64 the global value is 11.00.00, and in that case we should use the global value.

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

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


From geekinthelead at gmail.com  Fri Nov 12 18:26:55 2021
From: geekinthelead at gmail.com (Kingsley O)
Date: Fri, 12 Nov 2021 18:26:55 +0000
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
Message-ID: <CAGQ2jNCTexi8kWmOLi3REZuvdDh5wku2zS9kjK_cYUat9FGbYA@mail.gmail.com>

Please remove me from your mailing list - thanks

On Thu, Nov 11, 2021 at 3:32 PM Jayathirth D V <jdv at openjdk.java.net> wrote:

> > When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests
> in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont
> set any deployment target when when we use xcrun to create .air file and
> this issue looks similar to
> https://developer.apple.com/forums/thread/105719. Also
> https://developer.apple.com/forums/thread/105719 states that even if they
> set app deployment target they need to explicitly set deployment in "xcrun
> metal".
> >
> > Made same change to use -mmacosx-version-min=10.12.00 in our make file.
> Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal
> pipeline.
> >
> > SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also
> Vitaly(Submitter) has confirmed that patch resolves the issue.
>
> Jayathirth D V has updated the pull request incrementally with one
> additional commit since the last revision:
>
>   Use Macro for version
>
> -------------
>
> Changes:
>   - all: https://git.openjdk.java.net/jdk/pull/6346/files
>   - new:
> https://git.openjdk.java.net/jdk/pull/6346/files/a9f521a5..7f999650
>
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6346&range=01
>  - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6346&range=00-01
>
>   Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
>   Patch: https://git.openjdk.java.net/jdk/pull/6346.diff
>   Fetch: git fetch https://git.openjdk.java.net/jdk
> pull/6346/head:pull/6346
>
> PR: https://git.openjdk.java.net/jdk/pull/6346
>


From lbourges at openjdk.java.net  Fri Nov 12 19:12:36 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 12 Nov 2021 19:12:36 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <CfYjw2-_iTT-a3QJiBXX71AjQp0Eh3yfMq6lDmfyd6g=.f067bb5e-50fd-4b7d-b540-3c62263efb98@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
 <CeEMRyzppq2-yaby7fFDWT3ekeWJfRfD3Sp-dhY3scA=.723fad96-6c84-4583-a691-57152e3ec3dc@github.com>
 <7FgkHca8tdzn8chwJ6RsYWyuFVmtAQOl3xN17BiFhrg=.924d80dc-3171-45b4-a601-448bf3194aca@github.com>
 <2qVmqXHwGTEu7-fREZKtL8CBTnkgTf2pDpA1rFo5CVI=.7868c3ec-d91c-4d31-9751-28750be11968@github.com>
 <xIRXpvayrwFFU_Wo5XoLtHeKb5HUqNxxLcW3dE1h9Cc=.a7b379fa-b418-48b0-8714-b8182f81f950@github.com>
 <NZ7cYRk4MLJzGcGsu3ZGQOGU8KfCI-W9QheoW-55JC4=.7262f6dd-207b-4b75-bd49-58b7305277f6@github.com>
 <Q4-YZst7t1biWjzhw5lvCaAbe9aZ_lklJ-PpiSKKayw=.85696551-6ef8-4e93-a3fc-29590b46de84@github.com>
 <h89bp5udPKNgAOSvGSQg8LnBv9nU9Nm7inhQ1VTcQr8=.d0e7dbcc-d898-495d-81f5-c79fc823ac8d@github.com>
 <dxSJxjm6ertf9togbKd7XwErlS5O_UR59kgzdjreoas=.20349b5b-674a-4273-9449-997db15fd40e@github.com>
 <UsAaWyanTR2eT5iOWWyMz9txyrMKXoyOxtS
 WmMgRhZs=.580a6b36-7353-4dbe-b975-a7206bb96a92@github.com>
 <CfYjw2-_iTT-a3QJiBXX71AjQp0Eh3yfMq6lDmfyd6g=.f067bb5e-50fd-4b7d-b540-3c62263efb98@github.com>
Message-ID: <kRO5AvedUrv_Em8j4dExoc7j1uE3D7W3Qjuu8LBgWKY=.0db48177-3c7d-4598-9cd4-1c12594c9559@github.com>

On Fri, 12 Nov 2021 05:47:56 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> see condition number = magnitude range on such plot:
>> https://github.com/JuliaMath/AccurateArithmetic.jl/blob/master/test/figs/sum_accuracy.svg
>
> I just pushed a commit ( 40bda06 ) that addresses the machine error problem to my satisfaction. It includes a unit test that failed before that commit and now passes.
> 
> At your convenience let me know your thoughts. (That commit continues to focus on very small doubles; it may (?) need help to address very large double errors.)

That looks interesting as the new margin looks like ulp(x - bbox), however it may be not enough as the position error depends on curve polynom coefficients (magnitude).

I derived your (yesterday) test to play with the margin and try small to huge curves. 
I found the condition number ~ sum (abs(coeffs)) so margin = math.ulp(cond). But sometimes the quad solver is giving t with few ulps error that cause high position shifts.

I will go on testing your last approach and share my experiments

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

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


From achung at openjdk.java.net  Fri Nov 12 19:54:47 2021
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 12 Nov 2021 19:54:47 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac OS X
 Aqua look and feel
Message-ID: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>

Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.

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

Commit messages:
 - 8190264: JScrollBar ignores its border when using macOS Mac OS X Aqua look and feel

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

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


From prr at openjdk.java.net  Fri Nov 12 20:30:41 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 12 Nov 2021 20:30:41 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
Message-ID: <T_ZxuCrUuJJS6xW2_KefSNGoQKEYh_QWZNWXDL_upAA=.13fe2fc4-1127-453f-91e7-96a2dcc64335@github.com>

On Thu, 11 Nov 2021 15:32:01 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
>> 
>> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
>> 
>> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Macro for version

" Also note that on aarch64 the global value is 11.00.00, and in that case we should use the global value."

I have no idea what happens if you specify 10.14 to the metal compiler on aarch64
Something else to check although probably the safest option is to make it 11.0 on that architecture

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

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


From serb at openjdk.java.net  Sun Nov 14 05:56:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 14 Nov 2021 05:56:37 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v3]
In-Reply-To: <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
Message-ID: <gaura9XkVcm4-XY_ZqzgDWjkqUbQr-x2X_4CEiJUrBY=.0447e073-9bd7-4544-8b7e-27378429e8a4@github.com>

On Fri, 29 Oct 2021 06:43:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review fix
>  - Fix

It is a good thing to stabilize the tests and provide additional logging/screenshots at the end, but isn't taking the screenshot out of the mouse is a workaround for the bug?

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

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


From serb at openjdk.java.net  Sun Nov 14 05:58:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 14 Nov 2021 05:58:38 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <QPyLlBXqr80h-_OjGxuv6tGNl8_-IZ8IHF-_8QWy894=.b18fd0a2-4497-4aae-87b1-1570531f2862@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <-hj0v7RZ0HPpP9GND5csZsZ1Vz7oxaufOAC0-ZygtwM=.6a5ae7a8-52d6-4e3e-a166-2fae2c23dbe0@github.com>
 <cTqTWZsK6uJI_Kw9nUymKQnYxxzWBRrk52qJAKpAc9I=.18f7dffd-3ebe-4bd0-bc2f-d61b55437036@github.com>
 <aZX6pJkrGOTYLlAHRl9WlEGtoahiInx4QzelDWpV2b0=.c9a736f9-5dd5-4382-8513-94a0233105dc@github.com>
 <QPyLlBXqr80h-_OjGxuv6tGNl8_-IZ8IHF-_8QWy894=.b18fd0a2-4497-4aae-87b1-1570531f2862@github.com>
Message-ID: <2rBhm1b2wZwnJFYIve6hdNLHFE0iAkGbj1GkDkSOUCs=.726e6e6a-76b6-4657-b44b-dd854769055c@github.com>

On Thu, 11 Nov 2021 08:47:26 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Probably I should clarify my question, you added a parameter to the validate method and pass the "true" so the "validate" method will post a paint event, but just a few lines below there is a comment that the next code line "sd.getPeer().replaceSurfaceDataLater();" also will post an event. Is the comment outdated, or we will post two of them?
>
> @mrserb How long will it take to review this fix?

I suggest leaving it as is for some time, since it is known that could workaround another bug, linked below.

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

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


From serb at openjdk.java.net  Sun Nov 14 06:06:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 14 Nov 2021 06:06:36 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel
In-Reply-To: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
Message-ID: <I6rsVdsUDJC5WppKeRRyIbkH-WFXQvlaNgDWcSg1CEk=.7fb8eea0-4291-4a39-b65d-f1f260a3aa66@github.com>

On Fri, 12 Nov 2021 19:48:36 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.

Can we add a test case for this change? I think it should be possible to render the JScrollBar to the bufferedimage and then check where the colored border is rendered?

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

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


From serb at openjdk.java.net  Sun Nov 14 06:11:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 14 Nov 2021 06:11:37 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows [v2]
In-Reply-To: <XxMCSPzvbmfQMLQMiXKiGIGUipJzaEQH4-tOBarByn4=.d667c185-a42b-4152-840d-70e09ffc4b64@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
 <gVSUXx-iZ3g_7ImZWlonOSJ975OA3JRvaGZqYs79XoU=.f2d7e04a-bf03-4cd6-88af-6609f5368633@github.com>
 <669N85kj3NJ9LBmLySry9gncEzHOLsxmyTSgSJ9iuKA=.84146bec-e572-43a4-a260-c771e709caea@github.com>
 <TNIzf3oTslrWSF2fiNjyFZSRy9FQlKe0B85EFYilqRk=.6a62544f-dd0f-4684-9971-b6d132029310@github.com>
 <_8d2ZM_CXYdT8T9sM-Fo3ukpGfeFwIL1Ja6NnxdtWfM=.b881c420-934a-4bc5-b5d1-020c6cf09710@github.com>
 <X0s8JYNbZUBUTadloGIawVo1foBsKpEK3exh3AVzQFQ=.0562cc15-a19d-4c0c-8aa7-d358f1356316@github.com>
 <2c-WMR1gMWHiUal2JRMhKQnwj9n9ZiuxQnMkYcbOio8=.d265e491-69b8-4f5c-89ff-27151f48f2d2@github.com>
 <XxMCSPzvbmfQMLQMiXKiGIGUipJzaEQH4-tOBarByn4=.d667c185-a42b-4152-840d-70e09ffc4b64@github.com>
Message-ID: <pusUVkCBoDybTBOdO4tThHdECV9IUe-YtcLYn820uUo=.a6e70d45-1234-41d9-bd1a-f3c5d69d835c@github.com>

On Fri, 12 Nov 2021 07:59:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Before ignoring an exception it is better to check why the warning was raised, if that warning is correct then we should try to propogate/report exception to the app, if it is not possible then we should use trace macro.
>
> Hello, I added a trace call.  This is similar to what is done in https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/java2d/d3d/D3DRenderQueue.cpp#L869   .

In the old fix the trace was added there because that method is executed in the infinite loop on some special thread, so an exception could not be thrown to the user, is it the case in the current issue?

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

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


From prr at openjdk.java.net  Mon Nov 15 02:54:35 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 15 Nov 2021 02:54:35 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows [v2]
In-Reply-To: <rk3QGVEVrD9pHr6p5mwpP4Gxn2Sxd7WXUD0_SwEiSkQ=.545b4b8f-3eb2-49a2-9233-0ce9a90161bc@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
 <rk3QGVEVrD9pHr6p5mwpP4Gxn2Sxd7WXUD0_SwEiSkQ=.545b4b8f-3eb2-49a2-9233-0ce9a90161bc@github.com>
Message-ID: <TLZCU19EefUZsbV-wsMzt1maLALv9kxTQEovRyKD0EE=.d53f9b96-8c6f-4abb-a2aa-6ac1592625db@github.com>

On Fri, 12 Nov 2021 07:57:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni to an awt related test, and shows on Windows server 2019 the following JNI warning , so the test  JNICheck/FreeTypeScalerJNICheck.java fails on this Windows version.
>> 
>> :stdErr:
>> Thu Oct 28 01:27:10 CEST 2021
>> stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV
>>                at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 18.0.0.1-internal/Native Method)
>>                at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:95)
>>                at sun.awt.Win32GraphicsEnvironment.<clinit>(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:63)
>>                at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 18.0.0.1-internal/PlatformGraphicsInfo.java:34)
>>                at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:93)
>>                at java.awt.GraphicsEnvironment$LocalGE.<clinit>(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:84)
>>                at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:106)
>>                at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53)
>>                at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)
>> 
>> We can get rid of the warning by adjusting a JNU_CallStaticMethodByName call in awt_Win32GraphicsEnv.cpp .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a J2dTraceLn call

We have issues running in debug mode even in headful mode - https://bugs.openjdk.java.net/browse/JDK-8264773
I think this PR should be withdrawn. We need a holistic look at making sure we run properly in debug builds on windows when we get time.
In other words don't try to fix up individual tests, especially by suppressing the error.

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

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


From psadhukhan at openjdk.java.net  Mon Nov 15 04:49:35 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 15 Nov 2021 04:49:35 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v3]
In-Reply-To: <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
Message-ID: <JjI52cH4zJP1w0uY9fI7D1_RJxF6VMNL2AKBxE1f5mM=.3107e77e-c86c-4045-8888-aa95b0e2403b@github.com>

On Fri, 29 Oct 2021 06:43:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review fix
>  - Fix

It probably is but will not affect the regression testing of these tests for its specific JBS issues it was written for. Also, the CI system will have to be kept offline till a product fix is found and tested so I think it is prudent to apply this patch to make this CI system usable again...

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

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


From jdv at openjdk.java.net  Mon Nov 15 05:36:34 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 15 Nov 2021 05:36:34 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <gp1WP0PFrO2cQaWVhdTAm_8mq1UaVq47FO2iMsIIxks=.440b48a9-9a09-47df-8318-ca2f69c28c65@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
 <KkEKIvVot0bKHgdVKYpHwgKAJmHcTXyFMSKNLyOHD-I=.8a8bd921-ed44-4665-a1cd-abba22003a95@github.com>
 <gp1WP0PFrO2cQaWVhdTAm_8mq1UaVq47FO2iMsIIxks=.440b48a9-9a09-47df-8318-ca2f69c28c65@github.com>
Message-ID: <5EbmAyaNA_izgnu9JjvBpNlWeyyeqg7RFdzuM1YzhI4=.854b5a74-8d13-4be9-911b-3aa43bc7495f@github.com>

On Fri, 12 Nov 2021 03:59:52 GMT, Phil Race <prr at openjdk.org> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 850:
>> 
>>> 848:       COMMAND := $(METAL) -c -std=osx-metal2.0 \
>>> 849:           -mmacosx-version-min=$(MACOSX_VERSION_MIN) \
>>> 850:           -o $(SHADERS_AIR) $(SHADERS_SRC), \
>> 
>> No .. we decided metal requires macos 10.14 as a minimum. In fact it won't run (by policy) on earlier releases so settting it to what the broader JDK defines as a minimum is not appropriate right now.
>> And I've no idea what restrictions we'd be placing on metal saying it can only use 10.12 features.
>> Nor do I know what the xcode 12.4 used to build JDK 17 defaults to and how much a change to either 10.12 or 10.14 might require in re-testing.
>> 
>> So - 
>> we should use 10.14 
>> what's the actual impact of that on a current build using xcode 12.4 - does it change anything we use ?
>
> bear in mind "impact" might mean metal can't use some new faster code, not just runtime errors

Hi Phil,

Thanks for the review. I also had doubts using 10.12. And yes as you mentioned we dont use Metal pipeline for versions < macOS10.14.

We dont use any Metal API which is specific to >macOS10.14(We had such usage when Lanai was under development but they were removed subsequently). So i dont see any performance impact of making xcrun to use 10.14 as minimum version.

Thanks,
Jay

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

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


From jdv at openjdk.java.net  Mon Nov 15 05:49:32 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 15 Nov 2021 05:49:32 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <T_ZxuCrUuJJS6xW2_KefSNGoQKEYh_QWZNWXDL_upAA=.13fe2fc4-1127-453f-91e7-96a2dcc64335@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
 <T_ZxuCrUuJJS6xW2_KefSNGoQKEYh_QWZNWXDL_upAA=.13fe2fc4-1127-453f-91e7-96a2dcc64335@github.com>
Message-ID: <SuFVm5EBPqtZk9toGDxzXeqqq645bmJRyI7BjYRKNnU=.c0cb13f4-7681-4425-888f-9e73ef995f8c@github.com>

On Fri, 12 Nov 2021 20:27:32 GMT, Phil Race <prr at openjdk.org> wrote:

> " Also note that on aarch64 the global value is 11.00.00, and in that case we should use the global value."
> 
> I have no idea what happens if you specify 10.14 to the metal compiler on aarch64 Something else to check although probably the safest option is to make it 11.0 on that architecture

Sure. I will make it to use 11.0 on aarch64 and 10.14 on x64 and add comment mentioning that we have runtime guard to ignore metal pipeline for <10.14 versions. With current 10.12 minimum version patch there is CI run on aarch64 it has not thrown any error but i am not sure how that works.

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

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


From lbourges at openjdk.java.net  Mon Nov 15 06:56:40 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 15 Nov 2021 06:56:40 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v2]
In-Reply-To: <kRO5AvedUrv_Em8j4dExoc7j1uE3D7W3Qjuu8LBgWKY=.0db48177-3c7d-4598-9cd4-1c12594c9559@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <Xn2s4pm1AvcePpZ-rPN95aSJ03lVxQ2lzGO9C6vBR98=.a4079fcd-9881-4c08-9a0b-696a8ff181f0@github.com>
 <CeEMRyzppq2-yaby7fFDWT3ekeWJfRfD3Sp-dhY3scA=.723fad96-6c84-4583-a691-57152e3ec3dc@github.com>
 <7FgkHca8tdzn8chwJ6RsYWyuFVmtAQOl3xN17BiFhrg=.924d80dc-3171-45b4-a601-448bf3194aca@github.com>
 <2qVmqXHwGTEu7-fREZKtL8CBTnkgTf2pDpA1rFo5CVI=.7868c3ec-d91c-4d31-9751-28750be11968@github.com>
 <xIRXpvayrwFFU_Wo5XoLtHeKb5HUqNxxLcW3dE1h9Cc=.a7b379fa-b418-48b0-8714-b8182f81f950@github.com>
 <NZ7cYRk4MLJzGcGsu3ZGQOGU8KfCI-W9QheoW-55JC4=.7262f6dd-207b-4b75-bd49-58b7305277f6@github.com>
 <Q4-YZst7t1biWjzhw5lvCaAbe9aZ_lklJ-PpiSKKayw=.85696551-6ef8-4e93-a3fc-29590b46de84@github.com>
 <h89bp5udPKNgAOSvGSQg8LnBv9nU9Nm7inhQ1VTcQr8=.d0e7dbcc-d898-495d-81f5-c79fc823ac8d@github.com>
 <dxSJxjm6ertf9togbKd7XwErlS5O_UR59kgzdjreoas=.20349b5b-674a-4273-9449-997db15fd40e@github.com>
 <UsAaWyanTR2eT5iOWWyMz9txyrMKXoyOxtS
 WmMgRhZs=.580a6b36-7353-4dbe-b975-a7206bb96a92@github.com>
 <CfYjw2-_iTT-a3QJiBXX71AjQp0Eh3yfMq6lDmfyd6g=.f067bb5e-50fd-4b7d-b540-3c62263efb98@github.com>
 <kRO5AvedUrv_Em8j4dExoc7j1uE3D7W3Qjuu8LBgWKY=.0db48177-3c7d-4598-9cd4-1c12594c9559@github.com>
Message-ID: <kyoAsIX4XKHjlmrKl3nNR_6-k7mUPfeMDGcRav57tic=.01b556fc-2e5e-48f4-a86e-f025ee2811dd@github.com>

On Fri, 12 Nov 2021 19:09:18 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> I just pushed a commit ( 40bda06 ) that addresses the machine error problem to my satisfaction. It includes a unit test that failed before that commit and now passes.
>> 
>> At your convenience let me know your thoughts. (That commit continues to focus on very small doubles; it may (?) need help to address very large double errors.)
>
> That looks interesting as the new margin looks like ulp(x - bbox), however it may be not enough as the position error depends on curve polynom coefficients (magnitude).
> 
> I derived your (yesterday) test to play with the margin and try small to huge curves. 
> I found the condition number ~ sum (abs(coeffs)) so margin = math.ulp(cond). But sometimes the quad solver is giving t with few ulps error that cause high position shifts.
> 
> I will go on testing your last approach and share my experiments

As this accuracy problem is a more general issue on quad / cubic curves, I created the Marlin-Math project to ascertain the math function accuracy.
See https://github.com/bourgesl/marlin-math/blob/main/src/main/java/test/FindExtremaAccuracyTest.java

I will propose a new upper margin value that quarantees the edge condition.

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

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


From jdv at openjdk.java.net  Mon Nov 15 07:20:37 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 15 Nov 2021 07:20:37 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <SuFVm5EBPqtZk9toGDxzXeqqq645bmJRyI7BjYRKNnU=.c0cb13f4-7681-4425-888f-9e73ef995f8c@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
 <T_ZxuCrUuJJS6xW2_KefSNGoQKEYh_QWZNWXDL_upAA=.13fe2fc4-1127-453f-91e7-96a2dcc64335@github.com>
 <SuFVm5EBPqtZk9toGDxzXeqqq645bmJRyI7BjYRKNnU=.c0cb13f4-7681-4425-888f-9e73ef995f8c@github.com>
Message-ID: <JmekcO3EivsQcPEsy02OXob6PWxanyQuoMkUhgJcdSY=.070adef7-faf7-4fe8-85cb-ebb887fb196b@github.com>

On Mon, 15 Nov 2021 05:46:30 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> " Also note that on aarch64 the global value is 11.00.00, and in that case we should use the global value."
> 
> I have no idea what happens if you specify 10.14 to the metal compiler on aarch64 Something else to check although probably the safest option is to make it 11.0 on that architecture

A question popped up while doing this. My making 11.0 as minimum macosx version on aarch64, are we not restricting metal to be used only on >=11.0 on aarch 64?

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

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


From jdv at openjdk.java.net  Mon Nov 15 08:08:45 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 15 Nov 2021 08:08:45 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v3]
In-Reply-To: <gwA_8ObJLdJifNeXZH96uV_wHvY8TkSJyeqo91tgkhE=.9b578d70-9a44-48ef-a0fc-f10a47ca6418@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <gwA_8ObJLdJifNeXZH96uV_wHvY8TkSJyeqo91tgkhE=.9b578d70-9a44-48ef-a0fc-f10a47ca6418@github.com>
Message-ID: <ZTlmTugLnJJ1C4zpBPWm2IGSm5PVxkNXcMXlOSguvog=.0ee2d1e4-a91b-463c-9470-a32b90fce937@github.com>

On Fri, 12 Nov 2021 09:12:07 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8262297 bug fixes?
>> 
>> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.
>
> Masanori Yano has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException

src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java line 1459:

> 1457:         int biType = imgType.getBufferedImageType();
> 1458:         int bpp = imgType.getColorModel().getPixelSize();
> 1459:         if (bpp != 0 && bpp != 1 && bpp != 4 && bpp != 8 && bpp != 16 && bpp != 24 && bpp != 32) {

This change looks good to me.

test/jdk/javax/imageio/plugins/bmp/TruncatedPngTest.java line 27:

> 25:  * @test
> 26:  * @bug 8262297
> 27:  * @summary Checks that ImageIO.write(..., ..., File) truncates the file

I think with latest patch this summary should be updated to reflect what test is verifying.

test/jdk/javax/imageio/plugins/bmp/TruncatedPngTest.java line 41:

> 39: 
> 40:     public static void main(String[] args) {
> 41:         String fileName = "0.png";

A 2KB image will not take much space but it would be better if we can create 2bpp PNG image programmatically and use it in the test case.

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

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


From jdv at openjdk.java.net  Mon Nov 15 09:03:41 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 15 Nov 2021 09:03:41 GMT
Subject: RFR: 8233568: [TESTBUG] AWT event tests failing on MacOS
In-Reply-To: <wuww34-8VarDB4XRQ0sUI17MFpOyWa4DKOZSRckNcqo=.a72bed71-3776-4eab-8eca-e029bde09ed0@github.com>
References: <wuww34-8VarDB4XRQ0sUI17MFpOyWa4DKOZSRckNcqo=.a72bed71-3776-4eab-8eca-e029bde09ed0@github.com>
Message-ID: <Ud4lLmIPBt0MuFjNPpT6OMG8cjHpk8y3gGvgq9KWzu4=.ed8db425-3aae-4708-ad81-410ccf09178b@github.com>

On Thu, 21 Oct 2021 15:47:36 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Tests passing on macos, so removing from ProblemList

Are these tests verified to pass on CI or local machine?
If CI please add the link in JBS.

Also it looks all these tests are related to java/awt/event. It is possible that these tests will fail only when run as part of bigger set of tests. Would recommend to run java/awt/event jtreg tests multiple times in CI to be sure that it passes consistently.

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

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


From jdv at openjdk.java.net  Mon Nov 15 10:03:41 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 15 Nov 2021 10:03:41 GMT
Subject: RFR: 8270874: JFrame paint artifacts when dragged from standard
 monitor to HiDPI monitor
In-Reply-To: <hPV-NYDHAMhyOviuU89e9Frm1ALNGqn_Uw0i4NDscRE=.e3fcd015-0bc5-4e7a-92f0-8474ee8af548@github.com>
References: <hPV-NYDHAMhyOviuU89e9Frm1ALNGqn_Uw0i4NDscRE=.e3fcd015-0bc5-4e7a-92f0-8474ee8af548@github.com>
Message-ID: <8f93oLv4_N0vNlmfkvXQrju73GxBjyD1LW-d06poJus=.7dd8b1ef-2771-4709-b06f-1c5ef649d8de@github.com>

On Wed, 10 Nov 2021 18:45:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The bug occurs more often if initially the window is moved partly outside of the first screen(let's name this part as the invisible part), and then slowly moved to the second screen where that invisible part became visible on the second screen.
> 
> The problem is how we try to repaint the frame. The Windows send us coordinates to repaint in the device space, if the width/height values are less than a unit in the user's space, we round it to the empty rectangle and skip it.
> 
> Solution: request to repaint the smallest non-empty bounding box in the user's space around the region of pixels.
> 
> Workaround: repaint the whole window on the component resize/move event or at the end of the drag.
> 
> Notes:
>  * It is not reproducible(at least much less often) when d3d is enabled because the d3d pipeline sends repaint events more often (example https://github.com/openjdk/jdk/pull/6064). That hides the current issue.
>  * It started to be reproducible during the drag from one screen to another after JDK-8211999 because before JDK-8211999 we make a resize at the end of the drag, which caused the full repaint of the window.

Please correct my understanding. Does this refined repaint logic apply even for overlapping Windows? What happens when 2 windows are overlapping and we move top window slowly? Any performance/power impact?

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

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


From kcr at openjdk.java.net  Mon Nov 15 13:31:38 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 15 Nov 2021 13:31:38 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
Message-ID: <yo_nL0hE7EOPSrf4gM4Ov_KOTnPDvOFeiBEGVXjFsss=.3604d857-dc60-4dec-8bd2-f474546d7c3a@github.com>

On Thu, 11 Nov 2021 15:32:01 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
>> 
>> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
>> 
>> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Macro for version

The JDK itself has a minimum version of 11.0 on macOS aarch64 systems (because apple only supports it on macOS >= 11), so it probably doesn't matter much. You might wish to file a low-priority follow-up issue to change the runtime check to be consistent.

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

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


From erikj at openjdk.java.net  Mon Nov 15 13:36:35 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 15 Nov 2021 13:36:35 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <JmekcO3EivsQcPEsy02OXob6PWxanyQuoMkUhgJcdSY=.070adef7-faf7-4fe8-85cb-ebb887fb196b@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
 <T_ZxuCrUuJJS6xW2_KefSNGoQKEYh_QWZNWXDL_upAA=.13fe2fc4-1127-453f-91e7-96a2dcc64335@github.com>
 <SuFVm5EBPqtZk9toGDxzXeqqq645bmJRyI7BjYRKNnU=.c0cb13f4-7681-4425-888f-9e73ef995f8c@github.com>
 <JmekcO3EivsQcPEsy02OXob6PWxanyQuoMkUhgJcdSY=.070adef7-faf7-4fe8-85cb-ebb887fb196b@github.com>
Message-ID: <QfvCDsfl3lDeYF0iGlNjv1KpQyKghHfY01R8pvuK4jw=.21c83761-5cce-410b-9707-0107c1d9ac1d@github.com>

On Mon, 15 Nov 2021 07:17:45 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> A question popped up while doing this. By making 11.0 as minimum macosx version on aarch64, are we not restricting metal to be used only on >=11.0 on aarch 64?

Correct, but there are no older versions of Macos on aarch64, so this is what we want. I think the correct behavior here is to use $(MACOSX_VERSION_MIN) on aarch64 and only override this with an explicit 10.14 for x86_64 and explaining why that override is done in a comment.

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

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


From jdv at openjdk.java.net  Mon Nov 15 13:44:11 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 15 Nov 2021 13:44:11 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v3]
In-Reply-To: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
Message-ID: <fHhIdXlM313qHNzkrjC4l1z-lRmFZ7RBKsFR-WSiFeQ=.dd75c95b-4f2f-4af2-b1b9-a69493d4fa07@github.com>

> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
> 
> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
> 
> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Use 10.14 macOS version

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6346/files
  - new: https://git.openjdk.java.net/jdk/pull/6346/files/7f999650..49104160

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

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

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


From jdv at openjdk.java.net  Mon Nov 15 14:00:59 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 15 Nov 2021 14:00:59 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v4]
In-Reply-To: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
Message-ID: <B0yOGzikq8-GaQ5Eo7UER7zZI9x-eDGVpstsKMdIoDU=.33047c9a-7c09-4c01-bfa0-13dd0402392b@github.com>

> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
> 
> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
> 
> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Use MACOSX_VERSION_MIN for aarch64

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6346/files
  - new: https://git.openjdk.java.net/jdk/pull/6346/files/49104160..ecea143b

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

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

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


From erikj at openjdk.java.net  Mon Nov 15 14:01:01 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 15 Nov 2021 14:01:01 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v4]
In-Reply-To: <B0yOGzikq8-GaQ5Eo7UER7zZI9x-eDGVpstsKMdIoDU=.33047c9a-7c09-4c01-bfa0-13dd0402392b@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <B0yOGzikq8-GaQ5Eo7UER7zZI9x-eDGVpstsKMdIoDU=.33047c9a-7c09-4c01-bfa0-13dd0402392b@github.com>
Message-ID: <un2gR7foeFxZVExI9HufW_xXZ4pZDsDzbuXGjMhKcIg=.2985c689-dae0-44e2-a190-7ee552808342@github.com>

On Mon, 15 Nov 2021 13:57:25 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
>> 
>> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
>> 
>> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use MACOSX_VERSION_MIN for aarch64

Looks good!

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

Marked as reviewed by erikj (Reviewer).

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


From kcr at openjdk.java.net  Mon Nov 15 14:01:00 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 15 Nov 2021 14:01:00 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v4]
In-Reply-To: <B0yOGzikq8-GaQ5Eo7UER7zZI9x-eDGVpstsKMdIoDU=.33047c9a-7c09-4c01-bfa0-13dd0402392b@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <B0yOGzikq8-GaQ5Eo7UER7zZI9x-eDGVpstsKMdIoDU=.33047c9a-7c09-4c01-bfa0-13dd0402392b@github.com>
Message-ID: <5vw6AZ4nbyQtt9kHySnfxNqmPXG2Uvd8CM8lPdGgOK0=.5f25a4b1-99fb-40ef-b90e-0786b93be38b@github.com>

On Mon, 15 Nov 2021 13:57:25 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
>> 
>> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
>> 
>> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use MACOSX_VERSION_MIN for aarch64

Marked as reviewed by kcr (Author).

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

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


From jdv at openjdk.java.net  Mon Nov 15 14:01:01 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 15 Nov 2021 14:01:01 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v2]
In-Reply-To: <yo_nL0hE7EOPSrf4gM4Ov_KOTnPDvOFeiBEGVXjFsss=.3604d857-dc60-4dec-8bd2-f474546d7c3a@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <PYIWsYF98k2rNrUKGSifzqAhkWoDZrWwhyuQ3ZfBXBU=.3bbcf46f-9831-4d74-b294-d91a073187e7@github.com>
 <yo_nL0hE7EOPSrf4gM4Ov_KOTnPDvOFeiBEGVXjFsss=.3604d857-dc60-4dec-8bd2-f474546d7c3a@github.com>
Message-ID: <uirEQTfDeovMhRpKCasnnCiiOdkiFlZxmTLGdGkxRxA=.41708c4a-a5ce-4995-94fa-ae867607f58d@github.com>

On Mon, 15 Nov 2021 13:28:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> The JDK itself has a minimum version of 11.0 on macOS aarch64 systems (because apple only supports it on macOS >= 11), so it probably doesn't matter much. You might wish to file a low-priority follow-up issue to change the runtime check to be consistent.

Thanks Kevin for the clarification and for also clearing up the follow up question i wanted to ask about runtime check update.

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

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


From kcr at openjdk.java.net  Mon Nov 15 14:01:09 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 15 Nov 2021 14:01:09 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v3]
In-Reply-To: <fHhIdXlM313qHNzkrjC4l1z-lRmFZ7RBKsFR-WSiFeQ=.dd75c95b-4f2f-4af2-b1b9-a69493d4fa07@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <fHhIdXlM313qHNzkrjC4l1z-lRmFZ7RBKsFR-WSiFeQ=.dd75c95b-4f2f-4af2-b1b9-a69493d4fa07@github.com>
Message-ID: <8292Qt06yac4wltN03MhQPHqtuVvO7uRBUw98Jtq0Cw=.963fb049-0e03-4e19-bc74-7532b8abb146@github.com>

On Mon, 15 Nov 2021 13:44:11 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
>> 
>> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
>> 
>> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use 10.14 macOS version

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

> 842: # for aarch64 is 11.00.00 at the time of introducing MACOSX_METAL_VERSION_MIN.
> 843: ifeq ($(OPENJDK_TARGET_CPU_ARCH), xaarch64)
> 844:     MACOSX_METAL_VERSION_MIN=11.00.00

I like Erik's suggestion of using `MACOSX_VERSION_MIN` for `aarch64`, since it's one less place you need to duplicate a constant.

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

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


From jdv at openjdk.java.net  Mon Nov 15 14:01:13 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 15 Nov 2021 14:01:13 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v3]
In-Reply-To: <8292Qt06yac4wltN03MhQPHqtuVvO7uRBUw98Jtq0Cw=.963fb049-0e03-4e19-bc74-7532b8abb146@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <fHhIdXlM313qHNzkrjC4l1z-lRmFZ7RBKsFR-WSiFeQ=.dd75c95b-4f2f-4af2-b1b9-a69493d4fa07@github.com>
 <8292Qt06yac4wltN03MhQPHqtuVvO7uRBUw98Jtq0Cw=.963fb049-0e03-4e19-bc74-7532b8abb146@github.com>
Message-ID: <b0q9VEaJMN5tfk8aq7c_Am7qH-i83GzI2O607NEs9GM=.3e6a6b83-6a0e-4b90-9100-46ddea8e8a86@github.com>

On Mon, 15 Nov 2021 13:46:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use 10.14 macOS version
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 844:
> 
>> 842: # for aarch64 is 11.00.00 at the time of introducing MACOSX_METAL_VERSION_MIN.
>> 843: ifeq ($(OPENJDK_TARGET_CPU_ARCH), xaarch64)
>> 844:     MACOSX_METAL_VERSION_MIN=11.00.00
> 
> I like Erik's suggestion of using `MACOSX_VERSION_MIN` for `aarch64`, since it's one less place you need to duplicate a constant.

Hi Kevin,

I noticed the comment after pushing the change. I have updated it.

Thanks,
Jay

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

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


From ihse at openjdk.java.net  Mon Nov 15 14:38:37 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 15 Nov 2021 14:38:37 GMT
Subject: RFR: 8276905: Function frag_col has a deployment target which is
 incompatible with this OS [v4]
In-Reply-To: <B0yOGzikq8-GaQ5Eo7UER7zZI9x-eDGVpstsKMdIoDU=.33047c9a-7c09-4c01-bfa0-13dd0402392b@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <B0yOGzikq8-GaQ5Eo7UER7zZI9x-eDGVpstsKMdIoDU=.33047c9a-7c09-4c01-bfa0-13dd0402392b@github.com>
Message-ID: <wtId5shWvXpeQzfrm78opH_E51Tji0hpRFcbR0k_zPw=.c08327bf-f54a-4f56-bfa3-adf50ba30992@github.com>

On Mon, 15 Nov 2021 14:00:59 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
>> 
>> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
>> 
>> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use MACOSX_VERSION_MIN for aarch64

Looks good to me also. Please let Phil have a say as well before integrating.

Also please update the title of the PR and the JBS issue (they must be the same) to something about that we're changing metal min version, rather than the obscure error that was the result of not having the min version...

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

Marked as reviewed by ihse (Reviewer).

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


From jdv at openjdk.java.net  Mon Nov 15 14:46:42 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 15 Nov 2021 14:46:42 GMT
Subject: RFR: 8276905: Use appropriate macosx_version_minimum value while
 compiling metal shaders [v4]
In-Reply-To: <wtId5shWvXpeQzfrm78opH_E51Tji0hpRFcbR0k_zPw=.c08327bf-f54a-4f56-bfa3-adf50ba30992@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <B0yOGzikq8-GaQ5Eo7UER7zZI9x-eDGVpstsKMdIoDU=.33047c9a-7c09-4c01-bfa0-13dd0402392b@github.com>
 <wtId5shWvXpeQzfrm78opH_E51Tji0hpRFcbR0k_zPw=.c08327bf-f54a-4f56-bfa3-adf50ba30992@github.com>
Message-ID: <GA9Do27xHnUaHNK5J1sV7GWCzgzQacigiW1S-2Cbx5o=.5534da97-5213-429a-9458-ce43cb5f1604@github.com>

On Mon, 15 Nov 2021 14:33:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Looks good to me also. Please let Phil have a say as well before integrating.

Thanks Magnus for the review. Yes i have already Re-Requested review from Phil on latest patch.
Also i am waiting on Vitaly(JBS submitter) to verify the latest patch.

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

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


From achung at openjdk.java.net  Mon Nov 15 17:15:16 2021
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 15 Nov 2021 17:15:16 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v2]
In-Reply-To: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
Message-ID: <HqkeVlcwyZnx6eRffKYOr8gWKXv_UwUtbGv3TvaMW_k=.a5160576-5f05-43f1-9c18-96e49cf4c50d@github.com>

> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.

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

  added test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6374/files
  - new: https://git.openjdk.java.net/jdk/pull/6374/files/b48fdbe3..40157e04

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

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

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


From achung at openjdk.java.net  Mon Nov 15 17:33:09 2021
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 15 Nov 2021 17:33:09 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v3]
In-Reply-To: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
Message-ID: <QU3ZR8euhuq1lR4Y56LIKVkDzwxKm69ANvsNK9huCvg=.77568628-c221-4f79-b6c0-2a741a4fa130@github.com>

> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.

Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:

 - removed trailing whitespace
 - test change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6374/files
  - new: https://git.openjdk.java.net/jdk/pull/6374/files/40157e04..e6dab9b2

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

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

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


From prr at openjdk.java.net  Mon Nov 15 17:34:46 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 15 Nov 2021 17:34:46 GMT
Subject: RFR: 8276905: Use appropriate macosx_version_minimum value while
 compiling metal shaders [v4]
In-Reply-To: <B0yOGzikq8-GaQ5Eo7UER7zZI9x-eDGVpstsKMdIoDU=.33047c9a-7c09-4c01-bfa0-13dd0402392b@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
 <B0yOGzikq8-GaQ5Eo7UER7zZI9x-eDGVpstsKMdIoDU=.33047c9a-7c09-4c01-bfa0-13dd0402392b@github.com>
Message-ID: <FHvLaox3aoYZ7TpdQ24WO_N8sMYHJJ2d2TOcG29Uaxc=.eacb98e1-0600-4664-93af-6b82d0ca55d7@github.com>

On Mon, 15 Nov 2021 14:00:59 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
>> 
>> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
>> 
>> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use MACOSX_VERSION_MIN for aarch64

This should be the most compatible solution.

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

Marked as reviewed by prr (Reviewer).

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


From serb at openjdk.java.net  Mon Nov 15 19:06:35 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 15 Nov 2021 19:06:35 GMT
Subject: RFR: 8276794: Change nested classes in java.desktop to static
 nested classes
In-Reply-To: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
Message-ID: <I5HN2el5PXIfHuXN9QkVluBzNFGKLk3fFIsBDNSvinY=.5e36613d-f1a8-4cf0-b56e-b148b5bee623@github.com>

On Thu, 14 Oct 2021 07:47:33 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)

Marked as reviewed by serb (Reviewer).

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

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


From lbourges at openjdk.java.net  Mon Nov 15 20:54:40 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 15 Nov 2021 20:54:40 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v7]
In-Reply-To: <cgAWhv1J6wQIciHNQKgwHmTFucfbTGWHrmuijw15wg4=.5153f11f-86f1-4e3d-bf79-286f64801ce8@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <cgAWhv1J6wQIciHNQKgwHmTFucfbTGWHrmuijw15wg4=.5153f11f-86f1-4e3d-bf79-286f64801ce8@github.com>
Message-ID: <EYfOcl9reCwSGc_6Wiq3C15vPPM7qX-xQcrlWY7qBBo=.c0371bca-5d8a-4f90-bf66-23f457366bca@github.com>

On Fri, 12 Nov 2021 05:47:12 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>    
>    This adds a new unit test that calculates a high-precision bounding box (using BigDecimals), and then makes sure our double-based logic contains that high-precision bounds.
>    
>    This restores getBounds2D() to its original contract: it should only ever be *larger* than the actual bounds -- it should never be smaller.
>    
>    Also we want to only apply this margin (aka "padding") when we deal with polynomial-based extrema. We should never apply it to line-based polygons. For ex: a Path2D that represents an int-based rectangle should return the same bounds as before 8176501 was addressed.
>    
>    This test currently only addresses very small cubic curves.
>    
>    I experimented with very large cubic & quadratic curves, but I didn't come up with a unit test that failed before and after this commit. Adding unit tests for large curve segments is a possible area of improvement.
>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>    
>    Addressing code review comments: given current code structure we don't need separate data structures for x and y equations.
>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>    
>    Removing accidental leftover code. This should have been removed in a recent previous commit. The preceding code already defines these values.

src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2124:

> 2122:         // a box that is slightly too small. But the contract of this method
> 2123:         // says we should err on the side of being too large.
> 2124:         // So to address this: we take the difference between the control

This is my alternative proposal to use the polynomial error as base error (cubic case is more tricky as solveQuadratic is problematic too for huge curves):

        // So to address this: we take using the upper limit of numerical error
        // caused by the polynomial evaluation (horner scheme).

        for (; !pi.isDone(); pi.next()) {
            final int type = pi.currentSegment(coords);
            switch (type) {
                case PathIterator.SEG_MOVETO:
                    if (!started) {
                        started = true;
                        leftX = rightX = coords[0];
                        topY = bottomY = coords[1];
                    } else {
                        if (coords[0] < leftX) {
                            leftX = coords[0];
                        }
                        if (coords[0] > rightX) {
                            rightX = coords[0];
                        }
                        if (coords[1] < topY) {
                            topY = coords[1];
                        }
                        if (coords[1] > bottomY) {
                            bottomY = coords[1];
                        }
                    }
                    lastX = coords[0];
                    lastY = coords[1];
                    break;
                case PathIterator.SEG_LINETO:
                    if (coords[0] < leftX) {
                        leftX = coords[0];
                    }
                    if (coords[0] > rightX) {
                        rightX = coords[0];
                    }
                    if (coords[1] < topY) {
                        topY = coords[1];
                    }
                    if (coords[1] > bottomY) {
                        bottomY = coords[1];
                    }
                    lastX = coords[0];
                    lastY = coords[1];
                    break;
                case PathIterator.SEG_QUADTO:
                    if (coords[2] < leftX) {
                        leftX = coords[2];
                    }
                    if (coords[2] > rightX) {
                        rightX = coords[2];
                    }
                    if (coords[3] < topY) {
                        topY = coords[3];
                    }
                    if (coords[3] > bottomY) {
                        bottomY = coords[3];
                    }

                    if (coords[0] < leftX || coords[0] > rightX) {
                        final double dx21 = (coords[0] - lastX);
                        coeff[2] = (coords[2] - coords[0]) - dx21;  // A = P3 - P0 - 2 P2
                        coeff[1] = 2.0 * dx21;                      // B = 2 (P2 - P1)
                        coeff[0] = lastX;                           // C = P1

                        deriv_coeff[0] = coeff[1];
                        deriv_coeff[1] = 2.0 * coeff[2];

                        double t = -deriv_coeff[0] / deriv_coeff[1];
                        if (t > 0.0 && t < 1.0) {
                            double x = coeff[0] + t * (coeff[1] + t * coeff[2]);

                            // error condition = sum ( abs (coeff) ):
                            final double margin = Math.ulp( Math.abs(coeff[0])
                                    + Math.abs(coeff[1]) + Math.abs(coeff[2]));

                            if (x - margin < leftX) {
                                leftX = x - margin;
                            }
                            if (x + margin > rightX) {
                                rightX = x + margin;
                            }
                        }
                    }
                    if (coords[1] < topY || coords[1] > bottomY) {
                        final double dy21 = (coords[1] - lastY);
                        coeff[2] = (coords[3] - coords[1]) - dy21;
                        coeff[1] = 2.0 * dy21;
                        coeff[0] = lastY;

                        deriv_coeff[0] = coeff[1];
                        deriv_coeff[1] = 2.0 * coeff[2];

                        double t = -deriv_coeff[0] / deriv_coeff[1];
                        if (t > 0.0 && t < 1.0) {
                            double y = coeff[0] + t * (coeff[1] + t * coeff[2]);
                            
                            // error condition = sum ( abs (coeff) ):
                            final double margin = Math.ulp( Math.abs(coeff[0])
                                    + Math.abs(coeff[1]) + Math.abs(coeff[2]));
                            
                            if (y - margin < topY) {
                                topY = y - margin;
                            }
                            if (y + margin > bottomY) {
                                bottomY = y + margin;
                            }
                        }
                    }
                    lastX = coords[2];
                    lastY = coords[3];
                    break;
                case PathIterator.SEG_CUBICTO:
                    if (coords[4] < leftX) {
                        leftX = coords[4];
                    }
                    if (coords[4] > rightX) {
                        rightX = coords[4];
                    }
                    if (coords[5] < topY) {
                        topY = coords[5];
                    }
                    if (coords[5] > bottomY) {
                        bottomY = coords[5];
                    }

                    if (coords[0] < leftX || coords[0] > rightX || coords[2] < leftX || coords[2] > rightX) {
                        final double dx32 = 3.0 * (coords[2] - coords[0]);
                        final double dx21 = 3.0 * (coords[0] - lastX);
                        coeff[3] = (coords[4] - lastX) - dx32;  // A = P3 - P0 - 3 (P2 - P1) = (P3 - P0) + 3 (P1 - P2)
                        coeff[2] = (dx32 - dx21);               // B = 3 (P2 - P1) - 3(P1 - P0) = 3 (P2 + P0) - 6 P1
                        coeff[1] = dx21;                        // C = 3 (P1 - P0)
                        coeff[0] = lastX;                       // D = P0

                        deriv_coeff[0] = coeff[1];
                        deriv_coeff[1] = 2.0 * coeff[2];
                        deriv_coeff[2] = 3.0 * coeff[3];

                        // solveQuadratic should be improved to get correct t extrema (1 ulp):
                        final int tExtremaCount = QuadCurve2D.solveQuadratic(deriv_coeff, tExtrema);
                        if (tExtremaCount > 0) {
                            // error condition = sum ( abs (coeff) ):
                            final double margin = Math.ulp(Math.abs(coeff[0])
                                    + Math.abs(coeff[1]) + Math.abs(coeff[2])
                                    + Math.abs(coeff[3]));

                            for (int i = 0; i < tExtremaCount; i++) {
                                final double t = tExtrema[i];
                                if (t > 0.0 && t < 1.0) {
                                    double x = coeff[0] + t * (coeff[1] + t * (coeff[2] + t * coeff[3]));
                                    if (x - margin < leftX) {
                                        leftX = x - margin;
                                    }
                                    if (x + margin > rightX) {
                                        rightX = x + margin;
                                    }
                                }
                            }
                        }
                    }
                    if (coords[1] < topY || coords[1] > bottomY || coords[3] < topY || coords[3] > bottomY) {
                        final double dy32 = 3.0 * (coords[3] - coords[1]);
                        final double dy21 = 3.0 * (coords[1] - lastY);
                        coeff[3] = (coords[5] - lastY) - dy32;
                        coeff[2] = (dy32 - dy21);
                        coeff[1] = dy21;
                        coeff[0] = lastY;

                        deriv_coeff[0] = coeff[1];
                        deriv_coeff[1] = 2.0 * coeff[2];
                        deriv_coeff[2] = 3.0 * coeff[3];

                        int tExtremaCount = QuadCurve2D.solveQuadratic(deriv_coeff, tExtrema);
                        if (tExtremaCount > 0) {
                            // error condition = sum ( abs (coeff) ):
                            final double margin = Math.ulp(Math.abs(coeff[0])
                                    + Math.abs(coeff[1]) + Math.abs(coeff[2])
                                    + Math.abs(coeff[3]));

                            for (int i = 0; i < tExtremaCount; i++) {
                                double t = tExtrema[i];
                                if (t > 0.0 && t < 1.0) {
                                    double y = coeff[0] + t * (coeff[1] + t * (coeff[2] + t * coeff[3]));
                                    if (y - margin < topY) {
                                        topY = y - margin;
                                    }
                                    if (y + margin > bottomY) {
                                        bottomY = y + margin;
                                    }
                                }
                            }
                        }
                    }
                    lastX = coords[4];
                    lastY = coords[5];
                    break;
                case PathIterator.SEG_CLOSE:
                default:
            }
        }

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

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


From serb at openjdk.java.net  Tue Nov 16 00:43:32 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 16 Nov 2021 00:43:32 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v3]
In-Reply-To: <ZTlmTugLnJJ1C4zpBPWm2IGSm5PVxkNXcMXlOSguvog=.0ee2d1e4-a91b-463c-9470-a32b90fce937@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <gwA_8ObJLdJifNeXZH96uV_wHvY8TkSJyeqo91tgkhE=.9b578d70-9a44-48ef-a0fc-f10a47ca6418@github.com>
 <ZTlmTugLnJJ1C4zpBPWm2IGSm5PVxkNXcMXlOSguvog=.0ee2d1e4-a91b-463c-9470-a32b90fce937@github.com>
Message-ID: <qIUvpCLlEaDOEhEX2IxRiHpdbh3B1n2XhA-zlXXaTgU=.306e8484-3cf0-4a13-81e4-f8d9c07782b0@github.com>

On Mon, 15 Nov 2021 08:06:13 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Masanori Yano has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
>>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java line 1459:
> 
>> 1457:         int biType = imgType.getBufferedImageType();
>> 1458:         int bpp = imgType.getColorModel().getPixelSize();
>> 1459:         if (bpp != 0 && bpp != 1 && bpp != 4 && bpp != 8 && bpp != 16 && bpp != 24 && bpp != 32) {
> 
> This change looks good to me.

Probably the exception message caused by this should be updated as well? Currently, it takes care of compression only.

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

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


From duke at openjdk.java.net  Tue Nov 16 04:46:07 2021
From: duke at openjdk.java.net (Jeremy)
Date: Tue, 16 Nov 2021 04:46:07 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v8]
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <4YC95pXalYpZo0m0eB_TKkVO4gDMebj7og2MM9O7104=.69f6d3c9-c475-4d16-a006-45907e4765d3@github.com>

> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
> 
> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
> B. Updating the unit test to forgive the discrepancy.
> 
> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
> 
> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
> 
> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

Jeremy has updated the pull request incrementally with two additional commits since the last revision:

 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
   
   This is broadly addresses the code review feedback: "I see many duplicated lines". This commit does NOT include "the previous unified solution" that is also mentioned... so we'll try this on and see how we feel about it.
   
   https://github.com/openjdk/jdk/pull/6227#issuecomment-964020449
 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
   
   Applying Laurent's implementation to address machine error.
   
   See https://github.com/openjdk/jdk/pull/6227#discussion_r749672090

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6227/files
  - new: https://git.openjdk.java.net/jdk/pull/6227/files/40bda064..0e2b5293

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

  Stats: 316 lines in 2 files changed: 142 ins; 158 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6227.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6227/head:pull/6227

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


From duke at openjdk.java.net  Tue Nov 16 05:27:39 2021
From: duke at openjdk.java.net (Jeremy)
Date: Tue, 16 Nov 2021 05:27:39 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v5]
In-Reply-To: <1bsoBtuyINX0C5ApYsOUoh78rEkjt4WEQumU4qf_pkk=.591c47a7-20b1-4dbf-a3d3-2b1d47345c4f@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <MSkEUKcb6PeZ9IuHaoSOpaefJDdbViAxK0XAzb6vL-s=.02f4f130-d8c0-4b3c-a108-dcb5df7a129a@github.com>
 <1bsoBtuyINX0C5ApYsOUoh78rEkjt4WEQumU4qf_pkk=.591c47a7-20b1-4dbf-a3d3-2b1d47345c4f@github.com>
Message-ID: <MIW8wyPf2ibPKuTyIBqtlkXitlHxffGnLL8T-ZXPJpc=.b88b9abf-3263-4b0b-8765-8ba7344aa89f@github.com>

On Tue, 9 Nov 2021 10:34:11 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>>   
>>   Addressing code review recommendation to calculate polynomial coefficients using differences / vector notation.
>>   
>>   https://github.com/openjdk/jdk/pull/6227#discussion_r743534560
>>   
>>   I generally understand the intention of this change, but I don't know exactly how to test/evaluate it.
>>   
>>   The unit tests still pass. I ran some sample calculations involving a 100x100 Ellipse2D as it was rotated, and the two getBounds2D(..) implementations (before and after this commit) only differed by a few ulps (usually around 10^-15), as expected.
>
> Great !
> I see many duplicated lines, probably it is time to add 2 small methods to processCubic() and processQuad() that can be called on x and y equations => only 2 arrays needed for coeff and deriv_coeff. 
> Maybe I prefer the previous unified solution relying on QuadCurve2D.solveQuadratic() that handles both case.

@bourgesl : I refactored things just now to address the "many duplicated lines" comment. At your convenience please me know if the current branch looks/feels better, or if you have other recommendations in mind.

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

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


From duke at openjdk.java.net  Tue Nov 16 05:27:41 2021
From: duke at openjdk.java.net (Jeremy)
Date: Tue, 16 Nov 2021 05:27:41 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v7]
In-Reply-To: <EYfOcl9reCwSGc_6Wiq3C15vPPM7qX-xQcrlWY7qBBo=.c0371bca-5d8a-4f90-bf66-23f457366bca@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <cgAWhv1J6wQIciHNQKgwHmTFucfbTGWHrmuijw15wg4=.5153f11f-86f1-4e3d-bf79-286f64801ce8@github.com>
 <EYfOcl9reCwSGc_6Wiq3C15vPPM7qX-xQcrlWY7qBBo=.c0371bca-5d8a-4f90-bf66-23f457366bca@github.com>
Message-ID: <wot-957L5Hw6y-Y-aE3pzU225EhqGTqHwEPpowD9JKY=.81740956-b06b-4131-a08c-1df6f612a91f@github.com>

On Mon, 15 Nov 2021 20:52:00 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>>    
>>    This adds a new unit test that calculates a high-precision bounding box (using BigDecimals), and then makes sure our double-based logic contains that high-precision bounds.
>>    
>>    This restores getBounds2D() to its original contract: it should only ever be *larger* than the actual bounds -- it should never be smaller.
>>    
>>    Also we want to only apply this margin (aka "padding") when we deal with polynomial-based extrema. We should never apply it to line-based polygons. For ex: a Path2D that represents an int-based rectangle should return the same bounds as before 8176501 was addressed.
>>    
>>    This test currently only addresses very small cubic curves.
>>    
>>    I experimented with very large cubic & quadratic curves, but I didn't come up with a unit test that failed before and after this commit. Adding unit tests for large curve segments is a possible area of improvement.
>>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>>    
>>    Addressing code review comments: given current code structure we don't need separate data structures for x and y equations.
>>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>>    
>>    Removing accidental leftover code. This should have been removed in a recent previous commit. The preceding code already defines these values.
>
> src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2124:
> 
>> 2122:         // a box that is slightly too small. But the contract of this method
>> 2123:         // says we should err on the side of being too large.
>> 2124:         // So to address this: we take the difference between the control
> 
> This is my alternative proposal to use the polynomial error as base error (cubic case is more tricky as solveQuadratic is problematic too for huge curves):
> 
>         // So to address this: we take using the upper limit of numerical error
>         // caused by the polynomial evaluation (horner scheme).
> 
>         for (; !pi.isDone(); pi.next()) {
>             final int type = pi.currentSegment(coords);
>             switch (type) {
>                 case PathIterator.SEG_MOVETO:
>                     if (!started) {
>                         started = true;
>                         leftX = rightX = coords[0];
>                         topY = bottomY = coords[1];
>                     } else {
>                         if (coords[0] < leftX) {
>                             leftX = coords[0];
>                         }
>                         if (coords[0] > rightX) {
>                             rightX = coords[0];
>                         }
>                         if (coords[1] < topY) {
>                             topY = coords[1];
>                         }
>                         if (coords[1] > bottomY) {
>                             bottomY = coords[1];
>                         }
>                     }
>                     lastX = coords[0];
>                     lastY = coords[1];
>                     break;
>                 case PathIterator.SEG_LINETO:
>                     if (coords[0] < leftX) {
>                         leftX = coords[0];
>                     }
>                     if (coords[0] > rightX) {
>                         rightX = coords[0];
>                     }
>                     if (coords[1] < topY) {
>                         topY = coords[1];
>                     }
>                     if (coords[1] > bottomY) {
>                         bottomY = coords[1];
>                     }
>                     lastX = coords[0];
>                     lastY = coords[1];
>                     break;
>                 case PathIterator.SEG_QUADTO:
>                     if (coords[2] < leftX) {
>                         leftX = coords[2];
>                     }
>                     if (coords[2] > rightX) {
>                         rightX = coords[2];
>                     }
>                     if (coords[3] < topY) {
>                         topY = coords[3];
>                     }
>                     if (coords[3] > bottomY) {
>                         bottomY = coords[3];
>                     }
> 
>                     if (coords[0] < leftX || coords[0] > rightX) {
>                         final double dx21 = (coords[0] - lastX);
>                         coeff[2] = (coords[2] - coords[0]) - dx21;  // A = P3 - P0 - 2 P2
>                         coeff[1] = 2.0 * dx21;                      // B = 2 (P2 - P1)
>                         coeff[0] = lastX;                           // C = P1
> 
>                         deriv_coeff[0] = coeff[1];
>                         deriv_coeff[1] = 2.0 * coeff[2];
> 
>                         double t = -deriv_coeff[0] / deriv_coeff[1];
>                         if (t > 0.0 && t < 1.0) {
>                             double x = coeff[0] + t * (coeff[1] + t * coeff[2]);
> 
>                             // error condition = sum ( abs (coeff) ):
>                             final double margin = Math.ulp( Math.abs(coeff[0])
>                                     + Math.abs(coeff[1]) + Math.abs(coeff[2]));
> 
>                             if (x - margin < leftX) {
>                                 leftX = x - margin;
>                             }
>                             if (x + margin > rightX) {
>                                 rightX = x + margin;
>                             }
>                         }
>                     }
>                     if (coords[1] < topY || coords[1] > bottomY) {
>                         final double dy21 = (coords[1] - lastY);
>                         coeff[2] = (coords[3] - coords[1]) - dy21;
>                         coeff[1] = 2.0 * dy21;
>                         coeff[0] = lastY;
> 
>                         deriv_coeff[0] = coeff[1];
>                         deriv_coeff[1] = 2.0 * coeff[2];
> 
>                         double t = -deriv_coeff[0] / deriv_coeff[1];
>                         if (t > 0.0 && t < 1.0) {
>                             double y = coeff[0] + t * (coeff[1] + t * coeff[2]);
>                             
>                             // error condition = sum ( abs (coeff) ):
>                             final double margin = Math.ulp( Math.abs(coeff[0])
>                                     + Math.abs(coeff[1]) + Math.abs(coeff[2]));
>                             
>                             if (y - margin < topY) {
>                                 topY = y - margin;
>                             }
>                             if (y + margin > bottomY) {
>                                 bottomY = y + margin;
>                             }
>                         }
>                     }
>                     lastX = coords[2];
>                     lastY = coords[3];
>                     break;
>                 case PathIterator.SEG_CUBICTO:
>                     if (coords[4] < leftX) {
>                         leftX = coords[4];
>                     }
>                     if (coords[4] > rightX) {
>                         rightX = coords[4];
>                     }
>                     if (coords[5] < topY) {
>                         topY = coords[5];
>                     }
>                     if (coords[5] > bottomY) {
>                         bottomY = coords[5];
>                     }
> 
>                     if (coords[0] < leftX || coords[0] > rightX || coords[2] < leftX || coords[2] > rightX) {
>                         final double dx32 = 3.0 * (coords[2] - coords[0]);
>                         final double dx21 = 3.0 * (coords[0] - lastX);
>                         coeff[3] = (coords[4] - lastX) - dx32;  // A = P3 - P0 - 3 (P2 - P1) = (P3 - P0) + 3 (P1 - P2)
>                         coeff[2] = (dx32 - dx21);               // B = 3 (P2 - P1) - 3(P1 - P0) = 3 (P2 + P0) - 6 P1
>                         coeff[1] = dx21;                        // C = 3 (P1 - P0)
>                         coeff[0] = lastX;                       // D = P0
> 
>                         deriv_coeff[0] = coeff[1];
>                         deriv_coeff[1] = 2.0 * coeff[2];
>                         deriv_coeff[2] = 3.0 * coeff[3];
> 
>                         // solveQuadratic should be improved to get correct t extrema (1 ulp):
>                         final int tExtremaCount = QuadCurve2D.solveQuadratic(deriv_coeff, tExtrema);
>                         if (tExtremaCount > 0) {
>                             // error condition = sum ( abs (coeff) ):
>                             final double margin = Math.ulp(Math.abs(coeff[0])
>                                     + Math.abs(coeff[1]) + Math.abs(coeff[2])
>                                     + Math.abs(coeff[3]));
> 
>                             for (int i = 0; i < tExtremaCount; i++) {
>                                 final double t = tExtrema[i];
>                                 if (t > 0.0 && t < 1.0) {
>                                     double x = coeff[0] + t * (coeff[1] + t * (coeff[2] + t * coeff[3]));
>                                     if (x - margin < leftX) {
>                                         leftX = x - margin;
>                                     }
>                                     if (x + margin > rightX) {
>                                         rightX = x + margin;
>                                     }
>                                 }
>                             }
>                         }
>                     }
>                     if (coords[1] < topY || coords[1] > bottomY || coords[3] < topY || coords[3] > bottomY) {
>                         final double dy32 = 3.0 * (coords[3] - coords[1]);
>                         final double dy21 = 3.0 * (coords[1] - lastY);
>                         coeff[3] = (coords[5] - lastY) - dy32;
>                         coeff[2] = (dy32 - dy21);
>                         coeff[1] = dy21;
>                         coeff[0] = lastY;
> 
>                         deriv_coeff[0] = coeff[1];
>                         deriv_coeff[1] = 2.0 * coeff[2];
>                         deriv_coeff[2] = 3.0 * coeff[3];
> 
>                         int tExtremaCount = QuadCurve2D.solveQuadratic(deriv_coeff, tExtrema);
>                         if (tExtremaCount > 0) {
>                             // error condition = sum ( abs (coeff) ):
>                             final double margin = Math.ulp(Math.abs(coeff[0])
>                                     + Math.abs(coeff[1]) + Math.abs(coeff[2])
>                                     + Math.abs(coeff[3]));
> 
>                             for (int i = 0; i < tExtremaCount; i++) {
>                                 double t = tExtrema[i];
>                                 if (t > 0.0 && t < 1.0) {
>                                     double y = coeff[0] + t * (coeff[1] + t * (coeff[2] + t * coeff[3]));
>                                     if (y - margin < topY) {
>                                         topY = y - margin;
>                                     }
>                                     if (y + margin > bottomY) {
>                                         bottomY = y + margin;
>                                     }
>                                 }
>                             }
>                         }
>                     }
>                     lastX = coords[4];
>                     lastY = coords[5];
>                     break;
>                 case PathIterator.SEG_CLOSE:
>                 default:
>             }
>         }

Looks good, and it passes all the unit tests. I pushed an update with this code. (Although immediately after that I pushed a refactor for readability that you previously requested -- so the logic/margin is in the branch now but it looks a little different already...)

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

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


From serb at openjdk.java.net  Tue Nov 16 07:56:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 16 Nov 2021 07:56:36 GMT
Subject: RFR: 8270874: JFrame paint artifacts when dragged from standard
 monitor to HiDPI monitor
In-Reply-To: <8f93oLv4_N0vNlmfkvXQrju73GxBjyD1LW-d06poJus=.7dd8b1ef-2771-4709-b06f-1c5ef649d8de@github.com>
References: <hPV-NYDHAMhyOviuU89e9Frm1ALNGqn_Uw0i4NDscRE=.e3fcd015-0bc5-4e7a-92f0-8474ee8af548@github.com>
 <8f93oLv4_N0vNlmfkvXQrju73GxBjyD1LW-d06poJus=.7dd8b1ef-2771-4709-b06f-1c5ef649d8de@github.com>
Message-ID: <q7Xo4e_E1h_qpGelzXie8AMV1f3oi-hQysdCsUgy3x8=.08c4e8d6-e270-4e42-b46a-639466088c6d@github.com>

On Mon, 15 Nov 2021 10:00:37 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Please correct my understanding. Does this refined repaint logic apply even for overlapping Windows? What happens when 2 windows are overlapping and we move top window slowly? Any performance/power impact?

Initially, this code was used just for that, to make a fast blit of the content from the Swing back buffer to the native window, when some other window is moved over the Swing and damaged it (the fix for the "grey rectangle" JDK-4967886). But since Windows Vista the Windows itself maintain such doublebuffer and the content is not damaged when windows overlap, so this callback is not called.

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

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


From serb at openjdk.java.net  Tue Nov 16 07:58:34 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 16 Nov 2021 07:58:34 GMT
Subject: RFR: 8169468: NoResizeEventOnDMChangeTest.java fails because FS
 Window didn't receive all resizes! [v3]
In-Reply-To: <ESDcvvz0EfoHXtg5aFV7Xtk7Ax9InIqryoVpvuY_h64=.f5246d99-26bd-4a4a-8cd7-eaf256d08d10@github.com>
References: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
 <ESDcvvz0EfoHXtg5aFV7Xtk7Ax9InIqryoVpvuY_h64=.f5246d99-26bd-4a4a-8cd7-eaf256d08d10@github.com>
Message-ID: <sdejDfww9A3Rb5VaXY_ZuT23n6-GgvAvgcG3-1sUHOA=.0bafe09f-d436-4fec-98e9-5aead8fe3d72@github.com>

On Wed, 10 Nov 2021 05:35:12 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> I was able to reproduce this issue locally 2 times out of 100 runs on multi-monitor
>> configuration. Both times due to the screen resolution change is so slow window got
>> accidentally moved to the secondary screen by the display driver.
>> Can not reproduce this bug with ATI card at all.
>> Since there is nothing we can do to stop graphics driver from reassigning
>> the window if it decides that promary monitor is not on at the moment the
>> only way is to check if this has had happened and if so then we can not trust the test
>> since we changing resolution of one display and window not getting resized
>> because it is placed on another display and test should be skept.
>> 
>> After that i ran this test locally about a thousand times on all platforms
>> and has not seen the failure again.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added speel for 2 seconds after setting new display mode.
>   Removed unneeded imports.

Marked as reviewed by serb (Reviewer).

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

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


From mbaesken at openjdk.java.net  Tue Nov 16 08:23:35 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 16 Nov 2021 08:23:35 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows [v2]
In-Reply-To: <TLZCU19EefUZsbV-wsMzt1maLALv9kxTQEovRyKD0EE=.d53f9b96-8c6f-4abb-a2aa-6ac1592625db@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
 <rk3QGVEVrD9pHr6p5mwpP4Gxn2Sxd7WXUD0_SwEiSkQ=.545b4b8f-3eb2-49a2-9233-0ce9a90161bc@github.com>
 <TLZCU19EefUZsbV-wsMzt1maLALv9kxTQEovRyKD0EE=.d53f9b96-8c6f-4abb-a2aa-6ac1592625db@github.com>
Message-ID: <YSaCc8bMAHnoma2dPC5CRqqyxrGuQMuWRBm8W5a8HEA=.412815c4-c634-4e3b-b75a-b539817f03d3@github.com>

On Mon, 15 Nov 2021 02:51:33 GMT, Phil Race <prr at openjdk.org> wrote:

> We have issues running in debug mode even in headful mode - https://bugs.openjdk.java.net/browse/JDK-8264773 I think this PR should be withdrawn. We need a holistic look at making sure we run properly in debug builds on windows when we get time. In other words don't try to fix up individual tests, especially by suppressing the error.

Hi Phil,  what about excluding the  test  java/awt/font/JNICheck/FreeTypeScalerJNICheck.java   on Windows ?
That would be fine with me too .

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

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


From clanger at openjdk.java.net  Tue Nov 16 08:32:38 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 16 Nov 2021 08:32:38 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows [v2]
In-Reply-To: <YSaCc8bMAHnoma2dPC5CRqqyxrGuQMuWRBm8W5a8HEA=.412815c4-c634-4e3b-b75a-b539817f03d3@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
 <rk3QGVEVrD9pHr6p5mwpP4Gxn2Sxd7WXUD0_SwEiSkQ=.545b4b8f-3eb2-49a2-9233-0ce9a90161bc@github.com>
 <TLZCU19EefUZsbV-wsMzt1maLALv9kxTQEovRyKD0EE=.d53f9b96-8c6f-4abb-a2aa-6ac1592625db@github.com>
 <YSaCc8bMAHnoma2dPC5CRqqyxrGuQMuWRBm8W5a8HEA=.412815c4-c634-4e3b-b75a-b539817f03d3@github.com>
Message-ID: <3GGalBXg-mIqGMVNASkhbxrVgASbLISf3CwNPlNMxNo=.18a25034-86bf-4f61-ad26-228101b4baa9@github.com>

On Tue, 16 Nov 2021 08:20:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > We have issues running in debug mode even in headful mode - https://bugs.openjdk.java.net/browse/JDK-8264773 I think this PR should be withdrawn. We need a holistic look at making sure we run properly in debug builds on windows when we get time. In other words don't try to fix up individual tests, especially by suppressing the error.
> 
> Hi Phil, what about excluding the test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java on Windows ? That would be fine with me too .

I understand that this is about the debug build on Windows only. So why not solve it like this: https://github.com/openjdk/jdk/commit/d042029509a8cbdb723f78e2cfee4e2885775814 ?

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

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


From lbourges at openjdk.java.net  Tue Nov 16 08:39:42 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Tue, 16 Nov 2021 08:39:42 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v8]
In-Reply-To: <4YC95pXalYpZo0m0eB_TKkVO4gDMebj7og2MM9O7104=.69f6d3c9-c475-4d16-a006-45907e4765d3@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <4YC95pXalYpZo0m0eB_TKkVO4gDMebj7og2MM9O7104=.69f6d3c9-c475-4d16-a006-45907e4765d3@github.com>
Message-ID: <qxGzla8Xmlg4O2fAub0VbFqLSy1NWfBB1fhj6n3Y0Po=.2c58fc3b-272f-4a54-bc33-8e65128e060e@github.com>

On Tue, 16 Nov 2021 04:46:07 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>    
>    This is broadly addresses the code review feedback: "I see many duplicated lines". This commit does NOT include "the previous unified solution" that is also mentioned... so we'll try this on and see how we feel about it.
>    
>    https://github.com/openjdk/jdk/pull/6227#issuecomment-964020449
>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>    
>    Applying Laurent's implementation to address machine error.
>    
>    See https://github.com/openjdk/jdk/pull/6227#discussion_r749672090

Looks good refactoring.
I would prefer having accumulate functions called twice (using offset) if needed on x then y if needed (bbox condition in caller) and move all array allocations out of loops as before.

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

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


From mbaesken at openjdk.java.net  Tue Nov 16 08:43:43 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 16 Nov 2021 08:43:43 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows [v2]
In-Reply-To: <rk3QGVEVrD9pHr6p5mwpP4Gxn2Sxd7WXUD0_SwEiSkQ=.545b4b8f-3eb2-49a2-9233-0ce9a90161bc@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
 <rk3QGVEVrD9pHr6p5mwpP4Gxn2Sxd7WXUD0_SwEiSkQ=.545b4b8f-3eb2-49a2-9233-0ce9a90161bc@github.com>
Message-ID: <hHVxCbeyGNNM5B-PrxqfJTwDQR80_j3qzgrDQ8HL2JA=.c122666c-475b-4a86-a2c6-3d03f0c29b66@github.com>

On Fri, 12 Nov 2021 07:57:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni to an awt related test, and shows on Windows server 2019 the following JNI warning , so the test  JNICheck/FreeTypeScalerJNICheck.java fails on this Windows version.
>> 
>> :stdErr:
>> Thu Oct 28 01:27:10 CEST 2021
>> stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV
>>                at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 18.0.0.1-internal/Native Method)
>>                at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:95)
>>                at sun.awt.Win32GraphicsEnvironment.<clinit>(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:63)
>>                at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 18.0.0.1-internal/PlatformGraphicsInfo.java:34)
>>                at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:93)
>>                at java.awt.GraphicsEnvironment$LocalGE.<clinit>(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:84)
>>                at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:106)
>>                at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53)
>>                at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)
>> 
>> We can get rid of the warning by adjusting a JNU_CallStaticMethodByName call in awt_Win32GraphicsEnv.cpp .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a J2dTraceLn call

Our central tests were running with a fastdebug jvm. I do not know what would have happened with an opt/product JVM on the same test machine. I would prefer the exclude list but if this is not wanted then we can use requires in the test as well.
The java/awt/font/JNICheck/FreeTypeScalerJNICheck.java  test was added with Linux in mind anyway afaik.

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

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


From myano at openjdk.java.net  Tue Nov 16 09:30:42 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Tue, 16 Nov 2021 09:30:42 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails [v2]
In-Reply-To: <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>
 <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
Message-ID: <5yujJUG9qlyd1ZNoyERSRTAuwUbgxcPgtIZkkgbRYNQ=.209513fa-9321-4d76-9037-553110dd96a4@github.com>

On Tue, 26 Oct 2021 04:52:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Masanori Yano 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:
>> 
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - Merge branch 'master' of https://github.com/masyano/jdk into 7001973
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>
> I'll check it, let me some time.

@mrserb Could you tell me how long it will take to run the test?

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

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


From duke at openjdk.java.net  Tue Nov 16 10:44:57 2021
From: duke at openjdk.java.net (kabutz)
Date: Tue, 16 Nov 2021 10:44:57 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
Message-ID: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>

BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.

The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3.  Fibonacci 100 million is a 347084 bit number.

We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.


Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
BigIntegerParallelMultiply.multiply            1000000    ss    4     68,043 ?   25,317  ms/op
BigIntegerParallelMultiply.multiply           10000000    ss    4   1073,095 ?  125,296  ms/op
BigIntegerParallelMultiply.multiply          100000000    ss    4  25317,535 ? 5806,205  ms/op
BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     56,552 ?   22,368  ms/op
BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    536,193 ?   37,393  ms/op
BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9274,657 ?  826,197  ms/op

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

Commit messages:
 - Update comments
 - Added parallelMultiply() method to BigInteger to allow large multiplications to run in parallel
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'origin/master'
 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box

Changes: https://git.openjdk.java.net/jdk/pull/6391/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6391&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277175
  Stats: 731 lines in 8 files changed: 565 ins; 136 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6391.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6391/head:pull/6391

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


From duke at openjdk.java.net  Tue Nov 16 10:53:37 2021
From: duke at openjdk.java.net (kabutz)
Date: Tue, 16 Nov 2021 10:53:37 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
In-Reply-To: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
References: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
Message-ID: <10mS64ECRQ8QyDy3DpwQ--GyY1eqbmhEMyIe08_txYY=.f2a380d5-9367-420a-9239-5ace3a4cec25@github.com>

On Mon, 15 Nov 2021 15:50:39 GMT, kabutz <duke at openjdk.java.net> wrote:

> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
> 
> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3.  Fibonacci 100 million is a 347084 bit number.
> 
> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
> 
> 
> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
> BigIntegerParallelMultiply.multiply            1000000    ss    4     68,043 ?   25,317  ms/op
> BigIntegerParallelMultiply.multiply           10000000    ss    4   1073,095 ?  125,296  ms/op
> BigIntegerParallelMultiply.multiply          100000000    ss    4  25317,535 ? 5806,205  ms/op
> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     56,552 ?   22,368  ms/op
> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    536,193 ?   37,393  ms/op
> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9274,657 ?  826,197  ms/op

Some more benchmark results, run on my 1-6-2 server:


Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
BigIntegerParallelMultiply.multiply            1000000    ss    4     51.707 ?   11.194  ms/op
BigIntegerParallelMultiply.multiply           10000000    ss    4    988.302 ?  235.977  ms/op
BigIntegerParallelMultiply.multiply          100000000    ss    4  24662.063 ? 1123.329  ms/op
BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     49.337 ?   26.611  ms/op
BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    527.560 ?  268.903  ms/op
BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9076.551 ? 1899.444  ms/op


We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine.

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

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


From lbourges at openjdk.java.net  Tue Nov 16 11:00:36 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Tue, 16 Nov 2021 11:00:36 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v8]
In-Reply-To: <4YC95pXalYpZo0m0eB_TKkVO4gDMebj7og2MM9O7104=.69f6d3c9-c475-4d16-a006-45907e4765d3@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <4YC95pXalYpZo0m0eB_TKkVO4gDMebj7og2MM9O7104=.69f6d3c9-c475-4d16-a006-45907e4765d3@github.com>
Message-ID: <r37RLyC4uB6bZi3PU5J99YIPNLoQLKcUaFSA4cowciE=.e11ce3b7-e703-4749-9d4d-3e4e552b1d49@github.com>

On Tue, 16 Nov 2021 04:46:07 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>    
>    This is broadly addresses the code review feedback: "I see many duplicated lines". This commit does NOT include "the previous unified solution" that is also mentioned... so we'll try this on and see how we feel about it.
>    
>    https://github.com/openjdk/jdk/pull/6227#issuecomment-964020449
>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>    
>    Applying Laurent's implementation to address machine error.
>    
>    See https://github.com/openjdk/jdk/pull/6227#discussion_r749672090

I propose to ask official jdk reviewers to review this patch for integration.
@prrace @mrserb

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

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


From lbourges at openjdk.java.net  Tue Nov 16 11:00:37 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Tue, 16 Nov 2021 11:00:37 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v7]
In-Reply-To: <wot-957L5Hw6y-Y-aE3pzU225EhqGTqHwEPpowD9JKY=.81740956-b06b-4131-a08c-1df6f612a91f@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <cgAWhv1J6wQIciHNQKgwHmTFucfbTGWHrmuijw15wg4=.5153f11f-86f1-4e3d-bf79-286f64801ce8@github.com>
 <EYfOcl9reCwSGc_6Wiq3C15vPPM7qX-xQcrlWY7qBBo=.c0371bca-5d8a-4f90-bf66-23f457366bca@github.com>
 <wot-957L5Hw6y-Y-aE3pzU225EhqGTqHwEPpowD9JKY=.81740956-b06b-4131-a08c-1df6f612a91f@github.com>
Message-ID: <fhVQBoNe1gvzEBMLb-IjN1qXhu6sBvU-GOnxgyi-d4E=.80e3f23d-ef90-4199-a3d2-d64a158afb27@github.com>

On Tue, 16 Nov 2021 05:22:13 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2124:
>> 
>>> 2122:         // a box that is slightly too small. But the contract of this method
>>> 2123:         // says we should err on the side of being too large.
>>> 2124:         // So to address this: we take the difference between the control
>> 
>> This is my alternative proposal to use the polynomial error as base error (cubic case is more tricky as solveQuadratic is problematic too for huge curves):
>> 
>>         // So to address this: we take using the upper limit of numerical error
>>         // caused by the polynomial evaluation (horner scheme).
>> 
>>         for (; !pi.isDone(); pi.next()) {
>>             final int type = pi.currentSegment(coords);
>>             switch (type) {
>>                 case PathIterator.SEG_MOVETO:
>>                     if (!started) {
>>                         started = true;
>>                         leftX = rightX = coords[0];
>>                         topY = bottomY = coords[1];
>>                     } else {
>>                         if (coords[0] < leftX) {
>>                             leftX = coords[0];
>>                         }
>>                         if (coords[0] > rightX) {
>>                             rightX = coords[0];
>>                         }
>>                         if (coords[1] < topY) {
>>                             topY = coords[1];
>>                         }
>>                         if (coords[1] > bottomY) {
>>                             bottomY = coords[1];
>>                         }
>>                     }
>>                     lastX = coords[0];
>>                     lastY = coords[1];
>>                     break;
>>                 case PathIterator.SEG_LINETO:
>>                     if (coords[0] < leftX) {
>>                         leftX = coords[0];
>>                     }
>>                     if (coords[0] > rightX) {
>>                         rightX = coords[0];
>>                     }
>>                     if (coords[1] < topY) {
>>                         topY = coords[1];
>>                     }
>>                     if (coords[1] > bottomY) {
>>                         bottomY = coords[1];
>>                     }
>>                     lastX = coords[0];
>>                     lastY = coords[1];
>>                     break;
>>                 case PathIterator.SEG_QUADTO:
>>                     if (coords[2] < leftX) {
>>                         leftX = coords[2];
>>                     }
>>                     if (coords[2] > rightX) {
>>                         rightX = coords[2];
>>                     }
>>                     if (coords[3] < topY) {
>>                         topY = coords[3];
>>                     }
>>                     if (coords[3] > bottomY) {
>>                         bottomY = coords[3];
>>                     }
>> 
>>                     if (coords[0] < leftX || coords[0] > rightX) {
>>                         final double dx21 = (coords[0] - lastX);
>>                         coeff[2] = (coords[2] - coords[0]) - dx21;  // A = P3 - P0 - 2 P2
>>                         coeff[1] = 2.0 * dx21;                      // B = 2 (P2 - P1)
>>                         coeff[0] = lastX;                           // C = P1
>> 
>>                         deriv_coeff[0] = coeff[1];
>>                         deriv_coeff[1] = 2.0 * coeff[2];
>> 
>>                         double t = -deriv_coeff[0] / deriv_coeff[1];
>>                         if (t > 0.0 && t < 1.0) {
>>                             double x = coeff[0] + t * (coeff[1] + t * coeff[2]);
>> 
>>                             // error condition = sum ( abs (coeff) ):
>>                             final double margin = Math.ulp( Math.abs(coeff[0])
>>                                     + Math.abs(coeff[1]) + Math.abs(coeff[2]));
>> 
>>                             if (x - margin < leftX) {
>>                                 leftX = x - margin;
>>                             }
>>                             if (x + margin > rightX) {
>>                                 rightX = x + margin;
>>                             }
>>                         }
>>                     }
>>                     if (coords[1] < topY || coords[1] > bottomY) {
>>                         final double dy21 = (coords[1] - lastY);
>>                         coeff[2] = (coords[3] - coords[1]) - dy21;
>>                         coeff[1] = 2.0 * dy21;
>>                         coeff[0] = lastY;
>> 
>>                         deriv_coeff[0] = coeff[1];
>>                         deriv_coeff[1] = 2.0 * coeff[2];
>> 
>>                         double t = -deriv_coeff[0] / deriv_coeff[1];
>>                         if (t > 0.0 && t < 1.0) {
>>                             double y = coeff[0] + t * (coeff[1] + t * coeff[2]);
>>                             
>>                             // error condition = sum ( abs (coeff) ):
>>                             final double margin = Math.ulp( Math.abs(coeff[0])
>>                                     + Math.abs(coeff[1]) + Math.abs(coeff[2]));
>>                             
>>                             if (y - margin < topY) {
>>                                 topY = y - margin;
>>                             }
>>                             if (y + margin > bottomY) {
>>                                 bottomY = y + margin;
>>                             }
>>                         }
>>                     }
>>                     lastX = coords[2];
>>                     lastY = coords[3];
>>                     break;
>>                 case PathIterator.SEG_CUBICTO:
>>                     if (coords[4] < leftX) {
>>                         leftX = coords[4];
>>                     }
>>                     if (coords[4] > rightX) {
>>                         rightX = coords[4];
>>                     }
>>                     if (coords[5] < topY) {
>>                         topY = coords[5];
>>                     }
>>                     if (coords[5] > bottomY) {
>>                         bottomY = coords[5];
>>                     }
>> 
>>                     if (coords[0] < leftX || coords[0] > rightX || coords[2] < leftX || coords[2] > rightX) {
>>                         final double dx32 = 3.0 * (coords[2] - coords[0]);
>>                         final double dx21 = 3.0 * (coords[0] - lastX);
>>                         coeff[3] = (coords[4] - lastX) - dx32;  // A = P3 - P0 - 3 (P2 - P1) = (P3 - P0) + 3 (P1 - P2)
>>                         coeff[2] = (dx32 - dx21);               // B = 3 (P2 - P1) - 3(P1 - P0) = 3 (P2 + P0) - 6 P1
>>                         coeff[1] = dx21;                        // C = 3 (P1 - P0)
>>                         coeff[0] = lastX;                       // D = P0
>> 
>>                         deriv_coeff[0] = coeff[1];
>>                         deriv_coeff[1] = 2.0 * coeff[2];
>>                         deriv_coeff[2] = 3.0 * coeff[3];
>> 
>>                         // solveQuadratic should be improved to get correct t extrema (1 ulp):
>>                         final int tExtremaCount = QuadCurve2D.solveQuadratic(deriv_coeff, tExtrema);
>>                         if (tExtremaCount > 0) {
>>                             // error condition = sum ( abs (coeff) ):
>>                             final double margin = Math.ulp(Math.abs(coeff[0])
>>                                     + Math.abs(coeff[1]) + Math.abs(coeff[2])
>>                                     + Math.abs(coeff[3]));
>> 
>>                             for (int i = 0; i < tExtremaCount; i++) {
>>                                 final double t = tExtrema[i];
>>                                 if (t > 0.0 && t < 1.0) {
>>                                     double x = coeff[0] + t * (coeff[1] + t * (coeff[2] + t * coeff[3]));
>>                                     if (x - margin < leftX) {
>>                                         leftX = x - margin;
>>                                     }
>>                                     if (x + margin > rightX) {
>>                                         rightX = x + margin;
>>                                     }
>>                                 }
>>                             }
>>                         }
>>                     }
>>                     if (coords[1] < topY || coords[1] > bottomY || coords[3] < topY || coords[3] > bottomY) {
>>                         final double dy32 = 3.0 * (coords[3] - coords[1]);
>>                         final double dy21 = 3.0 * (coords[1] - lastY);
>>                         coeff[3] = (coords[5] - lastY) - dy32;
>>                         coeff[2] = (dy32 - dy21);
>>                         coeff[1] = dy21;
>>                         coeff[0] = lastY;
>> 
>>                         deriv_coeff[0] = coeff[1];
>>                         deriv_coeff[1] = 2.0 * coeff[2];
>>                         deriv_coeff[2] = 3.0 * coeff[3];
>> 
>>                         int tExtremaCount = QuadCurve2D.solveQuadratic(deriv_coeff, tExtrema);
>>                         if (tExtremaCount > 0) {
>>                             // error condition = sum ( abs (coeff) ):
>>                             final double margin = Math.ulp(Math.abs(coeff[0])
>>                                     + Math.abs(coeff[1]) + Math.abs(coeff[2])
>>                                     + Math.abs(coeff[3]));
>> 
>>                             for (int i = 0; i < tExtremaCount; i++) {
>>                                 double t = tExtrema[i];
>>                                 if (t > 0.0 && t < 1.0) {
>>                                     double y = coeff[0] + t * (coeff[1] + t * (coeff[2] + t * coeff[3]));
>>                                     if (y - margin < topY) {
>>                                         topY = y - margin;
>>                                     }
>>                                     if (y + margin > bottomY) {
>>                                         bottomY = y + margin;
>>                                     }
>>                                 }
>>                             }
>>                         }
>>                     }
>>                     lastX = coords[4];
>>                     lastY = coords[5];
>>                     break;
>>                 case PathIterator.SEG_CLOSE:
>>                 default:
>>             }
>>         }
>
> Looks good, and it passes all the unit tests. I pushed an update with this code. (Although immediately after that I pushed a refactor for readability that you previously requested -- so the logic/margin is in the branch now but it looks a little different already...)

Here is the test result in marlin-math proving the margin condition is satisfied from small to huge cubic curves:
https://github.com/bourgesl/marlin-math/blob/main/results/findExtrema/jdk17-2021-11-14-edge-cubic.log
Inaccuracies are within margin ~ 0.5 proved.

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

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


From kcr at openjdk.java.net  Tue Nov 16 12:29:34 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 16 Nov 2021 12:29:34 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
In-Reply-To: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
References: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
Message-ID: <Uow-w8rvlHah1wU7bqJoS4TP2An-NxuN-vzLmN37_wY=.5cd193a1-87ed-4148-a1da-5d7883d7c84e@github.com>

On Mon, 15 Nov 2021 15:50:39 GMT, kabutz <duke at openjdk.java.net> wrote:

> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
> 
> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3.  Fibonacci 100 million is a 347084 bit number.
> 
> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
> 
> 
> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
> BigIntegerParallelMultiply.multiply            1000000    ss    4     68,043 ?   25,317  ms/op
> BigIntegerParallelMultiply.multiply           10000000    ss    4   1073,095 ?  125,296  ms/op
> BigIntegerParallelMultiply.multiply          100000000    ss    4  25317,535 ? 5806,205  ms/op
> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     56,552 ?   22,368  ms/op
> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    536,193 ?   37,393  ms/op
> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9274,657 ?  826,197  ms/op

This PR mistakenly includes commits from another in-progress PR.

You need to remove these stray commits or else close this PR, create a new branch without them, and resubmit.

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

Changes requested by kcr (Author).

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


From duke at openjdk.java.net  Tue Nov 16 12:33:04 2021
From: duke at openjdk.java.net (kabutz)
Date: Tue, 16 Nov 2021 12:33:04 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v2]
In-Reply-To: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
References: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
Message-ID: <dT_JRl0iEpcqhPk2vUx1DfWHLIc3C7hMQPGiM_bmfxQ=.b335b65e-ac39-4731-9f49-e4786434f49b@github.com>

> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
> 
> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3.  Fibonacci 100 million is a 347084 bit number.
> 
> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
> 
> 
> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
> BigIntegerParallelMultiply.multiply            1000000    ss    4     68,043 ?   25,317  ms/op
> BigIntegerParallelMultiply.multiply           10000000    ss    4   1073,095 ?  125,296  ms/op
> BigIntegerParallelMultiply.multiply          100000000    ss    4  25317,535 ? 5806,205  ms/op
> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     56,552 ?   22,368  ms/op
> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    536,193 ?   37,393  ms/op
> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9274,657 ?  826,197  ms/op

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

 - Merge branch 'openjdk:master' into parallel-bigInteger
 - Update comments
 - Added parallelMultiply() method to BigInteger to allow large multiplications to run in parallel
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'origin/master'
 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
   
   Addressing some of Laurent's code review recommendations/comments:
   
   1. use the convention t for the parametric variable x(t),y(t)
   2. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
   3. always use braces for x = (a < b) ? ...
   4. always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)
   
   (There are two additional recommendations not in this commit that I'll ask about shortly.)
   
   See https://github.com/openjdk/jdk/pull/6227#issuecomment-959757954
 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
   
   The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
   A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
   B. Updating the unit test to forgive the discrepancy.
   
   I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
   
   This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6391/files
  - new: https://git.openjdk.java.net/jdk/pull/6391/files/eac09f15..03be5518

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

  Stats: 24162 lines in 218 files changed: 17701 ins; 2440 del; 4021 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6391.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6391/head:pull/6391

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


From kcr at openjdk.java.net  Tue Nov 16 12:33:06 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 16 Nov 2021 12:33:06 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
In-Reply-To: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
References: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
Message-ID: <6ETPRlAylc4gwtVouDkgDEIAsnjYNRJo-e93hq-Bi8U=.51ac85cd-4c25-4516-88c9-bac42ee81871@github.com>

On Mon, 15 Nov 2021 15:50:39 GMT, kabutz <duke at openjdk.java.net> wrote:

> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
> 
> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3.  Fibonacci 100 million is a 347084 bit number.
> 
> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
> 
> 
> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
> BigIntegerParallelMultiply.multiply            1000000    ss    4     68,043 ?   25,317  ms/op
> BigIntegerParallelMultiply.multiply           10000000    ss    4   1073,095 ?  125,296  ms/op
> BigIntegerParallelMultiply.multiply          100000000    ss    4  25317,535 ? 5806,205  ms/op
> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     56,552 ?   22,368  ms/op
> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    536,193 ?   37,393  ms/op
> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9274,657 ?  826,197  ms/op

Additionally, you should probably discuss new functionality such as this on the appropriate mailing list, `core-libs-dev at openjdk.java.net` in this case.

Finally, this will need a CSR if it is to proceed.

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

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


From duke at openjdk.java.net  Tue Nov 16 12:42:10 2021
From: duke at openjdk.java.net (kabutz)
Date: Tue, 16 Nov 2021 12:42:10 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v3]
In-Reply-To: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
References: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
Message-ID: <CusmzNrGE0zgHbyMXVRkhMjbft7r2ugEadBLDE0jznw=.a1dd5484-df89-420d-ad66-f0731a2162f3@github.com>

> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
> 
> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3.  Fibonacci 100 million is a 347084 bit number.
> 
> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
> 
> 
> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
> BigIntegerParallelMultiply.multiply            1000000    ss    4     68,043 ?   25,317  ms/op
> BigIntegerParallelMultiply.multiply           10000000    ss    4   1073,095 ?  125,296  ms/op
> BigIntegerParallelMultiply.multiply          100000000    ss    4  25317,535 ? 5806,205  ms/op
> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     56,552 ?   22,368  ms/op
> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    536,193 ?   37,393  ms/op
> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9274,657 ?  826,197  ms/op

kabutz 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:

 - 8277119: Add asserts in GenericTaskQueueSet methods
   
   Reviewed-by: tschatzl
 - 8274757: Cleanup unnecessary calls to Throwable.initCause() in java.management module
   
   Reviewed-by: dfuchs, sspitsyn
 - 8274662: Replace 'while' cycles with iterator with enhanced-for in jdk.hotspot.agent
   
   Reviewed-by: amenkov, cjplummer, sspitsyn
 - 8274163: Use String.equals instead of String.compareTo in jdk.jcmd
   
   Reviewed-by: cjplummer, amenkov, sspitsyn
 - 8274190: Use String.equals instead of String.compareTo in jdk.internal.jvmstat
   
   Reviewed-by: cjplummer, sspitsyn
 - 8274168: Avoid String.compareTo == 0 to check String equality in java.management
   
   Reviewed-by: sspitsyn, dfuchs, cjplummer, dholmes
 - 8274261: Use enhanced-for instead of plain 'for' in jdk.jcmd
   
   Reviewed-by: sspitsyn, cjplummer
 - Update comments
 - Added parallelMultiply() method to BigInteger to allow large multiplications to run in parallel
 - Merge branch 'openjdk:master' into master
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/744e9e8e...0075f04d

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6391/files
  - new: https://git.openjdk.java.net/jdk/pull/6391/files/03be5518..0075f04d

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

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

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


From duke at openjdk.java.net  Tue Nov 16 12:48:03 2021
From: duke at openjdk.java.net (kabutz)
Date: Tue, 16 Nov 2021 12:48:03 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v4]
In-Reply-To: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
References: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
Message-ID: <4X_4ikmPoRB3UHdYPLcAH9mycnN2IMJHYtySJsYLJzg=.fbbc6ff3-a4f0-4390-a0f6-7b7f28806f10@github.com>

> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
> 
> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3.  Fibonacci 100 million is a 347084 bit number.
> 
> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
> 
> 
> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
> BigIntegerParallelMultiply.multiply            1000000    ss    4     68,043 ?   25,317  ms/op
> BigIntegerParallelMultiply.multiply           10000000    ss    4   1073,095 ?  125,296  ms/op
> BigIntegerParallelMultiply.multiply          100000000    ss    4  25317,535 ? 5806,205  ms/op
> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     56,552 ?   22,368  ms/op
> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    536,193 ?   37,393  ms/op
> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9274,657 ?  826,197  ms/op

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

 - Update comments
 - Added parallelMultiply() method to BigInteger to allow large multiplications to run in parallel
 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
   
   Addressing some of Laurent's code review recommendations/comments:
   
   1. use the convention t for the parametric variable x(t),y(t)
   2. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
   3. always use braces for x = (a < b) ? ...
   4. always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)
   
   (There are two additional recommendations not in this commit that I'll ask about shortly.)
   
   See https://github.com/openjdk/jdk/pull/6227#issuecomment-959757954
 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
   
   The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
   A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
   B. Updating the unit test to forgive the discrepancy.
   
   I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
   
   This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

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

Changes: https://git.openjdk.java.net/jdk/pull/6391/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6391&range=03
  Stats: 731 lines in 8 files changed: 565 ins; 136 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6391.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6391/head:pull/6391

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


From kcr at openjdk.java.net  Tue Nov 16 13:07:55 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 16 Nov 2021 13:07:55 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v4]
In-Reply-To: <4X_4ikmPoRB3UHdYPLcAH9mycnN2IMJHYtySJsYLJzg=.fbbc6ff3-a4f0-4390-a0f6-7b7f28806f10@github.com>
References: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
 <4X_4ikmPoRB3UHdYPLcAH9mycnN2IMJHYtySJsYLJzg=.fbbc6ff3-a4f0-4390-a0f6-7b7f28806f10@github.com>
Message-ID: <pugnX_Ju-Q_ViIrsYhIaz348o7ZUc35ZJWzsvvJQOmM=.6530d6e6-2ffe-40d9-b86f-6c4d4779b72c@github.com>

On Tue, 16 Nov 2021 12:48:03 GMT, kabutz <duke at openjdk.java.net> wrote:

>> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
>> 
>> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3.  Fibonacci 100 million is a 347084 bit number.
>> 
>> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
>> 
>> 
>> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
>> BigIntegerParallelMultiply.multiply            1000000    ss    4     68,043 ?   25,317  ms/op
>> BigIntegerParallelMultiply.multiply           10000000    ss    4   1073,095 ?  125,296  ms/op
>> BigIntegerParallelMultiply.multiply          100000000    ss    4  25317,535 ? 5806,205  ms/op
>> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     56,552 ?   22,368  ms/op
>> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    536,193 ?   37,393  ms/op
>> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9274,657 ?  826,197  ms/op
>
> kabutz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Update comments
>  - Added parallelMultiply() method to BigInteger to allow large multiplications to run in parallel
>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>    
>    Addressing some of Laurent's code review recommendations/comments:
>    
>    1. use the convention t for the parametric variable x(t),y(t)
>    2. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
>    3. always use braces for x = (a < b) ? ...
>    4. always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)
>    
>    (There are two additional recommendations not in this commit that I'll ask about shortly.)
>    
>    See https://github.com/openjdk/jdk/pull/6227#issuecomment-959757954
>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>    
>    The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>    A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>    B. Updating the unit test to forgive the discrepancy.
>    
>    I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>    
>    This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

You still have the extra unwanted commits in your branch.

Normally you should not force push to your branch once a review is started, but in this case the only other choice would be to abandon this PR and create a new one.

Regardless of whether you close this PR and create a new one or continue with this PR, you should rebase your branch on top of the latest jdk master such that there is only a single commit with the changes you are proposing. It should _not_ touch any files from `java.desktop`.

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

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


From duke at openjdk.java.net  Tue Nov 16 13:07:58 2021
From: duke at openjdk.java.net (kabutz)
Date: Tue, 16 Nov 2021 13:07:58 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v4]
In-Reply-To: <4X_4ikmPoRB3UHdYPLcAH9mycnN2IMJHYtySJsYLJzg=.fbbc6ff3-a4f0-4390-a0f6-7b7f28806f10@github.com>
References: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
 <4X_4ikmPoRB3UHdYPLcAH9mycnN2IMJHYtySJsYLJzg=.fbbc6ff3-a4f0-4390-a0f6-7b7f28806f10@github.com>
Message-ID: <Pa63ncizBN1jtY8pZyk5jyBKb9RcozW1xNmu18yhmIs=.a7d6ca32-8886-4cb3-99cf-bb7777066888@github.com>

On Tue, 16 Nov 2021 12:48:03 GMT, kabutz <duke at openjdk.java.net> wrote:

>> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
>> 
>> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3.  Fibonacci 100 million is a 347084 bit number.
>> 
>> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
>> 
>> 
>> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
>> BigIntegerParallelMultiply.multiply            1000000    ss    4     68,043 ?   25,317  ms/op
>> BigIntegerParallelMultiply.multiply           10000000    ss    4   1073,095 ?  125,296  ms/op
>> BigIntegerParallelMultiply.multiply          100000000    ss    4  25317,535 ? 5806,205  ms/op
>> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     56,552 ?   22,368  ms/op
>> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    536,193 ?   37,393  ms/op
>> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9274,657 ?  826,197  ms/op
>
> kabutz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Update comments
>  - Added parallelMultiply() method to BigInteger to allow large multiplications to run in parallel
>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>    
>    Addressing some of Laurent's code review recommendations/comments:
>    
>    1. use the convention t for the parametric variable x(t),y(t)
>    2. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
>    3. always use braces for x = (a < b) ? ...
>    4. always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)
>    
>    (There are two additional recommendations not in this commit that I'll ask about shortly.)
>    
>    See https://github.com/openjdk/jdk/pull/6227#issuecomment-959757954
>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>    
>    The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>    A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>    B. Updating the unit test to forgive the discrepancy.
>    
>    I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>    
>    This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

Thanks Kevin, let me start again!

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

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


From duke at openjdk.java.net  Tue Nov 16 13:07:59 2021
From: duke at openjdk.java.net (kabutz)
Date: Tue, 16 Nov 2021 13:07:59 GMT
Subject: Withdrawn: JDK-8277175 : Add a parallel multiply method to BigInteger
In-Reply-To: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
References: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
Message-ID: <0Cf0GjEgY3DDBWyvWb-EFWKbv9xkokdbVk7le9j-1kc=.e566823e-f549-40ad-927e-4578e8c96623@github.com>

On Mon, 15 Nov 2021 15:50:39 GMT, kabutz <duke at openjdk.java.net> wrote:

> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
> 
> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3.  Fibonacci 100 million is a 347084 bit number.
> 
> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
> 
> 
> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
> BigIntegerParallelMultiply.multiply            1000000    ss    4     68,043 ?   25,317  ms/op
> BigIntegerParallelMultiply.multiply           10000000    ss    4   1073,095 ?  125,296  ms/op
> BigIntegerParallelMultiply.multiply          100000000    ss    4  25317,535 ? 5806,205  ms/op
> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     56,552 ?   22,368  ms/op
> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    536,193 ?   37,393  ms/op
> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9274,657 ?  826,197  ms/op

This pull request has been closed without being integrated.

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

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


From jdv at openjdk.java.net  Tue Nov 16 13:22:40 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 16 Nov 2021 13:22:40 GMT
Subject: Integrated: 8276905: Use appropriate macosx_version_minimum value
 while compiling metal shaders
In-Reply-To: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
References: <_OkC1YeToScvoDOBBhAZfQHSao_fjjsnw60prsCsWtE=.6ea0dbc2-0270-4caa-bcfc-baa7cb704365@github.com>
Message-ID: <NPQeYpt3zbxlBtpsUtrcuntG5DtbQAExnwk6E60x1HM=.f0f3e256-c696-48ec-8600-b4dd6ed735f9@github.com>

On Thu, 11 Nov 2021 05:52:18 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal".
> 
> Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline.
> 
> SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue.

This pull request has now been integrated.

Changeset: 9a9a157a
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9a9a157a7d45cbfb016d4427931e1d5345210f7a
Stats:     16 lines in 1 file changed: 15 ins; 0 del; 1 mod

8276905: Use appropriate macosx_version_minimum value while compiling metal shaders

Reviewed-by: ihse, kcr, erikj, prr

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

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


From duke at openjdk.java.net  Tue Nov 16 13:27:39 2021
From: duke at openjdk.java.net (kabutz)
Date: Tue, 16 Nov 2021 13:27:39 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v4]
In-Reply-To: <4X_4ikmPoRB3UHdYPLcAH9mycnN2IMJHYtySJsYLJzg=.fbbc6ff3-a4f0-4390-a0f6-7b7f28806f10@github.com>
References: <tbvD-agoLHKdWhaXKcXwAZxlXK3XmUvhQpAXZaTK3HY=.89ecad2f-629d-4f17-bc82-b64143f9c2a5@github.com>
 <4X_4ikmPoRB3UHdYPLcAH9mycnN2IMJHYtySJsYLJzg=.fbbc6ff3-a4f0-4390-a0f6-7b7f28806f10@github.com>
Message-ID: <tfgtnkRfLI1o8Ne4GGD-z7dCX7BzfAFlbQikrSofDfg=.93a0dc84-b448-4c9c-b908-a3031e9f0901@github.com>

On Tue, 16 Nov 2021 12:48:03 GMT, kabutz <duke at openjdk.java.net> wrote:

>> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
>> 
>> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3.  Fibonacci 100 million is a 347084 bit number.
>> 
>> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
>> 
>> 
>> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
>> BigIntegerParallelMultiply.multiply            1000000    ss    4     68,043 ?   25,317  ms/op
>> BigIntegerParallelMultiply.multiply           10000000    ss    4   1073,095 ?  125,296  ms/op
>> BigIntegerParallelMultiply.multiply          100000000    ss    4  25317,535 ? 5806,205  ms/op
>> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     56,552 ?   22,368  ms/op
>> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    536,193 ?   37,393  ms/op
>> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9274,657 ?  826,197  ms/op
>
> kabutz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Update comments
>  - Added parallelMultiply() method to BigInteger to allow large multiplications to run in parallel
>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>    
>    Addressing some of Laurent's code review recommendations/comments:
>    
>    1. use the convention t for the parametric variable x(t),y(t)
>    2. solve the quadratic equation using QuadCurve2d.solveQuadratic() or like Helpers.quadraticRoots()
>    3. always use braces for x = (a < b) ? ...
>    4. always use double-precision constants in math or logical operations: (2 * x => 2.0 * x) and (coefficients[3] != 0) => (coefficients[3] != 0.0)
>    
>    (There are two additional recommendations not in this commit that I'll ask about shortly.)
>    
>    See https://github.com/openjdk/jdk/pull/6227#issuecomment-959757954
>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>    
>    The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>    A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>    B. Updating the unit test to forgive the discrepancy.
>    
>    I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>    
>    This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

Resubmitted as PR https://github.com/openjdk/jdk/pull/6409/

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

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


From kizune at openjdk.java.net  Tue Nov 16 19:06:00 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 16 Nov 2021 19:06:00 GMT
Subject: RFR: 8169468: NoResizeEventOnDMChangeTest.java fails because FS
 Window didn't receive all resizes! [v4]
In-Reply-To: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
References: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
Message-ID: <64xGA14-maYsJwzPq2-2-AZTCiLy2stRCwwH-wCF9B8=.d601757c-304b-46b8-92da-992cf785cdcb@github.com>

> I was able to reproduce this issue locally 2 times out of 100 runs on multi-monitor
> configuration. Both times due to the screen resolution change is so slow window got
> accidentally moved to the secondary screen by the display driver.
> Can not reproduce this bug with ATI card at all.
> Since there is nothing we can do to stop graphics driver from reassigning
> the window if it decides that promary monitor is not on at the moment the
> only way is to check if this has had happened and if so then we can not trust the test
> since we changing resolution of one display and window not getting resized
> because it is placed on another display and test should be skept.
> 
> After that i ran this test locally about a thousand times on all platforms
> and has not seen the failure again.

Alexander Zuev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Resolve merge conflicts
 - Merge branch 'master' into JDK-8169468
 - Resolve merge conflict
 - Added speel for 2 seconds after setting new display mode.
   Removed unneeded imports.
 - Check that setting the new display mode ended up with window
   residing on the screen with resolution different than one it was before,
   even if it the different display - window and components still have to
   receive the resize event. Only skipping the iteration where that did not
   happened instead of skipping the entire test.
 - 8169468: NoResizeEventOnDMChangeTest.java fails because FS Window didn't receive all resizes!
   
   Made sleep() method always sleep at least the requested amount
   Checking if window got accidentally reassigned to another graphics device,
   skipping test if so.
   Removed test from the problem list.

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

Changes: https://git.openjdk.java.net/jdk/pull/6186/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6186&range=03
  Stats: 26 lines in 2 files changed: 18 ins; 2 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6186.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6186/head:pull/6186

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


From kizune at openjdk.java.net  Tue Nov 16 19:06:01 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 16 Nov 2021 19:06:01 GMT
Subject: Integrated: 8169468: NoResizeEventOnDMChangeTest.java fails because FS
 Window didn't receive all resizes!
In-Reply-To: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
References: <by15ZHAIitToadLYhIgmuEBqcJjXL7MI81n5hXJwzDE=.a0e5e93e-ea7b-4f46-bdc5-f6001588b3d4@github.com>
Message-ID: <SwDkreuTWvLpVvD5XQCyFZxekd4fc9Pu195uWmCIDX4=.59097e38-25cb-479b-8d52-5ae2739e165c@github.com>

On Mon, 1 Nov 2021 11:35:24 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> I was able to reproduce this issue locally 2 times out of 100 runs on multi-monitor
> configuration. Both times due to the screen resolution change is so slow window got
> accidentally moved to the secondary screen by the display driver.
> Can not reproduce this bug with ATI card at all.
> Since there is nothing we can do to stop graphics driver from reassigning
> the window if it decides that promary monitor is not on at the moment the
> only way is to check if this has had happened and if so then we can not trust the test
> since we changing resolution of one display and window not getting resized
> because it is placed on another display and test should be skept.
> 
> After that i ran this test locally about a thousand times on all platforms
> and has not seen the failure again.

This pull request has now been integrated.

Changeset: b0a463fa
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b0a463fa59a1c3c554f48267525729bf89a2c5be
Stats:     26 lines in 2 files changed: 18 ins; 2 del; 6 mod

8169468: NoResizeEventOnDMChangeTest.java fails because FS Window didn't receive all resizes!

Reviewed-by: serb

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

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


From achung at openjdk.java.net  Tue Nov 16 21:50:40 2021
From: achung at openjdk.java.net (Alisen Chung)
Date: Tue, 16 Nov 2021 21:50:40 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v3]
In-Reply-To: <QU3ZR8euhuq1lR4Y56LIKVkDzwxKm69ANvsNK9huCvg=.77568628-c221-4f79-b6c0-2a741a4fa130@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <QU3ZR8euhuq1lR4Y56LIKVkDzwxKm69ANvsNK9huCvg=.77568628-c221-4f79-b6c0-2a741a4fa130@github.com>
Message-ID: <B6Ws5D6oyKOLU9qIToeyzLbDnRu3k--IRWOSX_x3mBA=.9534cf1b-e47a-4dd7-a73d-828c55d58fa6@github.com>

On Mon, 15 Nov 2021 17:33:09 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removed trailing whitespace
>  - test change

@prrace @azuev-java please review

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

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


From kizune at openjdk.java.net  Wed Nov 17 00:04:02 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 17 Nov 2021 00:04:02 GMT
Subject: RFR: 8264293: Create implementation for NSAccessibilityMenu protocol
 peer
Message-ID: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>

Added implementation for all menu related protocol peers;
Native methods moved to CommonComponentAccessibility so they are called on correct peers;

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

Commit messages:
 - 8264293: Create implementation for NSAccessibilityMenu protocol peer

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

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


From vdyakov at openjdk.java.net  Wed Nov 17 00:15:32 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Wed, 17 Nov 2021 00:15:32 GMT
Subject: RFR: 8264293: Create implementation for NSAccessibilityMenu
 protocol peer
In-Reply-To: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
References: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
Message-ID: <8KERZY7KBsVylZUmKZOwH0PX2h4BKjrSjceZy3mVBPA=.3a0c1939-97e6-4fdc-9ad8-0d398ea4ba21@github.com>

On Tue, 16 Nov 2021 23:53:53 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Added implementation for all menu related protocol peers;
> Native methods moved to CommonComponentAccessibility so they are called on correct peers;

@pankaj-bansal please review

@forantar please review

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

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


From kizune at openjdk.java.net  Wed Nov 17 01:06:00 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 17 Nov 2021 01:06:00 GMT
Subject: RFR: 8275071: [macos] A11y cursor gets stuck when combobox is closed
Message-ID: <Sz1qsgCQB6aPmVXTjnHsRKkQO60-8yyWrOZxVJFuFh0=.86498ac7-a0fa-43a1-a59c-2e9e69a7ac97@github.com>

Before the new JList accessibility peer implementation sending popup closed
event to the combobox popup could trigger the native memory access error due
to the events arriving in the wrong order. After new implementation is done
it is no longer the case and this workaround needs to be removed.

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

Commit messages:
 - 8275071: [macos] A11y cursor gets stuck when combobox is closed

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

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


From jdv at openjdk.java.net  Wed Nov 17 03:26:42 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 17 Nov 2021 03:26:42 GMT
Subject: RFR: 8270874: JFrame paint artifacts when dragged from standard
 monitor to HiDPI monitor
In-Reply-To: <hPV-NYDHAMhyOviuU89e9Frm1ALNGqn_Uw0i4NDscRE=.e3fcd015-0bc5-4e7a-92f0-8474ee8af548@github.com>
References: <hPV-NYDHAMhyOviuU89e9Frm1ALNGqn_Uw0i4NDscRE=.e3fcd015-0bc5-4e7a-92f0-8474ee8af548@github.com>
Message-ID: <BXZuXTQYBtOhqE3D5C0wDKQSDp9D2B5UX5KS8AzHhjU=.920a6b83-fc7a-42fc-ad00-15de1fc4b146@github.com>

On Wed, 10 Nov 2021 18:45:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The bug occurs more often if initially the window is moved partly outside of the first screen(let's name this part as the invisible part), and then slowly moved to the second screen where that invisible part became visible on the second screen.
> 
> The problem is how we try to repaint the frame. The Windows send us coordinates to repaint in the device space, if the width/height values are less than a unit in the user's space, we round it to the empty rectangle and skip it.
> 
> Solution: request to repaint the smallest non-empty bounding box in the user's space around the region of pixels.
> 
> Workaround: repaint the whole window on the component resize/move event or at the end of the drag.
> 
> Notes:
>  * It is not reproducible(at least much less often) when d3d is enabled because the d3d pipeline sends repaint events more often (example https://github.com/openjdk/jdk/pull/6064). That hides the current issue.
>  * It started to be reproducible during the drag from one screen to another after JDK-8211999 because before JDK-8211999 we make a resize at the end of the drag, which caused the full repaint of the window.

Marked as reviewed by jdv (Reviewer).

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

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


From jdv at openjdk.java.net  Wed Nov 17 03:26:43 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 17 Nov 2021 03:26:43 GMT
Subject: RFR: 8270874: JFrame paint artifacts when dragged from standard
 monitor to HiDPI monitor
In-Reply-To: <q7Xo4e_E1h_qpGelzXie8AMV1f3oi-hQysdCsUgy3x8=.08c4e8d6-e270-4e42-b46a-639466088c6d@github.com>
References: <hPV-NYDHAMhyOviuU89e9Frm1ALNGqn_Uw0i4NDscRE=.e3fcd015-0bc5-4e7a-92f0-8474ee8af548@github.com>
 <8f93oLv4_N0vNlmfkvXQrju73GxBjyD1LW-d06poJus=.7dd8b1ef-2771-4709-b06f-1c5ef649d8de@github.com>
 <q7Xo4e_E1h_qpGelzXie8AMV1f3oi-hQysdCsUgy3x8=.08c4e8d6-e270-4e42-b46a-639466088c6d@github.com>
Message-ID: <CTcHkGGd0MbPS6MeSXhEE4VPMhISnMnLIzGcDO0dK2o=.af9e4c20-c28b-4d46-a746-8098d38abd24@github.com>

On Tue, 16 Nov 2021 07:53:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Please correct my understanding. Does this refined repaint logic apply even for overlapping Windows? What happens when 2 windows are overlapping and we move top window slowly? Any performance/power impact?
> 
> Initially, this code was used just for that, to make a fast blit of the content from the Swing back buffer to the native window, when some other window is moved over the Swing and damaged it (the fix for the "grey rectangle" JDK-4967886). But since Windows Vista the Windows itself maintain such doublebuffer and the content is not damaged when windows overlap, so this callback is not called.

Thanks for the clarification

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

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


From serb at openjdk.java.net  Wed Nov 17 03:51:35 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 17 Nov 2021 03:51:35 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v3]
In-Reply-To: <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
Message-ID: <3rXgfSZQ4Ow0iIwsurYZH3C5ApsrE3lCdGWmTNex0js=.c80568cc-267a-44fc-bf66-6e34cf894b05@github.com>

On Fri, 29 Oct 2021 06:43:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review fix
>  - Fix

ok, it is up to you.

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

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


From pbansal at openjdk.java.net  Wed Nov 17 06:45:35 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 17 Nov 2021 06:45:35 GMT
Subject: RFR: 8264293: Create implementation for NSAccessibilityMenu
 protocol peer
In-Reply-To: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
References: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
Message-ID: <jAuNG5IT-PcclbtGy2uzCqGAl2P1MzbobEqIqnOKLtY=.f580010e-cf9c-4954-a465-cdc07ad540d6@github.com>

On Tue, 16 Nov 2021 23:53:53 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Added implementation for all menu related protocol peers;
> Native methods moved to CommonComponentAccessibility so they are called on correct peers;

Looks good to me. Menu Accessibility works fine with these changes.

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

Marked as reviewed by pbansal (Reviewer).

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


From myano at openjdk.java.net  Wed Nov 17 08:16:42 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 17 Nov 2021 08:16:42 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <2rBhm1b2wZwnJFYIve6hdNLHFE0iAkGbj1GkDkSOUCs=.726e6e6a-76b6-4657-b44b-dd854769055c@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <-hj0v7RZ0HPpP9GND5csZsZ1Vz7oxaufOAC0-ZygtwM=.6a5ae7a8-52d6-4e3e-a166-2fae2c23dbe0@github.com>
 <cTqTWZsK6uJI_Kw9nUymKQnYxxzWBRrk52qJAKpAc9I=.18f7dffd-3ebe-4bd0-bc2f-d61b55437036@github.com>
 <aZX6pJkrGOTYLlAHRl9WlEGtoahiInx4QzelDWpV2b0=.c9a736f9-5dd5-4382-8513-94a0233105dc@github.com>
 <QPyLlBXqr80h-_OjGxuv6tGNl8_-IZ8IHF-_8QWy894=.b18fd0a2-4497-4aae-87b1-1570531f2862@github.com>
 <2rBhm1b2wZwnJFYIve6hdNLHFE0iAkGbj1GkDkSOUCs=.726e6e6a-76b6-4657-b44b-dd854769055c@github.com>
Message-ID: <k1gQRfQhMEC2tFwq5ZyyEmfebNqR6Mws651ijtdhTc8=.57c33d5c-9b6e-4b6c-9f4b-0afae0d0615f@github.com>

On Sun, 14 Nov 2021 05:55:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @mrserb How long will it take to review this fix?
>
> I suggest leaving it as is for some time, since it is known that could workaround another bug, linked below.

@mrserb Can I hope this fix will be integrated after JDK-8270874 is fixed?

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

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


From duke at openjdk.java.net  Wed Nov 17 08:53:07 2021
From: duke at openjdk.java.net (Jeremy)
Date: Wed, 17 Nov 2021 08:53:07 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v9]
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <2y_kzHqARE6UR805mdKhGmdTDXs3LFV3ogko9YZBc14=.cee9bb93-58a0-461a-82e7-2d8350b3a382@github.com>

> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
> 
> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
> B. Updating the unit test to forgive the discrepancy.
> 
> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
> 
> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
> 
> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

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

  8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
  
  Addressing code review feedback: "I would prefer having accumulate functions called twice (using offset)"
  
  https://github.com/openjdk/jdk/pull/6227#issuecomment-970040098

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6227/files
  - new: https://git.openjdk.java.net/jdk/pull/6227/files/0e2b5293..b3e84a5e

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

  Stats: 109 lines in 2 files changed: 15 ins; 16 del; 78 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6227.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6227/head:pull/6227

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


From duke at openjdk.java.net  Wed Nov 17 08:53:10 2021
From: duke at openjdk.java.net (Jeremy)
Date: Wed, 17 Nov 2021 08:53:10 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v8]
In-Reply-To: <4YC95pXalYpZo0m0eB_TKkVO4gDMebj7og2MM9O7104=.69f6d3c9-c475-4d16-a006-45907e4765d3@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <4YC95pXalYpZo0m0eB_TKkVO4gDMebj7og2MM9O7104=.69f6d3c9-c475-4d16-a006-45907e4765d3@github.com>
Message-ID: <lrPnFg1QjT-fWNSkNlDh1BICnrjUFu1HCyOdLDWhxeY=.b303dc68-1a46-4634-841b-5fbba6d393d1@github.com>

On Tue, 16 Nov 2021 04:46:07 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>    
>    This is broadly addresses the code review feedback: "I see many duplicated lines". This commit does NOT include "the previous unified solution" that is also mentioned... so we'll try this on and see how we feel about it.
>    
>    https://github.com/openjdk/jdk/pull/6227#issuecomment-964020449
>  - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>    
>    Applying Laurent's implementation to address machine error.
>    
>    See https://github.com/openjdk/jdk/pull/6227#discussion_r749672090

OK, I refactored the accumulate methods so they're called twice (once for each dimension). What array allocation are you referring to?

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

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


From asemenov at openjdk.java.net  Wed Nov 17 09:55:36 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Wed, 17 Nov 2021 09:55:36 GMT
Subject: RFR: 8264293: Create implementation for NSAccessibilityMenu
 protocol peer
In-Reply-To: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
References: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
Message-ID: <GfWwH3Rl5__z5wUJRMKMFHi1jHVOoqQv_OtyzYqBfxQ=.003f0140-42a3-4b75-af62-bd97fa7b1ca6@github.com>

On Tue, 16 Nov 2021 23:53:53 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Added implementation for all menu related protocol peers;
> Native methods moved to CommonComponentAccessibility so they are called on correct peers;

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

> 153:     [rolesMap setObject:@"OutlineAccessibility" forKey:@"tree"];
> 154:     [rolesMap setObject:@"TableAccessibility" forKey:@"table"];
> 155:     [rolesMap setObject:@"MenuBarAccessibility" forKey:@"menubar"];

Please increase the capacity of the rolesMap dictionary if you add a new role.

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

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


From ant at openjdk.java.net  Wed Nov 17 10:01:35 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Wed, 17 Nov 2021 10:01:35 GMT
Subject: RFR: 8264293: Create implementation for NSAccessibilityMenu
 protocol peer
In-Reply-To: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
References: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
Message-ID: <GtMPKOMMkcR_Ic1_YI9u7ijI-XB47831cWVwkjEUAb8=.4c6ad500-b98e-4d33-b40e-f34593fcb6af@github.com>

On Tue, 16 Nov 2021 23:53:53 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Added implementation for all menu related protocol peers;
> Native methods moved to CommonComponentAccessibility so they are called on correct peers;

Besides what @savoptik mentioned, I left only cosmetics comments. Overall looks ok to me.

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 1272:

> 1270:     [ThreadUtilities performOnMainThread:@selector(postMenuOpened)
> 1271:         on:(CommonComponentAccessibility *)jlong_to_ptr(element)
> 1272:         withObject:nil waitUntilDone:NO];

Please move `waitUntilDone` to the new line for consistency.

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.m line 35:

> 33: - (NSAccessibilityRole _Nonnull)accessibilityRole
> 34: {
> 35:         return [[[self parent] javaRole] isEqualToString:@"combobox"]

Please correct the indentation.

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

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


From lbourges at openjdk.java.net  Wed Nov 17 10:56:36 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 17 Nov 2021 10:56:36 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v9]
In-Reply-To: <2y_kzHqARE6UR805mdKhGmdTDXs3LFV3ogko9YZBc14=.cee9bb93-58a0-461a-82e7-2d8350b3a382@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <2y_kzHqARE6UR805mdKhGmdTDXs3LFV3ogko9YZBc14=.cee9bb93-58a0-461a-82e7-2d8350b3a382@github.com>
Message-ID: <oTYbA7S_RFt10MM7R4SudJ-9kHN9qjI7Z-fxnDpm03g=.d6b015d3-eb2e-4e2e-8ef0-3fd534239222@github.com>

On Wed, 17 Nov 2021 08:53:07 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   Addressing code review feedback: "I would prefer having accumulate functions called twice (using offset)"
>   
>   https://github.com/openjdk/jdk/pull/6227#issuecomment-970040098

You're right, no allocations made in accumulate() methods.
LGTM.
Congratulations !

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

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


From psadhukhan at openjdk.java.net  Wed Nov 17 13:32:36 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 17 Nov 2021 13:32:36 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v3]
In-Reply-To: <5gKSW29Ah7FkFKAqlcJxZekf1LYkHIVfY-C4rqfkmx4=.d0563bfc-de95-4726-a160-7cbdd22ceb66@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
 <5gKSW29Ah7FkFKAqlcJxZekf1LYkHIVfY-C4rqfkmx4=.d0563bfc-de95-4726-a160-7cbdd22ceb66@github.com>
Message-ID: <ZMRyILWuQQGX4uTsGvmjSdpbkGVpTL_WGZSYtAbKJRg=.3f1853c7-d19a-4018-a116-e7a329c85d01@github.com>

On Wed, 10 Nov 2021 05:47:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Review fix
>>  - Fix
>
> I don't see a reason to discard the various stability improvements.
> The discussion is long so I may not be summarising correctly but 
> - A product fix may resolve most of the issues and yet
> - Stability fixes are still valuable
> - The one test with a colour tolerance update may be better platform problem listed 
> - The offset of -10,-10 for the cursor maybe better if it was parameterised and a bit bigger.

@prrace Do you have any comments? If not, can you please approve?

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

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


From aivanov at openjdk.java.net  Wed Nov 17 14:54:37 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 17 Nov 2021 14:54:37 GMT
Subject: RFR: 8276794: Change nested classes in java.desktop to static
 nested classes
In-Reply-To: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
Message-ID: <usZ8Abd8HlU0tdT7MBFIw71TUOyvmvQ6RWlTrLumkH4=.f98b22c7-78ec-4c17-bbea-a8d9314b7b8d@github.com>

On Thu, 14 Oct 2021 07:47:33 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)

There are a couple of classes where a space before the opening brace in the class declaration can be added: you're changing the declaration anyway. By adding the space there, the declaration will follow Java Code Conventions.

In some cases, you're remove unused imports. Does it make sense to convert all wildcard imports into explicit imports? I noticed wildcards imports have been replaced with explicit ones in JDK source code recently.

I do not suggest changing the imports in all the modified classes, only those where imports are modified.

For example, you're removing redundant imports in `XTextFieldPeer.java`, there are quite a few of them. There are also lots of explicit imports in the file. I think expanding wildcard imports to explicit ones and sorting them will make the file cleaner.

Another example where such a change seems appropriate is `XTextAreaPeer.java` where Swing classes are imported class by class but `java.awt.*` by wildcard.

What do you think?

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java line 3949:

> 3947:     @SuppressWarnings("serial") // Superclass is not serializable across versions
> 3948:     private static class ScrollableTabButton extends BasicArrowButton implements UIResource,
> 3949:                                                                             SwingConstants {

Maybe, wrap the line before implements?

src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 2300:

> 2298: 
> 2299: @SuppressWarnings("serial") // JDK-implementation class
> 2300:  static class PrintToFileErrorDialog extends Dialog implements ActionListener{

There's an extra space before `static` modifier which breaks the common indentation.
I'd also add a space before the opening brace, it's there in the following code of the class.

src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java line 165:

> 163:      */
> 164:     @SuppressWarnings("serial") // JDK-implementation class
> 165:      static class ScrollEvent extends PeerEvent {

There's an extra space before `static` modifier. Is it intentional?

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

Marked as reviewed by aivanov (Reviewer).

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


From kizune at openjdk.java.net  Wed Nov 17 16:57:20 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 17 Nov 2021 16:57:20 GMT
Subject: RFR: 8264293: Create implementation for NSAccessibilityMenu
 protocol peer [v2]
In-Reply-To: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
References: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
Message-ID: <lEuESTA1JTr5zctuKGUUIU-p-6k9T9slkx8uLBKeOcg=.defe4e58-d094-47f1-8b37-6c0e717b544d@github.com>

> Added implementation for all menu related protocol peers;
> Native methods moved to CommonComponentAccessibility so they are called on correct peers;

Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:

 - Fixed parameters layout for better readeability;
 - Fixed indentation of native methods;
   Fixed initial capacity of rolesMap dictionary;

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6421/files
  - new: https://git.openjdk.java.net/jdk/pull/6421/files/264f8ee6..cedec290

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

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

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


From kizune at openjdk.java.net  Wed Nov 17 16:57:21 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 17 Nov 2021 16:57:21 GMT
Subject: RFR: 8264293: Create implementation for NSAccessibilityMenu
 protocol peer
In-Reply-To: <GtMPKOMMkcR_Ic1_YI9u7ijI-XB47831cWVwkjEUAb8=.4c6ad500-b98e-4d33-b40e-f34593fcb6af@github.com>
References: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
 <GtMPKOMMkcR_Ic1_YI9u7ijI-XB47831cWVwkjEUAb8=.4c6ad500-b98e-4d33-b40e-f34593fcb6af@github.com>
Message-ID: <k9rW35v49jXZqYJ_MgePSvMMA_tSpB5dk2feArpZpwc=.61581b32-cb06-4b21-839a-cfe56abbfd8e@github.com>

On Wed, 17 Nov 2021 09:58:14 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> Besides what @savoptik mentioned, I left only cosmetics comments. Overall looks ok to me.

Cosmetics are also important so i fixed them too.

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

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


From kizune at openjdk.java.net  Wed Nov 17 16:57:30 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 17 Nov 2021 16:57:30 GMT
Subject: RFR: 8264293: Create implementation for NSAccessibilityMenu
 protocol peer [v2]
In-Reply-To: <GtMPKOMMkcR_Ic1_YI9u7ijI-XB47831cWVwkjEUAb8=.4c6ad500-b98e-4d33-b40e-f34593fcb6af@github.com>
References: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
 <GtMPKOMMkcR_Ic1_YI9u7ijI-XB47831cWVwkjEUAb8=.4c6ad500-b98e-4d33-b40e-f34593fcb6af@github.com>
Message-ID: <4_3ZMmm25SnljICZw7arGn0wVKnMDC2I3IbOe8sGUA4=.dd67c3ad-d105-4528-be44-fd6a67b01757@github.com>

On Wed, 17 Nov 2021 09:55:19 GMT, Anton Tarasov <ant at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fixed parameters layout for better readeability;
>>  - Fixed indentation of native methods;
>>    Fixed initial capacity of rolesMap dictionary;
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 1272:
> 
>> 1270:     [ThreadUtilities performOnMainThread:@selector(postMenuOpened)
>> 1271:         on:(CommonComponentAccessibility *)jlong_to_ptr(element)
>> 1272:         withObject:nil waitUntilDone:NO];
> 
> Please move `waitUntilDone` to the new line for consistency.

Fixed.

> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.m line 35:
> 
>> 33: - (NSAccessibilityRole _Nonnull)accessibilityRole
>> 34: {
>> 35:         return [[[self parent] javaRole] isEqualToString:@"combobox"]
> 
> Please correct the indentation.

Fixed.

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

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


From kizune at openjdk.java.net  Wed Nov 17 16:57:26 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 17 Nov 2021 16:57:26 GMT
Subject: RFR: 8264293: Create implementation for NSAccessibilityMenu
 protocol peer [v2]
In-Reply-To: <GfWwH3Rl5__z5wUJRMKMFHi1jHVOoqQv_OtyzYqBfxQ=.003f0140-42a3-4b75-af62-bd97fa7b1ca6@github.com>
References: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
 <GfWwH3Rl5__z5wUJRMKMFHi1jHVOoqQv_OtyzYqBfxQ=.003f0140-42a3-4b75-af62-bd97fa7b1ca6@github.com>
Message-ID: <8u_bpk_u1semRyWPAOc4SVdpcrGv0euy1xU5d6RKkGU=.740545c3-f674-40db-a698-ecf6d8103283@github.com>

On Wed, 17 Nov 2021 09:45:16 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fixed parameters layout for better readeability;
>>  - Fixed indentation of native methods;
>>    Fixed initial capacity of rolesMap dictionary;
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 155:
> 
>> 153:     [rolesMap setObject:@"OutlineAccessibility" forKey:@"tree"];
>> 154:     [rolesMap setObject:@"TableAccessibility" forKey:@"table"];
>> 155:     [rolesMap setObject:@"MenuBarAccessibility" forKey:@"menubar"];
> 
> Please increase the capacity of the rolesMap dictionary if you add a new role.

Fixed.

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

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


From ant at openjdk.java.net  Wed Nov 17 17:13:20 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Wed, 17 Nov 2021 17:13:20 GMT
Subject: RFR: 8264293: Create implementation for NSAccessibilityMenu
 protocol peer [v2]
In-Reply-To: <lEuESTA1JTr5zctuKGUUIU-p-6k9T9slkx8uLBKeOcg=.defe4e58-d094-47f1-8b37-6c0e717b544d@github.com>
References: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
 <lEuESTA1JTr5zctuKGUUIU-p-6k9T9slkx8uLBKeOcg=.defe4e58-d094-47f1-8b37-6c0e717b544d@github.com>
Message-ID: <MnhVdUn5b-hzjBMVSSjDIBw6I0HyxkKv2RQ8BcsVlSk=.3fbb2631-7cc0-4bdf-9fc1-5ff170da967c@github.com>

On Wed, 17 Nov 2021 16:57:20 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Added implementation for all menu related protocol peers;
>> Native methods moved to CommonComponentAccessibility so they are called on correct peers;
>
> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed parameters layout for better readeability;
>  - Fixed indentation of native methods;
>    Fixed initial capacity of rolesMap dictionary;

Marked as reviewed by ant (Reviewer).

Looks fine now.

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

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


From kizune at openjdk.java.net  Wed Nov 17 17:14:31 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 17 Nov 2021 17:14:31 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v3]
In-Reply-To: <QU3ZR8euhuq1lR4Y56LIKVkDzwxKm69ANvsNK9huCvg=.77568628-c221-4f79-b6c0-2a741a4fa130@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <QU3ZR8euhuq1lR4Y56LIKVkDzwxKm69ANvsNK9huCvg=.77568628-c221-4f79-b6c0-2a741a4fa130@github.com>
Message-ID: <tlGXT3yLC9ejzvJqP24QJ45flIZuG7PAiMk3dSVfnSs=.ba6ce5a3-ad32-4e97-b1fa-bfd444cb1509@github.com>

On Mon, 15 Nov 2021 17:33:09 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removed trailing whitespace
>  - test change

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 1:

> 1: import javax.swing.JScrollBar;

Please add standard copyright header to the test. You can borrow it from any existing openjdk test made by Oracle - just make sure to change the year to the current.

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @run main/manual ScrollBarBorderTest

Please add short summary of the test with "@summary" tag and BugID with "@bug". You can see how it is done in any other OpenJDK test.

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

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


From kizune at openjdk.java.net  Wed Nov 17 17:42:03 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 17 Nov 2021 17:42:03 GMT
Subject: Integrated: 8264293: Create implementation for NSAccessibilityMenu
 protocol peer
In-Reply-To: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
References: <u9WaIc_aeehlKE3lsUKLVsZ-4T4GKxQ90qoAbwlvHJE=.f50aee28-a5f1-4fc2-9c8e-511b93b6b43f@github.com>
Message-ID: <fZ_q_qFx9uG9QLZu1uuGMY3cNvvyzBgUDcslplJr4A8=.f0efe7a6-7310-4118-be73-825f195c3b83@github.com>

On Tue, 16 Nov 2021 23:53:53 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Added implementation for all menu related protocol peers;
> Native methods moved to CommonComponentAccessibility so they are called on correct peers;

This pull request has now been integrated.

Changeset: 8f5a8f74
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8f5a8f740b62c27cc244debe57aaa2975f84a694
Stats:     358 lines in 8 files changed: 309 ins; 48 del; 1 mod

8264293: Create implementation for NSAccessibilityMenu protocol peer
8264296: Create implementation for NSAccessibilityPopUpButton protocol peer
8264295: Create implementation for NSAccessibilityMenuItem protocol peer
8264294: Create implementation for NSAccessibilityMenuBar protocol peer

Reviewed-by: pbansal, ant

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

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


From vdyakov at openjdk.java.net  Wed Nov 17 17:53:02 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Wed, 17 Nov 2021 17:53:02 GMT
Subject: RFR: 8275071: [macos] A11y cursor gets stuck when combobox is
 closed
In-Reply-To: <Sz1qsgCQB6aPmVXTjnHsRKkQO60-8yyWrOZxVJFuFh0=.86498ac7-a0fa-43a1-a59c-2e9e69a7ac97@github.com>
References: <Sz1qsgCQB6aPmVXTjnHsRKkQO60-8yyWrOZxVJFuFh0=.86498ac7-a0fa-43a1-a59c-2e9e69a7ac97@github.com>
Message-ID: <jZZTrYuyZCJezfHnmTkm9R08mwl0rDIv88-zJtnrtJU=.b0f4b5a2-ccc3-478f-b7c2-343b6ed7d464@github.com>

On Wed, 17 Nov 2021 00:57:47 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Before the new JList accessibility peer implementation sending popup closed
> event to the combobox popup could trigger the native memory access error due
> to the events arriving in the wrong order. After new implementation is done
> it is no longer the case and this workaround needs to be removed.

@forantar please review

@pankaj-bansal please review

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

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


From prr at openjdk.java.net  Wed Nov 17 18:09:43 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 17 Nov 2021 18:09:43 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v3]
In-Reply-To: <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
Message-ID: <_s7UbFPZGFomdgynDfTyNbxaKGEz8eToZmdjFR49On8=.40ab007e-b321-497c-a49d-20c93f53ca1f@github.com>

On Fri, 29 Oct 2021 06:43:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review fix
>  - Fix

Marked as reviewed by prr (Reviewer).

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

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


From kizune at openjdk.java.net  Wed Nov 17 18:38:44 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 17 Nov 2021 18:38:44 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v3]
In-Reply-To: <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
Message-ID: <_GsokXhycd2zwICl19PieErt_uvKaRpi6E-t9taKnr4=.fc8eb5e5-8a12-40b1-9b37-25658cfc7fa7@github.com>

On Fri, 29 Oct 2021 06:43:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review fix
>  - Fix

Marked as reviewed by kizune (Reviewer).

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

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


From achung at openjdk.java.net  Wed Nov 17 18:55:20 2021
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 17 Nov 2021 18:55:20 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v4]
In-Reply-To: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
Message-ID: <icSGKnOryPHI_yd-HKjSmURmjwpfb0joZm533GHrsEo=.231a05f3-31a7-4c31-8aa1-01aa0ea5fe8f@github.com>

> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.

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

  added summary and copyright

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6374/files
  - new: https://git.openjdk.java.net/jdk/pull/6374/files/e6dab9b2..58ba8b21

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

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

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


From duke at openjdk.java.net  Wed Nov 17 19:25:15 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 17 Nov 2021 19:25:15 GMT
Subject: RFR: 8276794: Change nested classes in java.desktop to static
 nested classes [v2]
In-Reply-To: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
Message-ID: <SW4CHT966aVUkkAAoPvgKKiduDcKi9GVkBelW8YPEd0=.8d3aef66-9793-4888-9f0d-01963b8edfa3@github.com>

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)

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

  [PATCH] Change nested classes in java.desktop to static nested classes
  fix review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5943/files
  - new: https://git.openjdk.java.net/jdk/pull/5943/files/a9671a0e..1eeab86a

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

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

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


From aivanov at openjdk.java.net  Wed Nov 17 19:25:18 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 17 Nov 2021 19:25:18 GMT
Subject: RFR: 8276794: Change nested classes in java.desktop to static
 nested classes [v2]
In-Reply-To: <SW4CHT966aVUkkAAoPvgKKiduDcKi9GVkBelW8YPEd0=.8d3aef66-9793-4888-9f0d-01963b8edfa3@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
 <SW4CHT966aVUkkAAoPvgKKiduDcKi9GVkBelW8YPEd0=.8d3aef66-9793-4888-9f0d-01963b8edfa3@github.com>
Message-ID: <MGWGQeVVbIK6vE-am2U5wqosMOihxBHWFnDs8Jkalg8=.fd352573-6149-43b0-843f-b586abed7ce7@github.com>

On Wed, 17 Nov 2021 19:21:49 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
>> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [PATCH] Change nested classes in java.desktop to static nested classes
>   fix review comments

Marked as reviewed by aivanov (Reviewer).

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

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


From duke at openjdk.java.net  Wed Nov 17 19:25:27 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 17 Nov 2021 19:25:27 GMT
Subject: RFR: 8276794: Change nested classes in java.desktop to static
 nested classes [v2]
In-Reply-To: <usZ8Abd8HlU0tdT7MBFIw71TUOyvmvQ6RWlTrLumkH4=.f98b22c7-78ec-4c17-bbea-a8d9314b7b8d@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
 <usZ8Abd8HlU0tdT7MBFIw71TUOyvmvQ6RWlTrLumkH4=.f98b22c7-78ec-4c17-bbea-a8d9314b7b8d@github.com>
Message-ID: <XknssIAycNgSMx7qGOBFrm4LplD5_OjANEqaquJU0cg=.62c6c8fd-c47c-4686-b83a-38755b1b9c26@github.com>

On Wed, 17 Nov 2021 14:32:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   [PATCH] Change nested classes in java.desktop to static nested classes
>>   fix review comments
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java line 3949:
> 
>> 3947:     @SuppressWarnings("serial") // Superclass is not serializable across versions
>> 3948:     private static class ScrollableTabButton extends BasicArrowButton implements UIResource,
>> 3949:                                                                             SwingConstants {
> 
> Maybe, wrap the line before implements?

done

> src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 2300:
> 
>> 2298: 
>> 2299: @SuppressWarnings("serial") // JDK-implementation class
>> 2300:  static class PrintToFileErrorDialog extends Dialog implements ActionListener{
> 
> There's an extra space before `static` modifier which breaks the common indentation.
> I'd also add a space before the opening brace, it's there in the following code of the class.

fixed

> src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java line 165:
> 
>> 163:      */
>> 164:     @SuppressWarnings("serial") // JDK-implementation class
>> 165:      static class ScrollEvent extends PeerEvent {
> 
> There's an extra space before `static` modifier. Is it intentional?

fixed

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

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


From duke at openjdk.java.net  Wed Nov 17 19:35:23 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 17 Nov 2021 19:35:23 GMT
Subject: RFR: 8276794: Change nested classes in java.desktop to static
 nested classes [v3]
In-Reply-To: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
Message-ID: <H-RYtqhP56gWRjhd6X78rUExRezD-J9PbEpALfrr2aQ=.39702f88-14af-43b1-a182-6029a4c53c53@github.com>

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)

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

  [PATCH] Change nested classes in java.desktop to static nested classes
  move opening brace to the same line where class is declared

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5943/files
  - new: https://git.openjdk.java.net/jdk/pull/5943/files/1eeab86a..de4deb36

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

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

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


From duke at openjdk.java.net  Wed Nov 17 19:37:45 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 17 Nov 2021 19:37:45 GMT
Subject: RFR: 8276794: Change nested classes in java.desktop to static
 nested classes [v2]
In-Reply-To: <SW4CHT966aVUkkAAoPvgKKiduDcKi9GVkBelW8YPEd0=.8d3aef66-9793-4888-9f0d-01963b8edfa3@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
 <SW4CHT966aVUkkAAoPvgKKiduDcKi9GVkBelW8YPEd0=.8d3aef66-9793-4888-9f0d-01963b8edfa3@github.com>
Message-ID: <He0pLcSO6Fh53vj5vNBopavbRCMHzr8SkMDkYAzmCog=.01b437b4-84c9-4988-a1b1-06428a48ccb2@github.com>

On Wed, 17 Nov 2021 19:25:15 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
>> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [PATCH] Change nested classes in java.desktop to static nested classes
>   fix review comments

I would prefer to postpone expanding import to another issue/PR. This one is already quite big.

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

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


From serb at openjdk.java.net  Wed Nov 17 20:26:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 17 Nov 2021 20:26:43 GMT
Subject: RFR: 8275071: [macos] A11y cursor gets stuck when combobox is
 closed
In-Reply-To: <Sz1qsgCQB6aPmVXTjnHsRKkQO60-8yyWrOZxVJFuFh0=.86498ac7-a0fa-43a1-a59c-2e9e69a7ac97@github.com>
References: <Sz1qsgCQB6aPmVXTjnHsRKkQO60-8yyWrOZxVJFuFh0=.86498ac7-a0fa-43a1-a59c-2e9e69a7ac97@github.com>
Message-ID: <0nNVe7B_afzsDiM8yVT6ln1Q0FNLfBj7w-9NM6Q3uWI=.66d4d822-2234-4861-b0d0-b97a0c3492c2@github.com>

On Wed, 17 Nov 2021 00:57:47 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Before the new JList accessibility peer implementation sending popup closed
> event to the combobox popup could trigger the native memory access error due
> to the events arriving in the wrong order. After new implementation is done
> it is no longer the case and this workaround needs to be removed.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Wed Nov 17 20:30:45 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 17 Nov 2021 20:30:45 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v3]
In-Reply-To: <tlGXT3yLC9ejzvJqP24QJ45flIZuG7PAiMk3dSVfnSs=.ba6ce5a3-ad32-4e97-b1fa-bfd444cb1509@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <QU3ZR8euhuq1lR4Y56LIKVkDzwxKm69ANvsNK9huCvg=.77568628-c221-4f79-b6c0-2a741a4fa130@github.com>
 <tlGXT3yLC9ejzvJqP24QJ45flIZuG7PAiMk3dSVfnSs=.ba6ce5a3-ad32-4e97-b1fa-bfd444cb1509@github.com>
Message-ID: <KI_pV9ahR6ci4aE72CVilGdCJIg4rqobLRYfQI9jm_Y=.d212448e-89dc-4cf3-9697-4230e3b973ec@github.com>

On Wed, 17 Nov 2021 17:08:36 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - removed trailing whitespace
>>  - test change
>
> test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @run main/manual ScrollBarBorderTest
> 
> Please add short summary of the test with "@summary" tag and BugID with "@bug". You can see how it is done in any other OpenJDK test.

Probably it will be good to try some kind of automation.

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

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


From serb at openjdk.java.net  Thu Nov 18 00:05:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 18 Nov 2021 00:05:41 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <k1gQRfQhMEC2tFwq5ZyyEmfebNqR6Mws651ijtdhTc8=.57c33d5c-9b6e-4b6c-9f4b-0afae0d0615f@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <-hj0v7RZ0HPpP9GND5csZsZ1Vz7oxaufOAC0-ZygtwM=.6a5ae7a8-52d6-4e3e-a166-2fae2c23dbe0@github.com>
 <cTqTWZsK6uJI_Kw9nUymKQnYxxzWBRrk52qJAKpAc9I=.18f7dffd-3ebe-4bd0-bc2f-d61b55437036@github.com>
 <aZX6pJkrGOTYLlAHRl9WlEGtoahiInx4QzelDWpV2b0=.c9a736f9-5dd5-4382-8513-94a0233105dc@github.com>
 <QPyLlBXqr80h-_OjGxuv6tGNl8_-IZ8IHF-_8QWy894=.b18fd0a2-4497-4aae-87b1-1570531f2862@github.com>
 <2rBhm1b2wZwnJFYIve6hdNLHFE0iAkGbj1GkDkSOUCs=.726e6e6a-76b6-4657-b44b-dd854769055c@github.com>
 <k1gQRfQhMEC2tFwq5ZyyEmfebNqR6Mws651ijtdhTc8=.57c33d5c-9b6e-4b6c-9f4b-0afae0d0615f@github.com>
Message-ID: <XNGsAkbvY13zmHrSmo3LpPDQNQNb97ocf_501nLgCMY=.da8f1bf4-c305-4e32-9d39-b2ab01a3da26@github.com>

On Wed, 17 Nov 2021 08:13:09 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> I suggest leaving it as is for some time, since it is known that could workaround another bug, linked below.
>
> @mrserb Can I hope this fix will be integrated after JDK-8270874 is fixed?

Yes.

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

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


From psadhukhan at openjdk.java.net  Thu Nov 18 04:37:47 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 18 Nov 2021 04:37:47 GMT
Subject: Integrated: 8276058: Some swing test fails on specific CI macos system
In-Reply-To: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
Message-ID: <Vgl9AlSDLATY9WZXeQ6MC4nkdYsqCv_Iy9P6T1gS8tA=.96a77a34-ccb8-49c7-b4ba-531682849152@github.com>

On Wed, 27 Oct 2021 12:42:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
> It was seen from the logs that we have color mismatch in these tests.
> 
> For example, in PressedIcon test, we had following log
> 
> ----------System.out:(1/75)----------
> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
> ----------System.err:(13/842)----------
> java.lang.RuntimeException: Colors is different for scale=1!
> 	at PressedIconTest.main(PressedIconTest.java:97)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> and JInternalFrame test, we had 
> ----------System.err:(15/939)----------
> FRAME_COLOR Red: 255; Green: 200; Blue: 0
> Pixel color Red: 55; Green: 55; Blue: 55
> java.lang.RuntimeException: Internal frame is not correctly dragged!
> 	at bug8069348.main(bug8069348.java:96)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
> 
> The awt tests that are failing seems to have different root cause and will be handled separately.

This pull request has now been integrated.

Changeset: 91607436
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/91607436b79126ccb999deaf38a98209dbfe6ec1
Stats:     126 lines in 5 files changed: 79 ins; 7 del; 40 mod

8276058: Some swing test fails on specific CI macos system

Reviewed-by: prr, kizune

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

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


From serb at openjdk.java.net  Thu Nov 18 05:41:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 18 Nov 2021 05:41:41 GMT
Subject: RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v2]
In-Reply-To: <DZpSTzGC0LcaK9FqwBCGbVIPUle1YEazznQZkfYOm58=.2f864fc5-3804-4180-be13-b7f1c2b5bed3@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
 <DZpSTzGC0LcaK9FqwBCGbVIPUle1YEazznQZkfYOm58=.2f864fc5-3804-4180-be13-b7f1c2b5bed3@github.com>
Message-ID: <0TqXqT-I0fAChKQOB5lDYeIIxG-wqzDjF22lFYWyHC0=.984aefe4-21e4-4fbe-81bf-15a3547d88bf@github.com>

On Wed, 13 Oct 2021 07:35:16 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> 8274893: Update java.desktop classes to use try-with-resources
>
> Andrey Turbanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8274893: Update java.desktop classes to use try-with-resources
>    close nested resources too
>  - [PATCH] Use try-with-resources to close resources in java.desktop

src/java.desktop/share/classes/com/sun/media/sound/StandardMidiFileReader.java line 150:

> 148:     public MidiFileFormat getMidiFileFormat(URL url) throws InvalidMidiDataException, IOException {
> 149:         try (InputStream urlStream = url.openStream()) { // throws IOException
> 150:             BufferedInputStream bis = new BufferedInputStream(urlStream, bisBufferSize);

Do we need to close the bis here and below as well?

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 463:

> 461:                         new InputStreamReader(is, ISO_8859_1));
> 462:                 defaultStyles.loadRules(r, null);
> 463:                 r.close();

the reader was not added to the try block, it will not be closed.

src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 398:

> 396:                 Properties props = new Properties();
> 397:                 try (var is = new FileInputStream(f.getPath());
> 398:                      var bis = new BufferedInputStream(is))

It will be better to use the same pattern everywhere, since the types are used in other places it will be good to use it here as well.

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

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


From pbansal at openjdk.java.net  Thu Nov 18 06:39:43 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 18 Nov 2021 06:39:43 GMT
Subject: RFR: 8275071: [macos] A11y cursor gets stuck when combobox is
 closed
In-Reply-To: <Sz1qsgCQB6aPmVXTjnHsRKkQO60-8yyWrOZxVJFuFh0=.86498ac7-a0fa-43a1-a59c-2e9e69a7ac97@github.com>
References: <Sz1qsgCQB6aPmVXTjnHsRKkQO60-8yyWrOZxVJFuFh0=.86498ac7-a0fa-43a1-a59c-2e9e69a7ac97@github.com>
Message-ID: <fzT4GgV__J3mJG5g-UAuNGWgDqqlNuw-sAFK-2RggBU=.ee078944-d5eb-47b8-aab4-7ee3128b663a@github.com>

On Wed, 17 Nov 2021 00:57:47 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Before the new JList accessibility peer implementation sending popup closed
> event to the combobox popup could trigger the native memory access error due
> to the events arriving in the wrong order. After new implementation is done
> it is no longer the case and this workaround needs to be removed.

Marked as reviewed by pbansal (Reviewer).

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

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


From duke at openjdk.java.net  Thu Nov 18 10:51:47 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Thu, 18 Nov 2021 10:51:47 GMT
Subject: Integrated: 8276794: Change nested classes in java.desktop to static
 nested classes
In-Reply-To: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
Message-ID: <XbsvldvEVzUPL0-DPd5Asbp0ENIaqhqdK-mtU7NWW74=.72e87359-2f6a-4b02-b2e0-5b9c33e323b3@github.com>

On Thu, 14 Oct 2021 07:47:33 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)

This pull request has now been integrated.

Changeset: 0a65e8b2
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a65e8b282fd41e57108422fbd140527d9697efd
Stats:     226 lines in 79 files changed: 3 ins; 53 del; 170 mod

8276794: Change nested classes in java.desktop to static nested classes

Reviewed-by: serb, aivanov

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

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


From aivanov at openjdk.java.net  Thu Nov 18 13:24:13 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 18 Nov 2021 13:24:13 GMT
Subject: RFR: JDK-8277396: [TESTBUG] In DefaultButtonModelCrashTest.java,
 frame is accessed from main thread
Message-ID: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>

It's a little cleanup: make sure `frame` is accessed from EDT only, remove unused variables and imports.

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

Commit messages:
 - JDK-8277396: [TESTBUG] In DefaultButtonModelCrashTest.java, frame is accessed from main thread

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

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


From aivanov at openjdk.java.net  Thu Nov 18 13:24:16 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 18 Nov 2021 13:24:16 GMT
Subject: RFR: JDK-8277396: [TESTBUG] In DefaultButtonModelCrashTest.java, 
 frame is accessed from main thread
In-Reply-To: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
References: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
Message-ID: <4SBwKtkr4fvsswEV2BJPiSMt5A-tHWINUGFIoBsoYLc=.6f22f5e4-1a37-4211-b03f-66a9cfc00cc4@github.com>

On Thu, 18 Nov 2021 13:17:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> It's a little cleanup: make sure `frame` is accessed from EDT only, remove unused variables and imports.

test/jdk/javax/swing/DefaultButtonModel/DefaultButtonModelCrashTest.java line 24:

> 22:  */
> 23: 
> 24: /*

With double asterisk, it's highlighted as a warning by my IDE: _Dangling Javadoc comment_.
I prefer fixing it.

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

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


From psadhukhan at openjdk.java.net  Thu Nov 18 15:22:09 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 18 Nov 2021 15:22:09 GMT
Subject: Integrated: 8277407:
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java fails to compile
 after JDK-8276058
Message-ID: <vWkRkXnwnCIC9ZXJtyw_bYEXLzGrEHC709H7s4NZELc=.17923079-a422-4d16-b9bf-9d58c8b6471e@github.com>

Fixed compilation issue.

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

Commit messages:
 - 8277407: javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java fails to compile after JDK-8276058

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

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


From dcubed at openjdk.java.net  Thu Nov 18 15:22:10 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 18 Nov 2021 15:22:10 GMT
Subject: Integrated: 8277407:
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java fails to compile
 after JDK-8276058
In-Reply-To: <vWkRkXnwnCIC9ZXJtyw_bYEXLzGrEHC709H7s4NZELc=.17923079-a422-4d16-b9bf-9d58c8b6471e@github.com>
References: <vWkRkXnwnCIC9ZXJtyw_bYEXLzGrEHC709H7s4NZELc=.17923079-a422-4d16-b9bf-9d58c8b6471e@github.com>
Message-ID: <2ieSw3MSrBk49EeHbdyGHrVy1oG2P0khcj0q9eE3COQ=.d7c7464c-f17f-42cf-bf59-f90a99250957@github.com>

On Thu, 18 Nov 2021 15:09:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fixed compilation issue.

Single char typo. Wow. Thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

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


From psadhukhan at openjdk.java.net  Thu Nov 18 15:22:11 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 18 Nov 2021 15:22:11 GMT
Subject: Integrated: 8277407:
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java fails to compile
 after JDK-8276058
In-Reply-To: <vWkRkXnwnCIC9ZXJtyw_bYEXLzGrEHC709H7s4NZELc=.17923079-a422-4d16-b9bf-9d58c8b6471e@github.com>
References: <vWkRkXnwnCIC9ZXJtyw_bYEXLzGrEHC709H7s4NZELc=.17923079-a422-4d16-b9bf-9d58c8b6471e@github.com>
Message-ID: <8kD5GLtKvFF8JbEXdoY15Cu-bdedi6OWjh1MqK8_hEY=.eb5cd8be-1f05-47c2-8aa4-6a6e4a84b5b1@github.com>

On Thu, 18 Nov 2021 15:09:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fixed compilation issue.

This pull request has now been integrated.

Changeset: 276bfcd1
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/276bfcd1a115f90dde644abef79d64bb61788c75
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8277407: javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java fails to compile after JDK-8276058

Reviewed-by: dcubed

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

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


From psadhukhan at openjdk.java.net  Thu Nov 18 15:41:45 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 18 Nov 2021 15:41:45 GMT
Subject: RFR: JDK-8277396: [TESTBUG] In DefaultButtonModelCrashTest.java, 
 frame is accessed from main thread
In-Reply-To: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
References: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
Message-ID: <9Dw0TGltiche5_fKfJQ5euvz4aZt4aDC_IEJlVThwYc=.54038db5-3fd5-4eb8-b294-4fd1a99f9b94@github.com>

On Thu, 18 Nov 2021 13:17:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> It's a little cleanup: make sure `frame` is accessed from EDT only, remove unused variables and imports.

I guess there's  probably 100+ tests in swing that access frame outside EDT before it calls dispose ex. 
Action/8133039/bug8133039.java, Box/TestBoxFiller.java, ButtonGroup/TestButtonGroupFocusTraversal.java, JButton/4368790/bug4368790.java, JButton/4796987/bug4796987.java..

If you are changing this, then those also needs to be updated, I guess..

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

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


From kizune at openjdk.java.net  Thu Nov 18 16:11:45 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 18 Nov 2021 16:11:45 GMT
Subject: Integrated: 8275071: [macos] A11y cursor gets stuck when combobox is
 closed
In-Reply-To: <Sz1qsgCQB6aPmVXTjnHsRKkQO60-8yyWrOZxVJFuFh0=.86498ac7-a0fa-43a1-a59c-2e9e69a7ac97@github.com>
References: <Sz1qsgCQB6aPmVXTjnHsRKkQO60-8yyWrOZxVJFuFh0=.86498ac7-a0fa-43a1-a59c-2e9e69a7ac97@github.com>
Message-ID: <UQeu7hn0YkTjV64U_E1nXGMXqppaTpcfus9tkpgQ4kM=.08095258-d28f-49ed-91c5-ad0d0868639e@github.com>

On Wed, 17 Nov 2021 00:57:47 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Before the new JList accessibility peer implementation sending popup closed
> event to the combobox popup could trigger the native memory access error due
> to the events arriving in the wrong order. After new implementation is done
> it is no longer the case and this workaround needs to be removed.

This pull request has now been integrated.

Changeset: 5d249c46
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5d249c46abc8dfdc3acdaff41d26f3bd9ba84731
Stats:     18 lines in 1 file changed: 0 ins; 6 del; 12 mod

8275071: [macos] A11y cursor gets stuck when combobox is closed

Reviewed-by: serb, pbansal

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

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


From aivanov at openjdk.java.net  Thu Nov 18 16:49:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 18 Nov 2021 16:49:40 GMT
Subject: RFR: JDK-8277396: [TESTBUG] In DefaultButtonModelCrashTest.java, 
 frame is accessed from main thread
In-Reply-To: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
References: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
Message-ID: <zgZ3wjk5Ltf5IGRvWqsRdjoGlmHy8XwWL-0em8dlMi8=.a410fb8f-c29a-4742-a895-1e736cb3044e@github.com>

On Thu, 18 Nov 2021 13:17:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> It's a little cleanup: make sure `frame` is accessed from EDT only, remove unused variables and imports.

I've been working with this test, I found what seemed wrong and so I decided to fix it.

I'm sure there are many tests which access some variables from different threads without synchronisation, there could be tests which create or access Swing UI not from EDT. Yet it wasn't my intention to fix all tests. I believe we've been updating the tests and resolve such problems on one-by-one basis when it gets noticed, when a test gets updated etc.

If you think it's not worth it, I'll withdraw my PR.

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

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


From serb at openjdk.java.net  Thu Nov 18 18:28:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 18 Nov 2021 18:28:43 GMT
Subject: Integrated: 8270874: JFrame paint artifacts when dragged from standard
 monitor to HiDPI monitor
In-Reply-To: <hPV-NYDHAMhyOviuU89e9Frm1ALNGqn_Uw0i4NDscRE=.e3fcd015-0bc5-4e7a-92f0-8474ee8af548@github.com>
References: <hPV-NYDHAMhyOviuU89e9Frm1ALNGqn_Uw0i4NDscRE=.e3fcd015-0bc5-4e7a-92f0-8474ee8af548@github.com>
Message-ID: <HHLa-hUXsMGst9zt7_NxlKrGb2W7St1EguBQQC2kDW0=.9827297f-9e84-44cc-b46b-9d878a3c70cd@github.com>

On Wed, 10 Nov 2021 18:45:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The bug occurs more often if initially the window is moved partly outside of the first screen(let's name this part as the invisible part), and then slowly moved to the second screen where that invisible part became visible on the second screen.
> 
> The problem is how we try to repaint the frame. The Windows send us coordinates to repaint in the device space, if the width/height values are less than a unit in the user's space, we round it to the empty rectangle and skip it.
> 
> Solution: request to repaint the smallest non-empty bounding box in the user's space around the region of pixels.
> 
> Workaround: repaint the whole window on the component resize/move event or at the end of the drag.
> 
> Notes:
>  * It is not reproducible(at least much less often) when d3d is enabled because the d3d pipeline sends repaint events more often (example https://github.com/openjdk/jdk/pull/6064). That hides the current issue.
>  * It started to be reproducible during the drag from one screen to another after JDK-8211999 because before JDK-8211999 we make a resize at the end of the drag, which caused the full repaint of the window.

This pull request has now been integrated.

Changeset: 03473b4c
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/03473b4c271b2ec7f0ebdb0edabadf7f36816b9d
Stats:     19 lines in 2 files changed: 10 ins; 0 del; 9 mod

8270874: JFrame paint artifacts when dragged from standard monitor to HiDPI monitor

Reviewed-by: jdv

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

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


From duke at openjdk.java.net  Thu Nov 18 18:36:20 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Thu, 18 Nov 2021 18:36:20 GMT
Subject: RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v2]
In-Reply-To: <0TqXqT-I0fAChKQOB5lDYeIIxG-wqzDjF22lFYWyHC0=.984aefe4-21e4-4fbe-81bf-15a3547d88bf@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
 <DZpSTzGC0LcaK9FqwBCGbVIPUle1YEazznQZkfYOm58=.2f864fc5-3804-4180-be13-b7f1c2b5bed3@github.com>
 <0TqXqT-I0fAChKQOB5lDYeIIxG-wqzDjF22lFYWyHC0=.984aefe4-21e4-4fbe-81bf-15a3547d88bf@github.com>
Message-ID: <kR7R52upKYWNj1Xy-MZ577miiV9htEq0Sj8iZCTxaOg=.a79be09c-5855-48e7-a38f-22b356861ec5@github.com>

On Thu, 18 Nov 2021 05:30:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8274893: Update java.desktop classes to use try-with-resources
>>    close nested resources too
>>  - [PATCH] Use try-with-resources to close resources in java.desktop
>
> src/java.desktop/share/classes/com/sun/media/sound/StandardMidiFileReader.java line 150:
> 
>> 148:     public MidiFileFormat getMidiFileFormat(URL url) throws InvalidMidiDataException, IOException {
>> 149:         try (InputStream urlStream = url.openStream()) { // throws IOException
>> 150:             BufferedInputStream bis = new BufferedInputStream(urlStream, bisBufferSize);
> 
> Do we need to close the bis here and below as well?

I'm not sure it's 100% needed to close BufferedInputStream/BufferedReader wrappers. It's more code style question. Updated.

> src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 398:
> 
>> 396:                 Properties props = new Properties();
>> 397:                 try (var is = new FileInputStream(f.getPath());
>> 398:                      var bis = new BufferedInputStream(is))
> 
> It will be better to use the same pattern everywhere, since the types are used in other places it will be good to use it here as well.

as you wish

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

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


From duke at openjdk.java.net  Thu Nov 18 18:36:12 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Thu, 18 Nov 2021 18:36:12 GMT
Subject: RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v3]
In-Reply-To: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
Message-ID: <S6y6z4BInR8rwrriKM_7M-yIOQqmctrhwhRbzcevlys=.d94aeba8-df69-4a9b-a32b-0ef9ef233e57@github.com>

> 8274893: Update java.desktop classes to use try-with-resources

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

  8274893: Update java.desktop classes to use try-with-resources
  fix review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5817/files
  - new: https://git.openjdk.java.net/jdk/pull/5817/files/13bdbc0d..19ced6d9

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

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

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


From duke at openjdk.java.net  Thu Nov 18 18:36:22 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Thu, 18 Nov 2021 18:36:22 GMT
Subject: RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v3]
In-Reply-To: <0TqXqT-I0fAChKQOB5lDYeIIxG-wqzDjF22lFYWyHC0=.984aefe4-21e4-4fbe-81bf-15a3547d88bf@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
 <DZpSTzGC0LcaK9FqwBCGbVIPUle1YEazznQZkfYOm58=.2f864fc5-3804-4180-be13-b7f1c2b5bed3@github.com>
 <0TqXqT-I0fAChKQOB5lDYeIIxG-wqzDjF22lFYWyHC0=.984aefe4-21e4-4fbe-81bf-15a3547d88bf@github.com>
Message-ID: <evHZiymXk5g7z5wYB2EzoHBx9HTs8xpNHAd3prGDvDc=.3e020003-99ef-4394-96d2-1ab2c7c14dd3@github.com>

On Thu, 18 Nov 2021 05:36:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274893: Update java.desktop classes to use try-with-resources
>>   fix review comments
>
> src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 463:
> 
>> 461:                         new InputStreamReader(is, ISO_8859_1));
>> 462:                 defaultStyles.loadRules(r, null);
>> 463:                 r.close();
> 
> the reader was not added to the try block, it will not be closed.

updated

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

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


From kizune at openjdk.java.net  Thu Nov 18 19:13:55 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 18 Nov 2021 19:13:55 GMT
Subject: RFR: 8264297: Create implementation for
 NSAccessibilityProgressIndicator protocol peer
Message-ID: <CUGVr_lRTIwtyltf5LiQvze9IwUoasByQ1dpQmSZwNA=.25e7c41d-0ae3-49cf-9cce-bea175d12939@github.com>

Add component accessibility peer

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

Commit messages:
 - JDK-8264297: Create implementation for NSAccessibilityProgressIndicator protocol peer

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

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


From vdyakov at openjdk.java.net  Thu Nov 18 19:55:43 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Thu, 18 Nov 2021 19:55:43 GMT
Subject: RFR: 8264297: Create implementation for
 NSAccessibilityProgressIndicator protocol peer
In-Reply-To: <CUGVr_lRTIwtyltf5LiQvze9IwUoasByQ1dpQmSZwNA=.25e7c41d-0ae3-49cf-9cce-bea175d12939@github.com>
References: <CUGVr_lRTIwtyltf5LiQvze9IwUoasByQ1dpQmSZwNA=.25e7c41d-0ae3-49cf-9cce-bea175d12939@github.com>
Message-ID: <t7sTpy1bLiEko8vNJj6BCJV7-2gAg2Z-onJc-w3qFgw=.02e84dc8-4522-4432-81f0-e91f64a63f65@github.com>

On Thu, 18 Nov 2021 19:04:05 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add component accessibility peer

@forantar please review

@pankaj-bansal please review

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

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


From bchristi at openjdk.java.net  Thu Nov 18 22:55:02 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 18 Nov 2021 22:55:02 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal
Message-ID: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>

Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.

This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.

The CSR has been approved.
An automated test build+test run passes cleanly (FWIW :D ).

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

Commit messages:
 - merge
 - @SuppressWarnings(removal) in Windows CKey.java
 - Add jls tag to runFinalization methods
 - Update wording of Object.finalize, new paragraph is now bold
 - update Object.finalize javadoc
 - update Object.finalize JavaDoc and @deprecated tag
 - Update Object.finalize deprecation message
 - Indicate that runFinalizers does nothing if finalization is disabled or removed
 - Fix @since on @Deprecated for java.lang.Enum
 - Clarify conditions for removal of Object.finalize method
 - ... and 21 more: https://git.openjdk.java.net/jdk/compare/89b125f4...eca95cb2

Changes: https://git.openjdk.java.net/jdk/pull/6465/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276447
  Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465

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


From tnakamura at openjdk.java.net  Fri Nov 19 01:50:47 2021
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Fri, 19 Nov 2021 01:50:47 GMT
Subject: RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese
 characters were garbled [v3]
In-Reply-To: <wtw6CL7UmKW6QM67dWNhZNGz2N1dQOvVs_-0w57iKao=.9c965195-4343-48b4-a8b0-65d75a38da23@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
 <wtw6CL7UmKW6QM67dWNhZNGz2N1dQOvVs_-0w57iKao=.9c965195-4343-48b4-a8b0-65d75a38da23@github.com>
Message-ID: <rZYnnyLgPJMcC_FsTRB3qQjOjSlwZKceSWeaSqt3syM=.e86a46bb-de0d-4d18-81de-43cd4fa20973@github.com>

On Thu, 21 Oct 2021 00:57:47 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> Hi,
>> 
>> Could you review the fix?
>> When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts.
>> 
>> The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn.
>
> 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 seven additional commits since the last revision:
> 
>  - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
>  - revert previous proposal
>  - Merge branch 'master' into 8240756
>  - 2nd proposal
>  - Revert previous change
>  - Merge branch 'master' into 8240756
>    merge master
>  - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled

Let me explain the fix a little bit more.
The native API for drawing with glyph vector, `CGContextShowGlyphsAtPoint()`, cannot set multiple fonts.
So, the latest fix (c52a9f) switches the target font by Java code side, when 'slot' data is not 0, which means non-default font is used.
This is completely changed from my previous proposals.

Also, I could finally create an automated test case. It compares drawing results by `SunGraphics2D.drawGlyphVector()` and `SunGraphics2D.drawString()` under `OSXOffScreenSurfaceData`. Since drawing positions can be different between these methods even if English characters, it tries to compare pixel counts. This can detect to use different glyphs.

I appreciate any comments.

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

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


From psadhukhan at openjdk.java.net  Fri Nov 19 05:25:36 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 19 Nov 2021 05:25:36 GMT
Subject: RFR: JDK-8277396: [TESTBUG] In DefaultButtonModelCrashTest.java, 
 frame is accessed from main thread
In-Reply-To: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
References: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
Message-ID: <UoxS-cjKbOJw2q1ItHyX9gg5dzPuAoL7NAdnSQYhwn8=.2e4ee68c-3953-44fd-8fb2-5f5d95e0c94a@github.com>

On Thu, 18 Nov 2021 13:17:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> It's a little cleanup: make sure `frame` is accessed from EDT only, remove unused variables and imports.

I am not sure on this as those 100+ tests which accesses frame variable outside EDT before it calls dispose  is not failing in CI testing and also locally so to modify this particular test only does not make sense to me.
But anyway, it's your call...
If you still want to take it forward, regarding the test, I will request to add a delay of 1sec after l56 after we make the frame visible, same way we normally do for other swing reg tests.

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

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


From kizune at openjdk.java.net  Fri Nov 19 05:47:41 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 19 Nov 2021 05:47:41 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v4]
In-Reply-To: <icSGKnOryPHI_yd-HKjSmURmjwpfb0joZm533GHrsEo=.231a05f3-31a7-4c31-8aa1-01aa0ea5fe8f@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <icSGKnOryPHI_yd-HKjSmURmjwpfb0joZm533GHrsEo=.231a05f3-31a7-4c31-8aa1-01aa0ea5fe8f@github.com>
Message-ID: <yP01TI0o-hQYcgDnxttQgx7L0onJBLs7SSm0UFGkCT4=.9d7e1fed-d48a-4d95-b916-a938b2716678@github.com>

On Wed, 17 Nov 2021 18:55:20 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added summary and copyright

Marked as reviewed by kizune (Reviewer).

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

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


From kizune at openjdk.java.net  Fri Nov 19 06:42:53 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 19 Nov 2021 06:42:53 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits
Message-ID: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>

Made colorBits and maskBits arrays dynamic so they are allocated on heap instead of stack.
Added regression test.

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

Commit messages:
 - 8277299: STACK_OVERFLOW in Java_sun_awt_shell_Win32ShellFolder2_getIconBits

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

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


From lbourges at openjdk.java.net  Fri Nov 19 07:11:43 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 19 Nov 2021 07:11:43 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v9]
In-Reply-To: <2y_kzHqARE6UR805mdKhGmdTDXs3LFV3ogko9YZBc14=.cee9bb93-58a0-461a-82e7-2d8350b3a382@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <2y_kzHqARE6UR805mdKhGmdTDXs3LFV3ogko9YZBc14=.cee9bb93-58a0-461a-82e7-2d8350b3a382@github.com>
Message-ID: <lNi0SqrdDWXV9BMn89iAtUwIGRgeyAYfj17JSZFj178=.186157ef-530c-4202-b1d4-c6a90a45a0c2@github.com>

On Wed, 17 Nov 2021 08:53:07 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   Addressing code review feedback: "I would prefer having accumulate functions called twice (using offset)"
>   
>   https://github.com/openjdk/jdk/pull/6227#issuecomment-970040098

test/jdk/java/awt/geom/Path2D/GetBounds2DPrecisionTest.java line 254:

> 252:             res[roots++] = q.divide(a, RoundingMode.HALF_EVEN);
> 253:             if (!q.equals(BigDecimal.ZERO)) {
> 254:                 res[roots++] = c.divide(q, RoundingMode.HALF_EVEN);

This divide operation suffers missing decimals:
Use BigDecomal.setScale(40) to ascertain precision.

See https://github.com/bourgesl/marlin-math/blob/c9bbfbac4565e81e54ce79fc02c38fcaa2fe0e48/src/main/java/test/FindExtremaAccuracyTest.java#L667

See cubic test fixed:
https://github.com/bourgesl/marlin-math/blob/main/results/findExtrema/jdk17-2021-11-19-dist-cubic.log

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

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


From myano at openjdk.java.net  Fri Nov 19 09:04:22 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 19 Nov 2021 09:04:22 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v4]
In-Reply-To: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
Message-ID: <q1CL3FjeQs3GzNh4gKrjzuBAQbCUYc7cUXIGT7hvnvI=.7365f57d-84ca-45d5-a3cd-f6577c244ecf@github.com>

> Could you please review the 8262297 bug fixes?
> 
> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.

Masanori Yano has updated the pull request incrementally with two additional commits since the last revision:

 - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
 - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6151/files
  - new: https://git.openjdk.java.net/jdk/pull/6151/files/0c7bb8d5..22b82942

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

  Stats: 143 lines in 4 files changed: 79 ins; 63 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6151/head:pull/6151

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


From myano at openjdk.java.net  Fri Nov 19 09:04:24 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 19 Nov 2021 09:04:24 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v3]
In-Reply-To: <qIUvpCLlEaDOEhEX2IxRiHpdbh3B1n2XhA-zlXXaTgU=.306e8484-3cf0-4a13-81e4-f8d9c07782b0@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <gwA_8ObJLdJifNeXZH96uV_wHvY8TkSJyeqo91tgkhE=.9b578d70-9a44-48ef-a0fc-f10a47ca6418@github.com>
 <ZTlmTugLnJJ1C4zpBPWm2IGSm5PVxkNXcMXlOSguvog=.0ee2d1e4-a91b-463c-9470-a32b90fce937@github.com>
 <qIUvpCLlEaDOEhEX2IxRiHpdbh3B1n2XhA-zlXXaTgU=.306e8484-3cf0-4a13-81e4-f8d9c07782b0@github.com>
Message-ID: <0dTS5He33a74Ct3u8B7SEV1A95DEaCv8sCQWr4JZZBw=.26b57abe-78a3-465c-8218-25e9ff6a4241@github.com>

On Tue, 16 Nov 2021 00:40:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java line 1459:
>> 
>>> 1457:         int biType = imgType.getBufferedImageType();
>>> 1458:         int bpp = imgType.getColorModel().getPixelSize();
>>> 1459:         if (bpp != 0 && bpp != 1 && bpp != 4 && bpp != 8 && bpp != 16 && bpp != 24 && bpp != 32) {
>> 
>> This change looks good to me.
>
> Probably the exception message caused by this should be updated as well? Currently, it takes care of compression only.

I also think the message should be change. I added bpp information at the end of the exception message.

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

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


From myano at openjdk.java.net  Fri Nov 19 09:04:29 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 19 Nov 2021 09:04:29 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v3]
In-Reply-To: <ZTlmTugLnJJ1C4zpBPWm2IGSm5PVxkNXcMXlOSguvog=.0ee2d1e4-a91b-463c-9470-a32b90fce937@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <gwA_8ObJLdJifNeXZH96uV_wHvY8TkSJyeqo91tgkhE=.9b578d70-9a44-48ef-a0fc-f10a47ca6418@github.com>
 <ZTlmTugLnJJ1C4zpBPWm2IGSm5PVxkNXcMXlOSguvog=.0ee2d1e4-a91b-463c-9470-a32b90fce937@github.com>
Message-ID: <DFrQmd5NxTIi_mzpO3h4Oes_-h0n0xWy1QkCygX1s2Q=.8ea88831-1b1e-4bbe-a270-18f08e4b4e5d@github.com>

On Mon, 15 Nov 2021 08:02:19 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Masanori Yano has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
>>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
>
> test/jdk/javax/imageio/plugins/bmp/TruncatedPngTest.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8262297
>> 27:  * @summary Checks that ImageIO.write(..., ..., File) truncates the file
> 
> I think with latest patch this summary should be updated to reflect what test is verifying.

I changed summary to verify bit per pixel checking.

> test/jdk/javax/imageio/plugins/bmp/TruncatedPngTest.java line 41:
> 
>> 39: 
>> 40:     public static void main(String[] args) {
>> 41:         String fileName = "0.png";
> 
> A 2KB image will not take much space but it would be better if we can create 2bpp PNG image programmatically and use it in the test case.

I changed test to use generated BufferdImage and more bpp.

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

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


From mbaesken at openjdk.java.net  Fri Nov 19 09:14:15 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 19 Nov 2021 09:14:15 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows [v3]
In-Reply-To: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
Message-ID: <vZdJqlPw_-3v2JnC8K4qxzW8SCwPCvQcbUmy9X4jBRs=.20d73184-0584-4058-8e2d-02d62957592b@github.com>

> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni to an awt related test, and shows on Windows server 2019 the following JNI warning , so the test  JNICheck/FreeTypeScalerJNICheck.java fails on this Windows version.
> 
> :stdErr:
> Thu Oct 28 01:27:10 CEST 2021
> stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV
>                at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 18.0.0.1-internal/Native Method)
>                at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:95)
>                at sun.awt.Win32GraphicsEnvironment.<clinit>(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:63)
>                at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 18.0.0.1-internal/PlatformGraphicsInfo.java:34)
>                at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:93)
>                at java.awt.GraphicsEnvironment$LocalGE.<clinit>(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:84)
>                at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:106)
>                at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53)
>                at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)
> 
> We can get rid of the warning by adjusting a JNU_CallStaticMethodByName call in awt_Win32GraphicsEnv.cpp .

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

  do you run FreeTypeScalerJNICheck.java test on Windows

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6306/files
  - new: https://git.openjdk.java.net/jdk/pull/6306/files/ab1101b3..579bd889

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

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

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


From duke at openjdk.java.net  Fri Nov 19 09:40:48 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 19 Nov 2021 09:40:48 GMT
Subject: Withdrawn: 8273618: DisplayChangeVITest.java is timing out on macOS 12
 aarch64
In-Reply-To: <AFbV2Uqsh4airkhkCe4pgdG3P7l8vsKXuQd3K_sRqq8=.2038d763-90bb-494f-b937-28dc6dd39707@github.com>
References: <AFbV2Uqsh4airkhkCe4pgdG3P7l8vsKXuQd3K_sRqq8=.2038d763-90bb-494f-b937-28dc6dd39707@github.com>
Message-ID: <lGDnM0U7-P2WJ13DgTUq5DhSF7P_DqGRtJpvqoN6DpM=.4843c9cc-21c0-4d40-82e7-c9d73b16842c@github.com>

On Thu, 23 Sep 2021 13:52:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java is timing out on a macOS 12 aarch64 (an Apple Silicon Mac Mini) system due to getting locked on frame.dispose() even though test passed.
> Modified test to use JFrame in EDT and revert the frame back to windowed mode before dispose frame in finally block.
> 
> Modified test pass in CI system for several iterations in all platforms (including macos x64 and aarch64)

This pull request has been closed without being integrated.

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

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


From alanb at openjdk.java.net  Fri Nov 19 17:31:53 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 19 Nov 2021 17:31:53 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <s5uZ42EuMGyW0S1nktOZSh1I5BUeC-lGUK4-VLTAZbw=.151b63d2-7598-47a7-a3e1-a0d9d0617aa9@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Looks good.

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

Marked as reviewed by alanb (Reviewer).

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


From rriggs at openjdk.java.net  Fri Nov 19 17:31:47 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 19 Nov 2021 17:31:47 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <g-OOLS12CnVzpJmzzDjU72acZU5_sb508fBLcLxhzoA=.4d7503a8-c2d2-4dd1-b92e-2c0b1a5a10a2@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

LGTM

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

Marked as reviewed by rriggs (Reviewer).

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


From lancea at openjdk.java.net  Fri Nov 19 17:47:57 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 19 Nov 2021 17:47:57 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <rk3xCjJlKgbIZt3rUi_crNZx2qjbpzB_ylVbpFjrR58=.71b45eb7-a79f-48d7-bd1b-cf541ba99268@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Marked as reviewed by lancea (Reviewer).

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

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


From mchung at openjdk.java.net  Fri Nov 19 18:10:09 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 19 Nov 2021 18:10:09 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <kC6p_fpghxElTgc-b79F7h7YoihJGsBp2lgKMW5HQBY=.c2cad07b-7aca-4ff8-9a85-4c2bdad1cfe4@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

src/java.base/share/classes/java/lang/Object.java line 481:

> 479:      * system resources or to perform other cleanup.
> 480:      * <p>
> 481:      * <b>When running in a Java virtual machine in which finalization has been

Disabling finalization is not part of the Java SE spec.   This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc.

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

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


From darcy at openjdk.java.net  Fri Nov 19 18:10:08 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 19 Nov 2021 18:10:08 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <H67a1T-dtaGUqeKSvlrfRWlTL64nxFUSN6jKOg0gmC4=.15c0752b-dae1-4e6a-8109-1f8478628d8f@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Marked as reviewed by darcy (Reviewer).

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

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


From bchristi at openjdk.java.net  Fri Nov 19 18:19:10 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 19 Nov 2021 18:19:10 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <kC6p_fpghxElTgc-b79F7h7YoihJGsBp2lgKMW5HQBY=.c2cad07b-7aca-4ff8-9a85-4c2bdad1cfe4@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
 <kC6p_fpghxElTgc-b79F7h7YoihJGsBp2lgKMW5HQBY=.c2cad07b-7aca-4ff8-9a85-4c2bdad1cfe4@github.com>
Message-ID: <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com>

On Fri, 19 Nov 2021 18:06:39 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
>> 
>> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
>> 
>> The CSR has been approved.
>> An automated test build+test run passes cleanly (FWIW :D ).
>
> src/java.base/share/classes/java/lang/Object.java line 481:
> 
>> 479:      * system resources or to perform other cleanup.
>> 480:      * <p>
>> 481:      * <b>When running in a Java virtual machine in which finalization has been
> 
> Disabling finalization is not part of the Java SE spec.   This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc.

The coupling between this change and [8276422](https://bugs.openjdk.java.net/browse/JDK-8276422) ("Add command-line option to disable finalization") is probably tighter than would be ideal.  That [CSR](https://bugs.openjdk.java.net/browse/JDK-8276773) allows for finalization to be disabled in the SE Platform Spec and the JLS.

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

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


From serb at openjdk.java.net  Fri Nov 19 19:05:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 19 Nov 2021 19:05:07 GMT
Subject: RFR: JDK-8277396: [TESTBUG] In DefaultButtonModelCrashTest.java, 
 frame is accessed from main thread
In-Reply-To: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
References: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
Message-ID: <MsDhh32IMhRvp-79a6MTkPBOdjk4oDVHpbj6qprtnhg=.a0ac9be6-2615-4b8f-93cd-22f42570debd@github.com>

On Thu, 18 Nov 2021 13:17:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> It's a little cleanup: make sure `frame` is accessed from EDT only, remove unused variables and imports.

Marked as reviewed by serb (Reviewer).

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

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


From duke at openjdk.java.net  Fri Nov 19 19:09:54 2021
From: duke at openjdk.java.net (Jeremy)
Date: Fri, 19 Nov 2021 19:09:54 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v10]
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <W1sc79kkjjEU2gMwVffM-tW9nvdr4hIkRNvWJrkPzXY=.0d9881e6-2761-4fe2-81e3-86abb50fd5ca@github.com>

> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
> 
> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
> B. Updating the unit test to forgive the discrepancy.
> 
> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
> 
> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
> 
> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

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

  8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
  
  Addressing code review feedback: "Use BigDecomal.setScale(40) to ascertain precision."
  
  The geom.* unit tests passed before & after this change.
  
  https://github.com/openjdk/jdk/pull/6227#discussion_r752908494

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6227/files
  - new: https://git.openjdk.java.net/jdk/pull/6227/files/b3e84a5e..76805330

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

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

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


From mchung at openjdk.java.net  Fri Nov 19 19:10:11 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 19 Nov 2021 19:10:11 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <XQEqvCRazxICMGG28AwzLqjpFVc_le_-jemEcxzWWAA=.db4ee046-4961-4c30-8f23-f2ee57cd2ecc@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Marked as reviewed by mchung (Reviewer).

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

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


From mchung at openjdk.java.net  Fri Nov 19 19:10:12 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 19 Nov 2021 19:10:12 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
 <kC6p_fpghxElTgc-b79F7h7YoihJGsBp2lgKMW5HQBY=.c2cad07b-7aca-4ff8-9a85-4c2bdad1cfe4@github.com>
 <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com>
Message-ID: <YfMEhBgRnkNrn9LpnheH8NJNWnS5A7HEnbt_n0046jc=.9c0ccb5a-57a4-4e0e-a237-aac01051d0b3@github.com>

On Fri, 19 Nov 2021 18:15:46 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Object.java line 481:
>> 
>>> 479:      * system resources or to perform other cleanup.
>>> 480:      * <p>
>>> 481:      * <b>When running in a Java virtual machine in which finalization has been
>> 
>> Disabling finalization is not part of the Java SE spec.   This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc.
>
> The coupling between this change and [8276422](https://bugs.openjdk.java.net/browse/JDK-8276422) ("Add command-line option to disable finalization") is probably tighter than would be ideal.  That [CSR](https://bugs.openjdk.java.net/browse/JDK-8276773) allows for finalization to be disabled in the SE Platform Spec and the JLS.

Thanks for pointing out that the CSR for JDK-8276422 ("Add command-line option to disable finalization") includes the change of the SE Platform Spec and JLS to allow an implementation for finalization to be disabled.   This makes senses now.

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

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


From serb at openjdk.java.net  Fri Nov 19 19:29:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 19 Nov 2021 19:29:10 GMT
Subject: RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v3]
In-Reply-To: <evHZiymXk5g7z5wYB2EzoHBx9HTs8xpNHAd3prGDvDc=.3e020003-99ef-4394-96d2-1ab2c7c14dd3@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
 <DZpSTzGC0LcaK9FqwBCGbVIPUle1YEazznQZkfYOm58=.2f864fc5-3804-4180-be13-b7f1c2b5bed3@github.com>
 <0TqXqT-I0fAChKQOB5lDYeIIxG-wqzDjF22lFYWyHC0=.984aefe4-21e4-4fbe-81bf-15a3547d88bf@github.com>
 <evHZiymXk5g7z5wYB2EzoHBx9HTs8xpNHAd3prGDvDc=.3e020003-99ef-4394-96d2-1ab2c7c14dd3@github.com>
Message-ID: <HKGTf-VvaJjNCZVqnE6tXcKquDPkSOSbBeraanlBSP8=.ba21f4cb-82cf-4152-8db4-32674f0fcda6@github.com>

On Thu, 18 Nov 2021 18:32:30 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 463:
>> 
>>> 461:                         new InputStreamReader(is, ISO_8859_1));
>>> 462:                 defaultStyles.loadRules(r, null);
>>> 463:                 r.close();
>> 
>> the reader was not added to the try block, it will not be closed.
>
> updated

What about "new InputStreamReader()" here and below?

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

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


From serb at openjdk.java.net  Fri Nov 19 20:04:11 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 19 Nov 2021 20:04:11 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v4]
In-Reply-To: <icSGKnOryPHI_yd-HKjSmURmjwpfb0joZm533GHrsEo=.231a05f3-31a7-4c31-8aa1-01aa0ea5fe8f@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <icSGKnOryPHI_yd-HKjSmURmjwpfb0joZm533GHrsEo=.231a05f3-31a7-4c31-8aa1-01aa0ea5fe8f@github.com>
Message-ID: <zxNsIG35aBhe9D8ry7rs8s1vnYtqZXcVSj13IGwYPs4=.baeb4de9-3292-4a97-9cc0-f441aebd1b12@github.com>

On Wed, 17 Nov 2021 18:55:20 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added summary and copyright

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 114:

> 112:                 = "\nINSTRUCTIONS:\n"
> 113:                 + "\n   Try to drag the thumb of the scrollbar into the red zone."
> 114:                 + "\n   If the thumb is able to go into the red zone, click fail."

If you place the thumb to the red zone by the code, will it be possible to check that by pixel color?

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

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


From serb at openjdk.java.net  Fri Nov 19 20:10:13 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 19 Nov 2021 20:10:13 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows [v3]
In-Reply-To: <vZdJqlPw_-3v2JnC8K4qxzW8SCwPCvQcbUmy9X4jBRs=.20d73184-0584-4058-8e2d-02d62957592b@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
 <vZdJqlPw_-3v2JnC8K4qxzW8SCwPCvQcbUmy9X4jBRs=.20d73184-0584-4058-8e2d-02d62957592b@github.com>
Message-ID: <bY-gEVcWX21DG0HL70n7Fb4OyJ7mZxd8OAf_mndhzmg=.1772ee3a-0d3a-4a52-8944-150a4482a7aa@github.com>

On Fri, 19 Nov 2021 09:14:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni to an awt related test, and shows on Windows server 2019 the following JNI warning , so the test  JNICheck/FreeTypeScalerJNICheck.java fails on this Windows version.
>> 
>> :stdErr:
>> Thu Oct 28 01:27:10 CEST 2021
>> stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV
>>                at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 18.0.0.1-internal/Native Method)
>>                at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:95)
>>                at sun.awt.Win32GraphicsEnvironment.<clinit>(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:63)
>>                at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 18.0.0.1-internal/PlatformGraphicsInfo.java:34)
>>                at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:93)
>>                at java.awt.GraphicsEnvironment$LocalGE.<clinit>(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:84)
>>                at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:106)
>>                at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53)
>>                at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)
>> 
>> We can get rid of the warning by adjusting a JNU_CallStaticMethodByName call in awt_Win32GraphicsEnv.cpp .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do you run FreeTypeScalerJNICheck.java test on Windows

> I understand that this is about the debug build on Windows only. So why not solve it like this: [d042029](https://github.com/openjdk/jdk/commit/d042029509a8cbdb723f78e2cfee4e2885775814) ?

The current issue does not produce any debug assertions nor try to open a debugger, so it is different. We need to check why the jni warning is produced, probably we call more java methods via jni in the debug build?

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

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


From serb at openjdk.java.net  Fri Nov 19 20:16:12 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 19 Nov 2021 20:16:12 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <ukGuoG0O2Jh8RpaJ-WYcNiWFpAqRXZdiuwKR6w9v9VQ=.07b447cd-6c91-4b5f-86d9-c0be213bb0b7@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Fri Nov 19 20:24:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 19 Nov 2021 20:24:08 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits
In-Reply-To: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
Message-ID: <x4B9ND1o-kKtJl3TtYa_F19b7pz5G8EgmFSYluwY1J0=.ca0d805c-e804-4e3d-a443-ffbbd8164159@github.com>

On Fri, 19 Nov 2021 06:34:30 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Made colorBits and maskBits arrays dynamic so they are allocated on heap instead of stack.
> Added regression test.

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1060:

> 1058:             int nBits = iconSize * iconSize;
> 1059:             long * colorBits;
> 1060:             colorBits = (long*)safe_Malloc(MAX_ICON_SIZE * MAX_ICON_SIZE * sizeof(long));

I am not sure that the bad_alloc will be properly handled in this Java_sun_awt_shell_Win32ShellFolder2_getIconBits method.
+Probably it will be better to merge assigning into one line.

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

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


From aivanov at openjdk.java.net  Fri Nov 19 20:53:10 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 19 Nov 2021 20:53:10 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits
In-Reply-To: <x4B9ND1o-kKtJl3TtYa_F19b7pz5G8EgmFSYluwY1J0=.ca0d805c-e804-4e3d-a443-ffbbd8164159@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
 <x4B9ND1o-kKtJl3TtYa_F19b7pz5G8EgmFSYluwY1J0=.ca0d805c-e804-4e3d-a443-ffbbd8164159@github.com>
Message-ID: <8gMvYVQgH0tVtTzgNCgKeJ5CHzo-Hy4s8Xl-njgH_aM=.57d59bfe-a3e3-4cca-b93a-00a31d628b93@github.com>

On Fri, 19 Nov 2021 20:21:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I am not sure that the bad_alloc will be properly handled in this Java_sun_awt_shell_Win32ShellFolder2_getIconBits method.

I can't see any try-catch.
Is it better to use `malloc` and check for `NULL`?

> Probably it will be better to merge assigning into one line.

I agree. The line doesn't get too long.

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

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


From aivanov at openjdk.java.net  Fri Nov 19 20:53:10 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 19 Nov 2021 20:53:10 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits
In-Reply-To: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
Message-ID: <R3XBf62htFtTsb3kKax634flhj8Euho4Nlh7KTqOzR8=.bb48413a-c2df-4df4-9cdf-3639b45d7433@github.com>

On Fri, 19 Nov 2021 06:34:30 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Made colorBits and maskBits arrays dynamic so they are allocated on heap instead of stack.
> Added regression test.

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1059:

> 1057:             // Extract the color bitmap
> 1058:             int nBits = iconSize * iconSize;
> 1059:             long * colorBits;

Pointer declarations aren't consistent in the file, the function parameter is declared as `JNIEnv* env`. However, in the majority of cases the asterisk is near the variable name as in `const char *pLibName`. In either case, there's only one space:

long *maskBits;

or

long* maskBits;

test/jdk/javax/swing/JFileChooser/FileSystemView/ShellFolderStackOverflow.java line 28:

> 26:  * @bug 8277299
> 27:  * @requires (os.family == "windows")
> 28:  * @summary STACK_OVERFLOW in Java_sun_awt_shell_Win32ShellFolder2_getIconBits

Maybe this could be spelt with regular case rather than caps?

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

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


From serb at openjdk.java.net  Fri Nov 19 20:54:11 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 19 Nov 2021 20:54:11 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v4]
In-Reply-To: <q1CL3FjeQs3GzNh4gKrjzuBAQbCUYc7cUXIGT7hvnvI=.7365f57d-84ca-45d5-a3cd-f6577c244ecf@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <q1CL3FjeQs3GzNh4gKrjzuBAQbCUYc7cUXIGT7hvnvI=.7365f57d-84ca-45d5-a3cd-f6577c244ecf@github.com>
Message-ID: <Z6wz_AAdM7mPPF2v_NyG4Z9ma2ArtAkcHpIvTk3J5nE=.0c031dc3-5605-4744-80b7-57404b82cca3@github.com>

On Fri, 19 Nov 2021 09:04:22 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8262297 bug fixes?
>> 
>> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.
>
> Masanori Yano has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException

I have no other comments.

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

Marked as reviewed by serb (Reviewer).

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


From serb at openjdk.java.net  Fri Nov 19 21:07:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 19 Nov 2021 21:07:07 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits
In-Reply-To: <8gMvYVQgH0tVtTzgNCgKeJ5CHzo-Hy4s8Xl-njgH_aM=.57d59bfe-a3e3-4cca-b93a-00a31d628b93@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
 <x4B9ND1o-kKtJl3TtYa_F19b7pz5G8EgmFSYluwY1J0=.ca0d805c-e804-4e3d-a443-ffbbd8164159@github.com>
 <8gMvYVQgH0tVtTzgNCgKeJ5CHzo-Hy4s8Xl-njgH_aM=.57d59bfe-a3e3-4cca-b93a-00a31d628b93@github.com>
Message-ID: <xVgO3HqGMcnDUnrOfTeOQpGfn2hkgFCevKIjHl32SEw=.d854a285-3f55-4afc-b20f-49ec8eb13ec2@github.com>

On Fri, 19 Nov 2021 20:47:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1060:
>> 
>>> 1058:             int nBits = iconSize * iconSize;
>>> 1059:             long * colorBits;
>>> 1060:             colorBits = (long*)safe_Malloc(MAX_ICON_SIZE * MAX_ICON_SIZE * sizeof(long));
>> 
>> I am not sure that the bad_alloc will be properly handled in this Java_sun_awt_shell_Win32ShellFolder2_getIconBits method.
>> +Probably it will be better to merge assigning into one line.
>
>> I am not sure that the bad_alloc will be properly handled in this Java_sun_awt_shell_Win32ShellFolder2_getIconBits method.
> 
> I can't see any try-catch.
> Is it better to use `malloc` and check for `NULL`?
> 
>> Probably it will be better to merge assigning into one line.
> 
> I agree. The line doesn't get too long.

Probably TRY/CATCH_BAD_ALLOC_RET(NULL); could be used. It depends on how we will clean the stuff on exception.

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

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


From achung at openjdk.java.net  Fri Nov 19 21:13:37 2021
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 19 Nov 2021 21:13:37 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v5]
In-Reply-To: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
Message-ID: <ATJgqWe67jY9hkhcH43jmWbJ8ZrPxFCSLrs6qE7IlK0=.21f24973-23cb-4f48-847c-a3d891170e64@github.com>

> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.

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

  automated test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6374/files
  - new: https://git.openjdk.java.net/jdk/pull/6374/files/58ba8b21..2d4a5fc2

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

  Stats: 138 lines in 1 file changed: 25 ins; 99 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6374.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6374/head:pull/6374

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


From achung at openjdk.java.net  Fri Nov 19 21:40:17 2021
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 19 Nov 2021 21:40:17 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v4]
In-Reply-To: <zxNsIG35aBhe9D8ry7rs8s1vnYtqZXcVSj13IGwYPs4=.baeb4de9-3292-4a97-9cc0-f441aebd1b12@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <icSGKnOryPHI_yd-HKjSmURmjwpfb0joZm533GHrsEo=.231a05f3-31a7-4c31-8aa1-01aa0ea5fe8f@github.com>
 <zxNsIG35aBhe9D8ry7rs8s1vnYtqZXcVSj13IGwYPs4=.baeb4de9-3292-4a97-9cc0-f441aebd1b12@github.com>
Message-ID: <lL2zcy61qbI4QXPWknffRqvgQfU3zS49BvrUQFgrSXE=.fe7927c5-e2fc-4ea5-a852-2773e841de21@github.com>

On Fri, 19 Nov 2021 20:01:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added summary and copyright
>
> test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 114:
> 
>> 112:                 = "\nINSTRUCTIONS:\n"
>> 113:                 + "\n   Try to drag the thumb of the scrollbar into the red zone."
>> 114:                 + "\n   If the thumb is able to go into the red zone, click fail."
> 
> If you place the thumb to the red zone by the code, will it be possible to check that by pixel color?

Just updated the automation. I added a robot to try to move the thumb into the red zone, then had the robot click again to see if the thumb is under the cursor. If the behavior is correct, the thumb should have stopped before entering the red zone and scrollbar mouseListener should only detect 1 click. Otherwise it will detect 2 clicks (thumb is under cursor) and test fails. Is my logic correct?

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

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


From achung at openjdk.java.net  Fri Nov 19 21:48:47 2021
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 19 Nov 2021 21:48:47 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v6]
In-Reply-To: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
Message-ID: <uPkieC2HFRc3_hlLqrEQw27KZyAJlYYYNQ1CULLv4nw=.ed8b6d7a-0e49-40ea-b4e8-8973cc2c488d@github.com>

> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.

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

  removed manual tag

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6374/files
  - new: https://git.openjdk.java.net/jdk/pull/6374/files/2d4a5fc2..02ae001c

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

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

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


From kizune at openjdk.java.net  Sat Nov 20 04:55:08 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 20 Nov 2021 04:55:08 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits
In-Reply-To: <R3XBf62htFtTsb3kKax634flhj8Euho4Nlh7KTqOzR8=.bb48413a-c2df-4df4-9cdf-3639b45d7433@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
 <R3XBf62htFtTsb3kKax634flhj8Euho4Nlh7KTqOzR8=.bb48413a-c2df-4df4-9cdf-3639b45d7433@github.com>
Message-ID: <DOlF_nbO81QesLLeJUwCyB8onpaX2VMS9wZKnRQdNRA=.1dcd695c-a826-43ca-a484-0f664cd787fa@github.com>

On Fri, 19 Nov 2021 20:49:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Maybe this could be spelt with regular case rather than caps?

Well, it is just copy-paste from the bug synopsis which is copy-paste from the error message of the VM crash.

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

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


From kizune at openjdk.java.net  Sat Nov 20 05:03:46 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 20 Nov 2021 05:03:46 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits [v2]
In-Reply-To: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
Message-ID: <eSI-MbnnR26q3Ic8BsE0XbZnC89i-bkpE-1OU5JcB7s=.0f6b3395-c28b-427e-9612-b3bd56187303@github.com>

> Made colorBits and maskBits arrays dynamic so they are allocated on heap instead of stack.
> Added regression test.

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

  Added bad_malloc handling
  Fixed insets
  Declaration and assignment are now joined

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6473/files
  - new: https://git.openjdk.java.net/jdk/pull/6473/files/fa8a4ed7..16d3eadc

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

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

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


From duke at openjdk.java.net  Sat Nov 20 12:09:30 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Sat, 20 Nov 2021 12:09:30 GMT
Subject: RFR: 8277504: Use String.stripTrailing instead of hand-crafted method
 in SwingUtilities2
Message-ID: <xIp8o7KwFhHt3NBX-y6CTG-3on8QKQ9CcjAKfUEE_Zs=.bb12232e-93be-4719-9d00-e2f7e36d2b92@github.com>

There is opportunity to use String.stripTrailing() method in java.desktop in SwingUtilities2 class.

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

Commit messages:
 - [PATCH] Use String.stripTrailing instead of hand-crafted method in SwingUtilities2
 - [PATCH] Use String.stripTrailing instead of hand-crafted method in SwingUtilities2

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

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


From serb at openjdk.java.net  Sat Nov 20 12:09:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 20 Nov 2021 12:09:31 GMT
Subject: RFR: 8277504: Use String.stripTrailing instead of hand-crafted
 method in SwingUtilities2
In-Reply-To: <xIp8o7KwFhHt3NBX-y6CTG-3on8QKQ9CcjAKfUEE_Zs=.bb12232e-93be-4719-9d00-e2f7e36d2b92@github.com>
References: <xIp8o7KwFhHt3NBX-y6CTG-3on8QKQ9CcjAKfUEE_Zs=.bb12232e-93be-4719-9d00-e2f7e36d2b92@github.com>
Message-ID: <1i5BVk8zZGH2IQDtjCz6FKQ5XHzFLQTQumnI94ExbNA=.1dcfcab4-6863-4650-bb0b-e10abfcb067a@github.com>

On Wed, 17 Nov 2021 19:57:19 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> There is opportunity to use String.stripTrailing() method in java.desktop in SwingUtilities2 class.

Probably all those typos can be fixed separately?

Looks fine.

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

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


From duke at openjdk.java.net  Sat Nov 20 12:09:32 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Sat, 20 Nov 2021 12:09:32 GMT
Subject: RFR: 8277504: Use String.stripTrailing instead of hand-crafted
 method in SwingUtilities2
In-Reply-To: <1i5BVk8zZGH2IQDtjCz6FKQ5XHzFLQTQumnI94ExbNA=.1dcfcab4-6863-4650-bb0b-e10abfcb067a@github.com>
References: <xIp8o7KwFhHt3NBX-y6CTG-3on8QKQ9CcjAKfUEE_Zs=.bb12232e-93be-4719-9d00-e2f7e36d2b92@github.com>
 <1i5BVk8zZGH2IQDtjCz6FKQ5XHzFLQTQumnI94ExbNA=.1dcfcab4-6863-4650-bb0b-e10abfcb067a@github.com>
Message-ID: <x-K4FvJADMhQv8RQgH_SM75fQe8WoZHY22aqJ_zZenU=.01fae3a4-70b5-42fe-897f-21645cde07d6@github.com>

On Wed, 17 Nov 2021 20:16:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>Probably all those typos can be fixed separately?

Okay. Reverted them.

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

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


From lmesnik at openjdk.java.net  Sun Nov 21 00:21:07 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Sun, 21 Nov 2021 00:21:07 GMT
Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules
In-Reply-To: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>
References: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>
Message-ID: <7FooviizG1lKmrfgzuXplwxRH3S13gXq3A8LzyZXLak=.685d673a-77a3-41d5-bd62-3d708e47867c@github.com>

On Thu, 9 Sep 2021 06:53:13 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance

Marked as reviewed by lmesnik (Reviewer).

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

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


From jdv at openjdk.java.net  Mon Nov 22 03:05:09 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 22 Nov 2021 03:05:09 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v4]
In-Reply-To: <q1CL3FjeQs3GzNh4gKrjzuBAQbCUYc7cUXIGT7hvnvI=.7365f57d-84ca-45d5-a3cd-f6577c244ecf@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <q1CL3FjeQs3GzNh4gKrjzuBAQbCUYc7cUXIGT7hvnvI=.7365f57d-84ca-45d5-a3cd-f6577c244ecf@github.com>
Message-ID: <5dWUn5R2pVmxg5Ored-sSYXjE32QbUq_LlJPuQxWgl4=.c0164d27-47cd-4d2c-ada7-192a7e8db2df@github.com>

On Fri, 19 Nov 2021 09:04:22 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8262297 bug fixes?
>> 
>> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.
>
> Masanori Yano has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException

Marked as reviewed by jdv (Reviewer).

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

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


From pbansal at openjdk.java.net  Mon Nov 22 06:18:05 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 22 Nov 2021 06:18:05 GMT
Subject: RFR: 8264297: Create implementation for
 NSAccessibilityProgressIndicator protocol peer
In-Reply-To: <CUGVr_lRTIwtyltf5LiQvze9IwUoasByQ1dpQmSZwNA=.25e7c41d-0ae3-49cf-9cce-bea175d12939@github.com>
References: <CUGVr_lRTIwtyltf5LiQvze9IwUoasByQ1dpQmSZwNA=.25e7c41d-0ae3-49cf-9cce-bea175d12939@github.com>
Message-ID: <-sm1uRpSVnF2JlNBZLYvonymgGCApSdiJmuxtE2c0YY=.245ded7e-77bb-4efa-bc8f-a6b22363a3d9@github.com>

On Thu, 18 Nov 2021 19:04:05 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add component accessibility peer

looks good to me

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

Marked as reviewed by pbansal (Reviewer).

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


From pbansal at openjdk.java.net  Mon Nov 22 06:52:02 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 22 Nov 2021 06:52:02 GMT
Subject: RFR: 8277504: Use String.stripTrailing instead of hand-crafted
 method in SwingUtilities2
In-Reply-To: <xIp8o7KwFhHt3NBX-y6CTG-3on8QKQ9CcjAKfUEE_Zs=.bb12232e-93be-4719-9d00-e2f7e36d2b92@github.com>
References: <xIp8o7KwFhHt3NBX-y6CTG-3on8QKQ9CcjAKfUEE_Zs=.bb12232e-93be-4719-9d00-e2f7e36d2b92@github.com>
Message-ID: <8wyHcIQFR9gaAJuWl2Ooqjc9e0205P60tH2gDzjbVsU=.87df2e29-6d9f-475d-aead-595fb68af225@github.com>

On Wed, 17 Nov 2021 19:57:19 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> There is opportunity to use String.stripTrailing() method in java.desktop in SwingUtilities2 class.

Marked as reviewed by pbansal (Reviewer).

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

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


From serb at openjdk.java.net  Mon Nov 22 07:13:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 22 Nov 2021 07:13:05 GMT
Subject: RFR: 8277504: Use String.stripTrailing instead of hand-crafted
 method in SwingUtilities2
In-Reply-To: <xIp8o7KwFhHt3NBX-y6CTG-3on8QKQ9CcjAKfUEE_Zs=.bb12232e-93be-4719-9d00-e2f7e36d2b92@github.com>
References: <xIp8o7KwFhHt3NBX-y6CTG-3on8QKQ9CcjAKfUEE_Zs=.bb12232e-93be-4719-9d00-e2f7e36d2b92@github.com>
Message-ID: <6HG3nR-D61pmk8wwuT6ewty3Mxh-2JHpj7Vnl03Rm6w=.ebfe2177-6b58-4fc4-92ad-233eada6abdf@github.com>

On Wed, 17 Nov 2021 19:57:19 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> There is opportunity to use String.stripTrailing() method in java.desktop in SwingUtilities2 class.

Marked as reviewed by serb (Reviewer).

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

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


From myano at openjdk.java.net  Mon Nov 22 09:21:08 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 22 Nov 2021 09:21:08 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
Message-ID: <iL2ceXU-6LZM4H_0iiBSm77YjXcZjEbseVCqDm1LpwU=.181a2936-6a95-477e-9013-196a799a415f@github.com>

On Thu, 28 Oct 2021 08:27:44 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8275715 bug fixes?
>> 
>> I think D3DScreenUpdateManager posts unnecessary PaintEvent during processing PaintEvent. When the validate method is called from createGraphics, repaintPeerTarget should not be called.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8275715: D3D pipeline processes multiple PaintEvent at initial drawing

@mrserb The fixes in JDK-8270874 have been integrated, so please review this PR again.

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

PR: https://git.openjdk.java.net/jdk/pull/6064


From myano at openjdk.java.net  Mon Nov 22 09:37:10 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 22 Nov 2021 09:37:10 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails [v2]
In-Reply-To: <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>
 <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
Message-ID: <M9uOlkO5b1_YouQdxPNdiPklFHmRDUFLJLDtWhDwAbI=.b0bfd42d-c458-4f9a-97db-70d9855441b5@github.com>

On Tue, 26 Oct 2021 04:52:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Masanori Yano 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:
>> 
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - Merge branch 'master' of https://github.com/masyano/jdk into 7001973
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>
> I'll check it, let me some time.

@mrserb Could you please reply to the above comment?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5491


From kizune at openjdk.java.net  Mon Nov 22 18:30:45 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 22 Nov 2021 18:30:45 GMT
Subject: Integrated: 8264297: Create implementation for
 NSAccessibilityProgressIndicator protocol peer
In-Reply-To: <CUGVr_lRTIwtyltf5LiQvze9IwUoasByQ1dpQmSZwNA=.25e7c41d-0ae3-49cf-9cce-bea175d12939@github.com>
References: <CUGVr_lRTIwtyltf5LiQvze9IwUoasByQ1dpQmSZwNA=.25e7c41d-0ae3-49cf-9cce-bea175d12939@github.com>
Message-ID: <218U4QsNrlZ7x4eFObq_oIfRmjyXh5X-XZkht3jM05A=.4f9f5207-cc0b-4636-a377-3fe67fede3d4@github.com>

On Thu, 18 Nov 2021 19:04:05 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add component accessibility peer

This pull request has now been integrated.

Changeset: 851a3624
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/851a36247937d124e8217deaaa1a1831cba19b6e
Stats:     48 lines in 3 files changed: 46 ins; 0 del; 2 mod

8264297: Create implementation for NSAccessibilityProgressIndicator protocol peer

Reviewed-by: pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/6462


From aivanov at openjdk.java.net  Mon Nov 22 19:16:09 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 22 Nov 2021 19:16:09 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits [v2]
In-Reply-To: <eSI-MbnnR26q3Ic8BsE0XbZnC89i-bkpE-1OU5JcB7s=.0f6b3395-c28b-427e-9612-b3bd56187303@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
 <eSI-MbnnR26q3Ic8BsE0XbZnC89i-bkpE-1OU5JcB7s=.0f6b3395-c28b-427e-9612-b3bd56187303@github.com>
Message-ID: <MQgleFlF0fjC7LpAsyLD7g-ok0uCqyGSihb3t-E8ybo=.7e85045f-e327-45f7-8634-ae88edf0df4f@github.com>

On Sat, 20 Nov 2021 05:03:46 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Made colorBits and maskBits arrays dynamic so they are allocated on heap instead of stack.
>> Added regression test.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added bad_malloc handling
>   Fixed insets
>   Declaration and assignment are now joined

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1097:

> 1095:             free(colorBits);
> 1096: 
> 1097:             CATCH_BAD_ALLOC_RET(NULL);

I believe we leak `dc` as well as `iconInfo.hbmColor` and `iconInfo.hbmMask` if `std::bad_alloc` is thrown.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6473


From aivanov at openjdk.java.net  Mon Nov 22 19:40:58 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 22 Nov 2021 19:40:58 GMT
Subject: RFR: JDK-8277396: [TESTBUG] In DefaultButtonModelCrashTest.java, 
 frame is accessed from main thread [v2]
In-Reply-To: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
References: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
Message-ID: <K7Gj-wDBZ7zWmXO2RN1mwGFWNAxFScfkO1f3V8m8S5s=.8037284e-9556-4424-843e-f1268f18bcd6@github.com>

> It's a little cleanup: make sure `frame` is accessed from EDT only, remove unused variables and imports.

Alexey Ivanov has updated the pull request incrementally with three additional commits since the last revision:

 - Re-grouped UI creation code for clarity
 - Clarified test description
 - Add 1 sec delay after showing frame

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6455/files
  - new: https://git.openjdk.java.net/jdk/pull/6455/files/c637f86c..200909ad

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6455&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6455&range=00-01

  Stats: 10 lines in 1 file changed: 5 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6455.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6455/head:pull/6455

PR: https://git.openjdk.java.net/jdk/pull/6455


From aivanov at openjdk.java.net  Mon Nov 22 19:40:59 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 22 Nov 2021 19:40:59 GMT
Subject: RFR: JDK-8277396: [TESTBUG] In DefaultButtonModelCrashTest.java, 
 frame is accessed from main thread
In-Reply-To: <UoxS-cjKbOJw2q1ItHyX9gg5dzPuAoL7NAdnSQYhwn8=.2e4ee68c-3953-44fd-8fb2-5f5d95e0c94a@github.com>
References: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
 <UoxS-cjKbOJw2q1ItHyX9gg5dzPuAoL7NAdnSQYhwn8=.2e4ee68c-3953-44fd-8fb2-5f5d95e0c94a@github.com>
Message-ID: <crFMNO_OFinXRYkUPshEcwltLD0bY6H7S_Hwnm2rrDY=.90c40958-30f7-463f-a6e5-e6a19c5d1ff2@github.com>

On Fri, 19 Nov 2021 05:22:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I am not sure on this as those 100+ tests which accesses frame variable outside EDT before it calls dispose is not failing in CI testing and also locally so to modify this particular test only does not make sense to me.
Most tests are short-lived, that's probably the reason why it doesn't cause any issues. Yet it doesn't mean that it's the way it should be.

My point is that JDK regression tests could be used as a sample code for writing Swing code. That is JDK code as well as its tests should be a role model.

I wouldn't commit into fixing all 100+ tests: it requires a considerable amount of time and effort. However, I consider fixing them one by one is a good thing to do. I spent around 15-20 minutes on this issue, including submitting it and raising code review. I admit both of us have wasted more time discussing whether it's worth integrating?

> If you still want to take it forward, regarding the test, I will request to add a delay of 1sec after l56 after we make the frame visible, same way we normally do for other swing reg tests.

I added 1 sec delay in the latest iteration of the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6455


From psadhukhan at openjdk.java.net  Tue Nov 23 06:48:16 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 23 Nov 2021 06:48:16 GMT
Subject: RFR: JDK-8277396: [TESTBUG] In DefaultButtonModelCrashTest.java, 
 frame is accessed from main thread [v2]
In-Reply-To: <K7Gj-wDBZ7zWmXO2RN1mwGFWNAxFScfkO1f3V8m8S5s=.8037284e-9556-4424-843e-f1268f18bcd6@github.com>
References: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
 <K7Gj-wDBZ7zWmXO2RN1mwGFWNAxFScfkO1f3V8m8S5s=.8037284e-9556-4424-843e-f1268f18bcd6@github.com>
Message-ID: <CrYY8RxJeaf7IUirVWQxi4AVTxTUyiKIeqbTW5OA3ZM=.6b0280fa-9120-4530-8ff2-c6c7e6953404@github.com>

On Mon, 22 Nov 2021 19:40:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It's a little cleanup: make sure `frame` is accessed from EDT only, remove unused variables and imports.
>
> Alexey Ivanov has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Re-grouped UI creation code for clarity
>  - Clarified test description
>  - Add 1 sec delay after showing frame

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6455


From jdv at openjdk.java.net  Tue Nov 23 11:13:25 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 23 Nov 2021 11:13:25 GMT
Subject: RFR: 8266435: WBMPImageReader.read() should not truncate the input
 stream
Message-ID: <dgFDpOpF6ONZCwgc9eJxvqQcESf8-WmmLAi4eHNeJjg=.33280dd0-fbff-4fa7-a90f-d6b9d7f35225@github.com>

If we use a custom stream and specify limit on stream.read() length, WBMPImageReader.read() doesnt verify whether we are decoded complete data or not. We can check the length of data decoded and rerun the stream.read() or use readFully(). In case of other decoders like BMP we are using readFully(), so i have updated WBMPImageReader.read() to use readFully().

-------------

Commit messages:
 - 8266435: WBMPImageReader.read() should not truncate the input stream

Changes: https://git.openjdk.java.net/jdk/pull/6518/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6518&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266435
  Stats: 122 lines in 2 files changed: 118 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6518.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6518/head:pull/6518

PR: https://git.openjdk.java.net/jdk/pull/6518


From jdv at openjdk.java.net  Tue Nov 23 11:18:10 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 23 Nov 2021 11:18:10 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v4]
In-Reply-To: <q1CL3FjeQs3GzNh4gKrjzuBAQbCUYc7cUXIGT7hvnvI=.7365f57d-84ca-45d5-a3cd-f6577c244ecf@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <q1CL3FjeQs3GzNh4gKrjzuBAQbCUYc7cUXIGT7hvnvI=.7365f57d-84ca-45d5-a3cd-f6577c244ecf@github.com>
Message-ID: <yDZsksuaH9IYSiOlT_t20jAYdeh023Pn7-QpVo7nXSM=.a2d702fe-4f03-45df-95c3-b354cfc4bec8@github.com>

On Fri, 19 Nov 2021 09:04:22 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8262297 bug fixes?
>> 
>> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.
>
> Masanori Yano has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException

test/jdk/javax/imageio/plugins/bmp/BMPBitsPerPixelTest.java line 62:

> 60:             }
> 61:             BufferedImage img = new BufferedImage(10, 10, imageType, (IndexColorModel)cm);
> 62:             ImageIO.write(img, "BMP", new File("test.bmp"));

Just noticed before sponsoring that this test will leave test.bmp file.
We should create temporary file and delete it on exit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6151


From jdv at openjdk.java.net  Tue Nov 23 11:34:09 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 23 Nov 2021 11:34:09 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v4]
In-Reply-To: <q1CL3FjeQs3GzNh4gKrjzuBAQbCUYc7cUXIGT7hvnvI=.7365f57d-84ca-45d5-a3cd-f6577c244ecf@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <q1CL3FjeQs3GzNh4gKrjzuBAQbCUYc7cUXIGT7hvnvI=.7365f57d-84ca-45d5-a3cd-f6577c244ecf@github.com>
Message-ID: <lko_aSjTQOyXLE6C8mpHYsDAEG8fCvqOYplk1hc5_B0=.b7f1e669-b8cf-456d-801a-57fecdf0a191@github.com>

On Fri, 19 Nov 2021 09:04:22 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8262297 bug fixes?
>> 
>> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.
>
> Masanori Yano has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException

Changes requested by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6151


From jdv at openjdk.java.net  Tue Nov 23 11:34:10 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 23 Nov 2021 11:34:10 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v4]
In-Reply-To: <yDZsksuaH9IYSiOlT_t20jAYdeh023Pn7-QpVo7nXSM=.a2d702fe-4f03-45df-95c3-b354cfc4bec8@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <q1CL3FjeQs3GzNh4gKrjzuBAQbCUYc7cUXIGT7hvnvI=.7365f57d-84ca-45d5-a3cd-f6577c244ecf@github.com>
 <yDZsksuaH9IYSiOlT_t20jAYdeh023Pn7-QpVo7nXSM=.a2d702fe-4f03-45df-95c3-b354cfc4bec8@github.com>
Message-ID: <ZLVf7awFb1SHm6Xtz3ujo9BkVyquOXGADgZGIiJBc8o=.8143d4d4-1a5a-4e8d-9c82-165d4798fdb7@github.com>

On Tue, 23 Nov 2021 11:14:09 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Masanori Yano has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
>>  - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
>
> test/jdk/javax/imageio/plugins/bmp/BMPBitsPerPixelTest.java line 62:
> 
>> 60:             }
>> 61:             BufferedImage img = new BufferedImage(10, 10, imageType, (IndexColorModel)cm);
>> 62:             ImageIO.write(img, "BMP", new File("test.bmp"));
> 
> Just noticed before sponsoring that this test will leave test.bmp file.
> We should create temporary file and delete it on exit.

I am withdrawing my approval, since this needs to be fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6151


From avu at openjdk.java.net  Tue Nov 23 19:47:22 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 23 Nov 2021 19:47:22 GMT
Subject: RFR: 8272392 Lanai: SwingSet2. Black background on expanding tree node
Message-ID: <j43XsVmt-JoPBbf2zmSprcycbHlkZF2GSBXas3T7BRk=.fcee72ac-9edf-423d-b71d-89612e6d2e52@github.com>

Removed creation of the separate encoder depending on destination properties as we don't use this info to customize the encoder properties

-------------

Commit messages:
 - 8272392 Lanai: SwingSet2. Black background on expanding tree node

Changes: https://git.openjdk.java.net/jdk/pull/6529/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6529&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272392
  Stats: 66 lines in 6 files changed: 12 ins; 19 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6529.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6529/head:pull/6529

PR: https://git.openjdk.java.net/jdk/pull/6529


From duke at openjdk.java.net  Tue Nov 23 20:52:40 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Nov 2021 20:52:40 GMT
Subject: RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v4]
In-Reply-To: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
Message-ID: <4-SKWxMIwTELnjjaNtCMiLopBp2n1-vpCPnEl4Gst6s=.e04c81b2-d0ed-4366-9b5b-f3eac4a660a5@github.com>

> 8274893: Update java.desktop classes to use try-with-resources

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8274893: Update java.desktop classes to use try-with-resources
  close nested streams too to unify code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5817/files
  - new: https://git.openjdk.java.net/jdk/pull/5817/files/19ced6d9..483b0cfd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5817&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5817&range=02-03

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5817.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5817/head:pull/5817

PR: https://git.openjdk.java.net/jdk/pull/5817


From duke at openjdk.java.net  Tue Nov 23 20:52:41 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Nov 2021 20:52:41 GMT
Subject: RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v4]
In-Reply-To: <HKGTf-VvaJjNCZVqnE6tXcKquDPkSOSbBeraanlBSP8=.ba21f4cb-82cf-4152-8db4-32674f0fcda6@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
 <DZpSTzGC0LcaK9FqwBCGbVIPUle1YEazznQZkfYOm58=.2f864fc5-3804-4180-be13-b7f1c2b5bed3@github.com>
 <0TqXqT-I0fAChKQOB5lDYeIIxG-wqzDjF22lFYWyHC0=.984aefe4-21e4-4fbe-81bf-15a3547d88bf@github.com>
 <evHZiymXk5g7z5wYB2EzoHBx9HTs8xpNHAd3prGDvDc=.3e020003-99ef-4394-96d2-1ab2c7c14dd3@github.com>
 <HKGTf-VvaJjNCZVqnE6tXcKquDPkSOSbBeraanlBSP8=.ba21f4cb-82cf-4152-8db4-32674f0fcda6@github.com>
Message-ID: <6ViRv9hu4_EDbUi5PqA54VwCOnkyluV9mK3E8EDwOco=.5c01f75d-4533-445f-8a30-4f140ee31039@github.com>

On Fri, 19 Nov 2021 19:24:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> updated
>
> What about "new InputStreamReader()" here and below?

added it to `try` too

-------------

PR: https://git.openjdk.java.net/jdk/pull/5817


From serb at openjdk.java.net  Wed Nov 24 06:11:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 24 Nov 2021 06:11:07 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v4]
In-Reply-To: <lL2zcy61qbI4QXPWknffRqvgQfU3zS49BvrUQFgrSXE=.fe7927c5-e2fc-4ea5-a852-2773e841de21@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <icSGKnOryPHI_yd-HKjSmURmjwpfb0joZm533GHrsEo=.231a05f3-31a7-4c31-8aa1-01aa0ea5fe8f@github.com>
 <zxNsIG35aBhe9D8ry7rs8s1vnYtqZXcVSj13IGwYPs4=.baeb4de9-3292-4a97-9cc0-f441aebd1b12@github.com>
 <lL2zcy61qbI4QXPWknffRqvgQfU3zS49BvrUQFgrSXE=.fe7927c5-e2fc-4ea5-a852-2773e841de21@github.com>
Message-ID: <heJWxX2cWSgjLWJPo2p-AJEoLSONuHy3xsiU1z6gEPA=.da4827c5-ee15-43ab-a3fd-3847ea5b6ed5@github.com>

On Fri, 19 Nov 2021 21:36:57 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 114:
>> 
>>> 112:                 = "\nINSTRUCTIONS:\n"
>>> 113:                 + "\n   Try to drag the thumb of the scrollbar into the red zone."
>>> 114:                 + "\n   If the thumb is able to go into the red zone, click fail."
>> 
>> If you place the thumb to the red zone by the code, will it be possible to check that by pixel color?
>
> Just updated the automation. I added a robot to try to move the thumb into the red zone, then had the robot click again to see if the thumb is under the cursor. If the behavior is correct, the thumb should have stopped before entering the red zone and scrollbar mouseListener should only detect 1 click. Otherwise it will detect 2 clicks (thumb is under cursor) and test fails. Is my logic correct?

But it is not necessary to use the robot at all? Can you try to set the scollbar thumb position/move it programmatically w/o a robot? If it is possible then it will be rendered on top of the red area -> it will be possible to render it to the buffered image and just check the pixel in the right position(is it red or not).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6374


From serb at openjdk.java.net  Wed Nov 24 06:14:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 24 Nov 2021 06:14:08 GMT
Subject: RFR: 8266435: WBMPImageReader.read() should not truncate the input
 stream
In-Reply-To: <dgFDpOpF6ONZCwgc9eJxvqQcESf8-WmmLAi4eHNeJjg=.33280dd0-fbff-4fa7-a90f-d6b9d7f35225@github.com>
References: <dgFDpOpF6ONZCwgc9eJxvqQcESf8-WmmLAi4eHNeJjg=.33280dd0-fbff-4fa7-a90f-d6b9d7f35225@github.com>
Message-ID: <iX8wG24aLcf6odMvzqK3l6ovs9TFiQ7TrQw9EhJRb5s=.0b5d794f-d84b-4c11-a603-8d7abb7ff93f@github.com>

On Tue, 23 Nov 2021 11:05:27 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> If we use a custom stream and specify limit on stream.read() length, WBMPImageReader.read() doesnt verify whether we are decoded complete data or not. We can check the length of data decoded and rerun the stream.read() or use readFully(). In case of other decoders like BMP we are using readFully(), so i have updated WBMPImageReader.read() to use readFully().

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6518


From myano at openjdk.java.net  Wed Nov 24 11:09:42 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 24 Nov 2021 11:09:42 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v5]
In-Reply-To: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
Message-ID: <U2NwWg-Qzc6gjAUIPs_v-B14fG4UPFPd0ELpAfw-xkU=.de144f74-eb1c-47b5-a198-245566b1d81e@github.com>

> Could you please review the 8262297 bug fixes?
> 
> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.

Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:

  8262297: ImageIO.write() method will throw IndexOutOfBoundsException

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6151/files
  - new: https://git.openjdk.java.net/jdk/pull/6151/files/22b82942..9d0f386a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6151&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6151&range=03-04

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6151/head:pull/6151

PR: https://git.openjdk.java.net/jdk/pull/6151


From myano at openjdk.java.net  Wed Nov 24 11:09:45 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 24 Nov 2021 11:09:45 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v4]
In-Reply-To: <ZLVf7awFb1SHm6Xtz3ujo9BkVyquOXGADgZGIiJBc8o=.8143d4d4-1a5a-4e8d-9c82-165d4798fdb7@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <q1CL3FjeQs3GzNh4gKrjzuBAQbCUYc7cUXIGT7hvnvI=.7365f57d-84ca-45d5-a3cd-f6577c244ecf@github.com>
 <yDZsksuaH9IYSiOlT_t20jAYdeh023Pn7-QpVo7nXSM=.a2d702fe-4f03-45df-95c3-b354cfc4bec8@github.com>
 <ZLVf7awFb1SHm6Xtz3ujo9BkVyquOXGADgZGIiJBc8o=.8143d4d4-1a5a-4e8d-9c82-165d4798fdb7@github.com>
Message-ID: <JwXIGZf_6bMJjVfd6jJEniTsoyyMphGgjTkVQcSldXs=.da2f001e-69dc-4fe5-8b1f-70d4e18c46e9@github.com>

On Tue, 23 Nov 2021 11:30:40 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> test/jdk/javax/imageio/plugins/bmp/BMPBitsPerPixelTest.java line 62:
>> 
>>> 60:             }
>>> 61:             BufferedImage img = new BufferedImage(10, 10, imageType, (IndexColorModel)cm);
>>> 62:             ImageIO.write(img, "BMP", new File("test.bmp"));
>> 
>> Just noticed before sponsoring that this test will leave test.bmp file.
>> We should create temporary file and delete it on exit.
>
> I am withdrawing my approval, since this needs to be fixed.

I fixed it to use createTempFile and deleteOnExit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6151


From alexsch at openjdk.java.net  Wed Nov 24 12:30:11 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Wed, 24 Nov 2021 12:30:11 GMT
Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v3]
In-Reply-To: <aUa1XLjw8b49-HzpaZAEO76vM4hAC9WR2iNjoooljmU=.3fb94a6b-2246-42d4-b87c-534ef06e6585@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
 <aUa1XLjw8b49-HzpaZAEO76vM4hAC9WR2iNjoooljmU=.3fb94a6b-2246-42d4-b87c-534ef06e6585@github.com>
Message-ID: <y--c3Wcu8NVmCIhpY-NxhKswRN7absiC9IodB38l39M=.ae62a51a-f144-4762-9734-38feb3b827a1@github.com>

On Tue, 24 Aug 2021 15:49:00 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
>> 
>> Create a native macOS app from the Hello.java file, sign and run it in sandbox:
>> 
>> import javax.print.*;
>> import javax.swing.*;
>> 
>> public class Hello {
>> 
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeAndWait(() -> {
>>             boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null;
>>             PrintService defaultPrinter = PrintServiceLookup.lookupDefaultPrintService();
>>             PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null);
>> 
>>             StringBuilder builder = new StringBuilder();
>>             builder.append("is sandboxed: ").append(isSandboxed).append("\n");
>>             builder.append("default printer: ").append(defaultPrinter).append("\n");
>>             int size = services.length;
>>             for (int i = 0; i < size; i++) {
>>                 builder.append("printer[").append(i).append("]=").append(services[i]).append("\n");
>>             }
>>             JOptionPane.showMessageDialog(null, builder.toString());
>>         });
>>     }
>> }
>> 
>> The signed app in sandbox shows null default printer and PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp".
>> ![PrintSandboxedApp](https://bugs.openjdk.java.net/secure/attachment/95629/PrintSandboxedApp.png)
>> 
>> The problem has been discussed on  2d-dev mail list:
>>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html
>>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html
>> 
>> According to the discussion:
>> 
>>> I've submitted a DTS incident to Apple and a friend there has followed-up.
>>> Their unofficial position is that java should be connecting to the cups interface returned
>>> by the cupsServer() function and not changing the interface string to "localhost".
>>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>>> network-client access with print access.  They don't seem interested in loosening that change.
>> 
>> 
>> The proposed solution is to use the domain socket pathname in httpConnect(...) cups function and cupsGetDests(...) to get list of printers from cups  when the app is signed and is run in sandbox on MacOs.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Return null if printers are not found in sandboxed app on MacOS

Just a question. Should the fix have 2 reviewers?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4861


From jdv at openjdk.java.net  Wed Nov 24 14:42:09 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 24 Nov 2021 14:42:09 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v5]
In-Reply-To: <U2NwWg-Qzc6gjAUIPs_v-B14fG4UPFPd0ELpAfw-xkU=.de144f74-eb1c-47b5-a198-245566b1d81e@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <U2NwWg-Qzc6gjAUIPs_v-B14fG4UPFPd0ELpAfw-xkU=.de144f74-eb1c-47b5-a198-245566b1d81e@github.com>
Message-ID: <vRxoctVyVDsSXdAxOFxMCMpk6eNtWyeJxAmFL7Eh_Ns=.5b1229a2-50d0-4d57-b2e3-45b882597eb2@github.com>

On Wed, 24 Nov 2021 11:09:42 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8262297 bug fixes?
>> 
>> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8262297: ImageIO.write() method will throw IndexOutOfBoundsException

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6151


From asemenov at openjdk.java.net  Wed Nov 24 15:27:22 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Wed, 24 Nov 2021 15:27:22 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty cell
Message-ID: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>

Testing https://bugs.openjdk.java.net/browse/JDK-8271071 
Step to reproduce 
1) Run SwingSet2 in JDK 18 ( I used b24 ) 
2) Enable Voiceover. 
3) Select JTable demo 
4) Click any row in the table or select the first row . Observe that row is selected & VoiceOver reads the column values or navigate the columns one by one by pressing tab key. When the focus reaches the last column ( Favourite Food ) Observe that column value is read as null. If you hear the same then the bug is reproduced.

-------------

Commit messages:
 - 8277497 Last column cell in the JTAble row is read as empty cell

Changes: https://git.openjdk.java.net/jdk/pull/6538/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6538&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277497
  Stats: 21 lines in 2 files changed: 12 ins; 8 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6538.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6538/head:pull/6538

PR: https://git.openjdk.java.net/jdk/pull/6538


From ant at openjdk.java.net  Wed Nov 24 16:04:10 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Wed, 24 Nov 2021 16:04:10 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell
In-Reply-To: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
Message-ID: <OoJPIG8nsnn6I8Yu-bA2fxLXC0qmc56-8WVHXHPSwcI=.f3dfb992-26aa-420d-9eeb-3f5a1c279a6f@github.com>

On Wed, 24 Nov 2021 15:16:54 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> Testing https://bugs.openjdk.java.net/browse/JDK-8271071 
> Step to reproduce 
> 1) Run SwingSet2 in JDK 18 ( I used b24 ) 
> 2) Enable Voiceover. 
> 3) Select JTable demo 
> 4) Click any row in the table or select the first row . Observe that row is selected & VoiceOver reads the column values or navigate the columns one by one by pressing tab key. When the focus reaches the last column ( Favourite Food ) Observe that column value is read as null. If you hear the same then the bug is reproduced.

src/java.desktop/share/classes/javax/swing/JLabel.java line 1083:

> 1081:                 name = super.getAccessibleName();
> 1082:             }
> 1083: 

Please remove the extra line.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6538


From duke at openjdk.java.net  Wed Nov 24 20:59:09 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 24 Nov 2021 20:59:09 GMT
Subject: RFR: 8274640: Cleanup unnecessary null comparison before
 instanceof check in java.desktop
In-Reply-To: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
Message-ID: <CYMTaWsxy2D8Z0X3M0nuL_7eCFqSAjnpJGRUiw2Jo1w=.e1c97b62-cb29-4597-b91d-e2f0edb3bb9c@github.com>

On Sat, 11 Sep 2021 14:59:21 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Updated code checks both non-null and instance of a class in java.desktop module classes.
> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. 
> Similar cleanups
> 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming
> 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base

not yet, bot

-------------

PR: https://git.openjdk.java.net/jdk/pull/5482


From serb at openjdk.java.net  Thu Nov 25 03:57:03 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 25 Nov 2021 03:57:03 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell
In-Reply-To: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
Message-ID: <FaRdPReanZ4yCDyfLPQnZNjHZGCxtx9YNoDRssy1P-w=.3a819ed2-7b6c-45db-ac4f-3f196103953e@github.com>

On Wed, 24 Nov 2021 15:16:54 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> Testing https://bugs.openjdk.java.net/browse/JDK-8271071 
> Step to reproduce 
> 1) Run SwingSet2 in JDK 18 ( I used b24 ) 
> 2) Enable Voiceover. 
> 3) Select JTable demo 
> 4) Click any row in the table or select the first row . Observe that row is selected & VoiceOver reads the column values or navigate the columns one by one by pressing tab key. When the focus reaches the last column ( Favourite Food ) Observe that column value is read as null. If you hear the same then the bug is reproduced.

src/java.desktop/share/classes/javax/swing/JLabel.java line 1091:

> 1089:                     (JLabel.this.getIcon() != null)) {
> 1090:                 name = ResourceBundle.getBundle("com.sun.accessibility.internal.resources.accessibility", Locale.getDefault()).getString("image");
> 1091:             }

Probably it should somehow ask the icon itself about possible description? I guess the JLabel should work similar to Icon/ImageIcon/AccessibleImageIcon/etc when the text is empty but the icon is set. But I am not sure that the iicons are supported by the a11y in Swing, for example how the reader will cover the simple Icon? Will it say something?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6538


From serb at openjdk.java.net  Thu Nov 25 04:00:02 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 25 Nov 2021 04:00:02 GMT
Subject: RFR: 8266435: WBMPImageReader.read() should not truncate the input
 stream
In-Reply-To: <dgFDpOpF6ONZCwgc9eJxvqQcESf8-WmmLAi4eHNeJjg=.33280dd0-fbff-4fa7-a90f-d6b9d7f35225@github.com>
References: <dgFDpOpF6ONZCwgc9eJxvqQcESf8-WmmLAi4eHNeJjg=.33280dd0-fbff-4fa7-a90f-d6b9d7f35225@github.com>
Message-ID: <icd3sXDFOf8TQx78hDgO9wULkZ0ah_yVrNvrQESsB0k=.f091df72-107b-4208-b651-9e142b60665e@github.com>

On Tue, 23 Nov 2021 11:05:27 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> If we use a custom stream and specify limit on stream.read() length, WBMPImageReader.read() doesnt verify whether we are decoded complete data or not. We can check the length of data decoded and rerun the stream.read() or use readFully(). In case of other decoders like BMP we are using readFully(), so i have updated WBMPImageReader.read() to use readFully().

test/jdk/javax/imageio/plugins/wbmp/WBMPStreamTruncateTest.java line 61:

> 59:         File imageFile = File.
> 60:                 createTempFile("test", ".wbmp", new File(filePath));
> 61:         imageFile.deleteOnExit();

In one another review I saw the deleteOnExit() usage, I remember that in case of full testrun via makefile, such files were not deleted, can you please confirm that it is work fine? probably it that was fixed already. Note that the full test run uses custom tmp folder inside the result dir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6518


From asemenov at openjdk.java.net  Thu Nov 25 08:32:39 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Thu, 25 Nov 2021 08:32:39 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v2]
In-Reply-To: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
Message-ID: <5LVMIj717WA-2s6QInJNjYxjtxfw2JYHS8Fjq6diV9M=.7f702dc0-5317-4cda-9798-5a45d310806c@github.com>

> Testing https://bugs.openjdk.java.net/browse/JDK-8271071 
> Step to reproduce 
> 1) Run SwingSet2 in JDK 18 ( I used b24 ) 
> 2) Enable Voiceover. 
> 3) Select JTable demo 
> 4) Click any row in the table or select the first row . Observe that row is selected & VoiceOver reads the column values or navigate the columns one by one by pressing tab key. When the focus reaches the last column ( Favourite Food ) Observe that column value is read as null. If you hear the same then the bug is reproduced.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  Probably it should somehow ask the icon itself about possible description? I guess the JLabel should work similar to Icon/ImageIcon/AccessibleImageIcon/etc when the text is empty but the icon is set. But I am not sure that the iicons are supported by the a11y in Swing, for example how the reader will cover the simple Icon? Will it say something?

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6538/files
  - new: https://git.openjdk.java.net/jdk/pull/6538/files/09d3fa57..8ea5d093

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6538&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6538&range=00-01

  Stats: 11 lines in 1 file changed: 8 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6538.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6538/head:pull/6538

PR: https://git.openjdk.java.net/jdk/pull/6538


From asemenov at openjdk.java.net  Thu Nov 25 08:32:42 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Thu, 25 Nov 2021 08:32:42 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v2]
In-Reply-To: <OoJPIG8nsnn6I8Yu-bA2fxLXC0qmc56-8WVHXHPSwcI=.f3dfb992-26aa-420d-9eeb-3f5a1c279a6f@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
 <OoJPIG8nsnn6I8Yu-bA2fxLXC0qmc56-8WVHXHPSwcI=.f3dfb992-26aa-420d-9eeb-3f5a1c279a6f@github.com>
Message-ID: <J0ZXAkHXBnUclUlIdU7kIAufToFnc7KERchFARcJxmY=.e38f58be-3a76-48bb-9fff-59bbef5e30a3@github.com>

On Wed, 24 Nov 2021 16:01:04 GMT, Anton Tarasov <ant at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Probably it should somehow ask the icon itself about possible description? I guess the JLabel should work similar to Icon/ImageIcon/AccessibleImageIcon/etc when the text is empty but the icon is set. But I am not sure that the iicons are supported by the a11y in Swing, for example how the reader will cover the simple Icon? Will it say something?
>
> src/java.desktop/share/classes/javax/swing/JLabel.java line 1083:
> 
>> 1081:                 name = super.getAccessibleName();
>> 1082:             }
>> 1083: 
> 
> Please remove the extra line.

Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6538


From asemenov at openjdk.java.net  Thu Nov 25 08:46:37 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Thu, 25 Nov 2021 08:46:37 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v3]
In-Reply-To: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
Message-ID: <mjArQwTV69aWjzu8v2I7yvDgW9XFhhNxD14TlLN93XY=.7691e650-6a85-4de0-8c49-bf838cf5d143@github.com>

> Testing https://bugs.openjdk.java.net/browse/JDK-8271071 
> Step to reproduce 
> 1) Run SwingSet2 in JDK 18 ( I used b24 ) 
> 2) Enable Voiceover. 
> 3) Select JTable demo 
> 4) Click any row in the table or select the first row . Observe that row is selected & VoiceOver reads the column values or navigate the columns one by one by pressing tab key. When the focus reaches the last column ( Favourite Food ) Observe that column value is read as null. If you hear the same then the bug is reproduced.

Artem Semenov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6538/files
  - new: https://git.openjdk.java.net/jdk/pull/6538/files/8ea5d093..09d3fa57

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6538&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6538&range=01-02

  Stats: 11 lines in 1 file changed: 2 ins; 8 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6538.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6538/head:pull/6538

PR: https://git.openjdk.java.net/jdk/pull/6538


From asemenov at openjdk.java.net  Thu Nov 25 09:00:37 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Thu, 25 Nov 2021 09:00:37 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v3]
In-Reply-To: <OoJPIG8nsnn6I8Yu-bA2fxLXC0qmc56-8WVHXHPSwcI=.f3dfb992-26aa-420d-9eeb-3f5a1c279a6f@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
 <OoJPIG8nsnn6I8Yu-bA2fxLXC0qmc56-8WVHXHPSwcI=.f3dfb992-26aa-420d-9eeb-3f5a1c279a6f@github.com>
Message-ID: <3GMNQzmOtHGi0CA4XOLw7HI_biwTMnCJlZeVHEoGNcY=.107d931b-6fe9-4ed4-bd53-16d02a142a10@github.com>

On Wed, 24 Nov 2021 16:01:04 GMT, Anton Tarasov <ant at openjdk.org> wrote:

>> Artem Semenov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> src/java.desktop/share/classes/javax/swing/JLabel.java line 1083:
> 
>> 1081:                 name = super.getAccessibleName();
>> 1082:             }
>> 1083: 
> 
> Please remove the extra line.

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/6538


From asemenov at openjdk.java.net  Thu Nov 25 09:00:32 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Thu, 25 Nov 2021 09:00:32 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v4]
In-Reply-To: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
Message-ID: <vYE-fKcVR2z6FtIBQHhz2eZCwA6eNjiYlrHa7-pgRJI=.34e5d6af-7ee9-4087-9a1c-31a7c8ff2ce5@github.com>

> Testing https://bugs.openjdk.java.net/browse/JDK-8271071 
> Step to reproduce 
> 1) Run SwingSet2 in JDK 18 ( I used b24 ) 
> 2) Enable Voiceover. 
> 3) Select JTable demo 
> 4) Click any row in the table or select the first row . Observe that row is selected & VoiceOver reads the column values or navigate the columns one by one by pressing tab key. When the focus reaches the last column ( Favourite Food ) Observe that column value is read as null. If you hear the same then the bug is reproduced.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  Probably it should somehow ask the icon itself about possible description? I guess the JLabel should work similar to Icon/ImageIcon/AccessibleImageIcon/etc when the text is empty but the icon is set. But I am not sure that the iicons are supported by the a11y in Swing, for example how the reader will cover the simple Icon? Will it say something?

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6538/files
  - new: https://git.openjdk.java.net/jdk/pull/6538/files/09d3fa57..2199bd53

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6538&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6538&range=02-03

  Stats: 11 lines in 1 file changed: 8 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6538.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6538/head:pull/6538

PR: https://git.openjdk.java.net/jdk/pull/6538


From lbourges at openjdk.java.net  Thu Nov 25 09:27:09 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 25 Nov 2021 09:27:09 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v10]
In-Reply-To: <W1sc79kkjjEU2gMwVffM-tW9nvdr4hIkRNvWJrkPzXY=.0d9881e6-2761-4fe2-81e3-86abb50fd5ca@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <W1sc79kkjjEU2gMwVffM-tW9nvdr4hIkRNvWJrkPzXY=.0d9881e6-2761-4fe2-81e3-86abb50fd5ca@github.com>
Message-ID: <74CXyCEJCW15HLBIbK4UY-25yfztLQ_tTjeIzWBFiJ0=.bc1343fc-734c-4b58-892e-be4be68ffee0@github.com>

On Fri, 19 Nov 2021 19:09:54 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   Addressing code review feedback: "Use BigDecomal.setScale(40) to ascertain precision."
>   
>   The geom.* unit tests passed before & after this change.
>   
>   https://github.com/openjdk/jdk/pull/6227#discussion_r752908494

Please consider this PR for review @prrace @mrserb ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6227


From asemenov at openjdk.java.net  Thu Nov 25 13:00:11 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Thu, 25 Nov 2021 13:00:11 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v3]
In-Reply-To: <FaRdPReanZ4yCDyfLPQnZNjHZGCxtx9YNoDRssy1P-w=.3a819ed2-7b6c-45db-ac4f-3f196103953e@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
 <FaRdPReanZ4yCDyfLPQnZNjHZGCxtx9YNoDRssy1P-w=.3a819ed2-7b6c-45db-ac4f-3f196103953e@github.com>
Message-ID: <p_g-qKuMtrK3M16iCkvdmgjnBWZTpWMxzkLT_4p5X5E=.fea38522-8074-4238-9df9-d89aff13ec53@github.com>

On Thu, 25 Nov 2021 03:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Artem Semenov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> src/java.desktop/share/classes/javax/swing/JLabel.java line 1091:
> 
>> 1089:                     (JLabel.this.getIcon() != null)) {
>> 1090:                 name = ResourceBundle.getBundle("com.sun.accessibility.internal.resources.accessibility", Locale.getDefault()).getString("image");
>> 1091:             }
> 
> Probably it should somehow ask the icon itself about possible description? I guess the JLabel should work similar to Icon/ImageIcon/AccessibleImageIcon/etc when the text is empty but the icon is set. But I am not sure that the iicons are supported by the a11y in Swing, for example how the reader will cover the simple Icon? Will it say something?

Done. thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6538


From ant at openjdk.java.net  Thu Nov 25 13:48:03 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Thu, 25 Nov 2021 13:48:03 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v4]
In-Reply-To: <vYE-fKcVR2z6FtIBQHhz2eZCwA6eNjiYlrHa7-pgRJI=.34e5d6af-7ee9-4087-9a1c-31a7c8ff2ce5@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
 <vYE-fKcVR2z6FtIBQHhz2eZCwA6eNjiYlrHa7-pgRJI=.34e5d6af-7ee9-4087-9a1c-31a7c8ff2ce5@github.com>
Message-ID: <KIvaOYRzhyPN4BouF3Qi1jIkjDcOAPkdRXYDtVvYteM=.d0a66a5d-2228-4a2b-b298-84e6b03fedd1@github.com>

On Thu, 25 Nov 2021 09:00:32 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> Testing https://bugs.openjdk.java.net/browse/JDK-8271071 
>> Step to reproduce 
>> 1) Run SwingSet2 in JDK 18 ( I used b24 ) 
>> 2) Enable Voiceover. 
>> 3) Select JTable demo 
>> 4) Click any row in the table or select the first row . Observe that row is selected & VoiceOver reads the column values or navigate the columns one by one by pressing tab key. When the focus reaches the last column ( Favourite Food ) Observe that column value is read as null. If you hear the same then the bug is reproduced.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Probably it should somehow ask the icon itself about possible description? I guess the JLabel should work similar to Icon/ImageIcon/AccessibleImageIcon/etc when the text is empty but the icon is set. But I am not sure that the iicons are supported by the a11y in Swing, for example how the reader will cover the simple Icon? Will it say something?

Marked as reviewed by ant (Reviewer).

Looks fine to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6538


From duke at openjdk.java.net  Fri Nov 26 01:49:07 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 26 Nov 2021 01:49:07 GMT
Subject: Integrated: 8277504: Use String.stripTrailing instead of hand-crafted
 method in SwingUtilities2
In-Reply-To: <xIp8o7KwFhHt3NBX-y6CTG-3on8QKQ9CcjAKfUEE_Zs=.bb12232e-93be-4719-9d00-e2f7e36d2b92@github.com>
References: <xIp8o7KwFhHt3NBX-y6CTG-3on8QKQ9CcjAKfUEE_Zs=.bb12232e-93be-4719-9d00-e2f7e36d2b92@github.com>
Message-ID: <KGhGGjmGAxuF8HvsyEOE7-fqPtpF3NhyOhC7Rqt5aM4=.301c6774-725a-4ed6-8f5e-b32fd4f68d24@github.com>

On Wed, 17 Nov 2021 19:57:19 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> There is opportunity to use String.stripTrailing() method in java.desktop in SwingUtilities2 class.

This pull request has now been integrated.

Changeset: eb4d886b
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eb4d886bc0f57085b21ef41f2069ff60b2714cfa
Stats:     10 lines in 1 file changed: 0 ins; 8 del; 2 mod

8277504: Use String.stripTrailing instead of hand-crafted method in SwingUtilities2

Reviewed-by: pbansal, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/6436


From serb at openjdk.java.net  Fri Nov 26 01:58:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 26 Nov 2021 01:58:14 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v3]
In-Reply-To: <p_g-qKuMtrK3M16iCkvdmgjnBWZTpWMxzkLT_4p5X5E=.fea38522-8074-4238-9df9-d89aff13ec53@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
 <FaRdPReanZ4yCDyfLPQnZNjHZGCxtx9YNoDRssy1P-w=.3a819ed2-7b6c-45db-ac4f-3f196103953e@github.com>
 <p_g-qKuMtrK3M16iCkvdmgjnBWZTpWMxzkLT_4p5X5E=.fea38522-8074-4238-9df9-d89aff13ec53@github.com>
Message-ID: <EQnkRK_iV0WV5D2YppyoeEKTNSPec0NdZhD4LYnIqSA=.6344ec75-896e-4ee0-af46-c02ca3158faa@github.com>

On Thu, 25 Nov 2021 12:57:20 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JLabel.java line 1091:
>> 
>>> 1089:                     (JLabel.this.getIcon() != null)) {
>>> 1090:                 name = ResourceBundle.getBundle("com.sun.accessibility.internal.resources.accessibility", Locale.getDefault()).getString("image");
>>> 1091:             }
>> 
>> Probably it should somehow ask the icon itself about possible description? I guess the JLabel should work similar to Icon/ImageIcon/AccessibleImageIcon/etc when the text is empty but the icon is set. But I am not sure that the iicons are supported by the a11y in Swing, for example how the reader will cover the simple Icon? Will it say something?
>
> Done. thank you very much.

I few questions to thinking about:
 - If the label and icon is not accessible then should we say something? Or we should ignore it like we do for any other non-accessible components?
 - Why the image text is used, don't we need to use the "javax.accessibility.AccessibleRole#ICON" role for such label/icon and allow the reader to say something standard for the icon. Does the voiceover has some default text for the icon/image when the alt text is not set?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6538


From avu at openjdk.java.net  Fri Nov 26 09:02:37 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 26 Nov 2021 09:02:37 GMT
Subject: RFR: 8272392 Lanai: SwingSet2. Black background on expanding tree
 node [v2]
In-Reply-To: <j43XsVmt-JoPBbf2zmSprcycbHlkZF2GSBXas3T7BRk=.fcee72ac-9edf-423d-b71d-89612e6d2e52@github.com>
References: <j43XsVmt-JoPBbf2zmSprcycbHlkZF2GSBXas3T7BRk=.fcee72ac-9edf-423d-b71d-89612e6d2e52@github.com>
Message-ID: <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>

> Removed creation of the separate encoder depending on destination properties as we don't use this info to customize the encoder properties

Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:

  8272392 Lanai: SwingSet2. Black background on expanding tree node
  
  Fixed incorrect addition of the values into pipeline state cache. Refactored index initialization. Removed unused flags from MTLClip.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6529/files
  - new: https://git.openjdk.java.net/jdk/pull/6529/files/1d4cf5c6..89138dfa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6529&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6529&range=00-01

  Stats: 37 lines in 2 files changed: 4 ins; 14 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6529.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6529/head:pull/6529

PR: https://git.openjdk.java.net/jdk/pull/6529


From mbaesken at openjdk.java.net  Fri Nov 26 11:54:06 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 26 Nov 2021 11:54:06 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows [v3]
In-Reply-To: <vZdJqlPw_-3v2JnC8K4qxzW8SCwPCvQcbUmy9X4jBRs=.20d73184-0584-4058-8e2d-02d62957592b@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
 <vZdJqlPw_-3v2JnC8K4qxzW8SCwPCvQcbUmy9X4jBRs=.20d73184-0584-4058-8e2d-02d62957592b@github.com>
Message-ID: <xH3TupkjWB_vf4TLi9gu1HBVki8MO0SmkTPZtPzLGlc=.e11331c3-c639-4b47-8138-23992aaa1e27@github.com>

On Fri, 19 Nov 2021 09:14:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni to an awt related test, and shows on Windows server 2019 the following JNI warning , so the test  JNICheck/FreeTypeScalerJNICheck.java fails on this Windows version.
>> 
>> :stdErr:
>> Thu Oct 28 01:27:10 CEST 2021
>> stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV
>>                at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 18.0.0.1-internal/Native Method)
>>                at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:95)
>>                at sun.awt.Win32GraphicsEnvironment.<clinit>(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:63)
>>                at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 18.0.0.1-internal/PlatformGraphicsInfo.java:34)
>>                at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:93)
>>                at java.awt.GraphicsEnvironment$LocalGE.<clinit>(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:84)
>>                at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:106)
>>                at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53)
>>                at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)
>> 
>> We can get rid of the warning by adjusting a JNU_CallStaticMethodByName call in awt_Win32GraphicsEnv.cpp .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do you run FreeTypeScalerJNICheck.java test on Windows

I looked a bit more into it;  when connecting with Remote desktop connection to the Win Server 2019 test machine, I could run the jtreg test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java on the command line successfully with **BOTH** the fastdebug and opt/product  JVM.
The error occurs when starting the tests from the Windows Task scheduler;  however when running from the task scheduler the error occurs  with the fastdebug-JVM not when running the opt/product JVM.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6306


From duke at openjdk.java.net  Fri Nov 26 12:54:21 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 26 Nov 2021 12:54:21 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
Message-ID: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>

Instead of something like

long x;
long y;
return (x < y) ? -1 : ((x == y) ? 0 : 1);

we can use `return Long.compare(x, y);`

All replacements are done with IDE.

-------------

Commit messages:
 - 8277868: Use Comparable.compare() instead of surrogate code

Changes: https://git.openjdk.java.net/jdk/pull/6575/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6575&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277868
  Stats: 70 lines in 12 files changed: 2 ins; 44 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6575.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6575/head:pull/6575

PR: https://git.openjdk.java.net/jdk/pull/6575


From dfuchs at openjdk.java.net  Fri Nov 26 15:37:14 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 26 Nov 2021 15:37:14 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
In-Reply-To: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
Message-ID: <lT1XZ3C4vlGYZ5ZehcpQzJciNEABanCJOh8aGMl6Nwo=.f124dce7-1d8f-4f9c-89c3-6017ff9e2eda@github.com>

On Fri, 26 Nov 2021 12:46:59 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> Instead of something like
> 
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
> 
> we can use `return Long.compare(x, y);`
> 
> All replacements are done with IDE.

Changes to java.net look good. Please obtain approval from reviewers in the other areas before integrating.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6575


From aivanov at openjdk.java.net  Sat Nov 27 18:54:05 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 27 Nov 2021 18:54:05 GMT
Subject: RFR: 8274640: Cleanup unnecessary null comparison before
 instanceof check in java.desktop
In-Reply-To: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
Message-ID: <tRXWyvjxILGa6Ueq9XfxU9Q52I2NylXnz38Ik_5RFmo=.b478e5ed-ac16-44d6-9550-267d74e9fdd9@github.com>

On Sat, 11 Sep 2021 14:59:21 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Updated code checks both non-null and instance of a class in java.desktop module classes.
> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. 
> Similar cleanups
> 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming
> 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base

src/java.desktop/macosx/classes/com/apple/laf/AquaRootPaneUI.java line 78:

> 76:         final Component parent = c.getParent();
> 77: 
> 78:         if (parent instanceof JFrame frameParent) {

The `frameParent` variable was declared `final` before.
Suggestion:

        if (parent instanceof final JFrame frameParent) {

src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderUI.java line 148:

> 146:     protected static TableColumn getTableColumn(final JTableHeader target, final Object value) {
> 147:         if (!(value instanceof Integer idx)) return null;
> 148:         final int columnIndex = idx;

Probably, this expression could be simplified?
Suggestion:

        if (!(value instanceof final Integer columnIndex)) return null;

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 247:

> 245:         }},
> 246:         new Property<CPlatformWindow>(WINDOW_DOCUMENT_FILE) { public void applyProperty(final CPlatformWindow c, final Object value) {
> 247:             if (!(value instanceof java.io.File f)) {

Is `file` a better name?

src/java.desktop/share/classes/javax/swing/JOptionPane.java line 2336:

> 2334:         if (icon instanceof Serializable ser) {
> 2335:             values.addElement("icon");
> 2336:             values.addElement(ser);

I suggest omitting `ser` variable declaration: it's not used as `Serializable`, checking with `instanceof` is enough. This comment applies to all similar if-conditions below.

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 1338:

> 1336:         }
> 1337:         // Save the popup, if it's Serializable.
> 1338:         if (popup instanceof Serializable ser) {

Suggestion:

        if (popup instanceof Serializable) {

src/java.desktop/share/classes/javax/swing/JTree.java line 3132:

> 3130:         s.defaultWriteObject();
> 3131:         // Save the cellRenderer, if it's Serializable.
> 3132:         if (cellRenderer instanceof Serializable ser) {

Suggestion:

        if (cellRenderer instanceof Serializable) {

src/java.desktop/share/classes/javax/swing/tree/DefaultMutableTreeNode.java line 1301:

> 1299:         s.defaultWriteObject();
> 1300:         // Save the userObject, if it's Serializable.
> 1301:         if (userObject instanceof Serializable ser) {

Suggestion:

        if (userObject instanceof Serializable) {

src/java.desktop/share/classes/javax/swing/tree/DefaultTreeModel.java line 694:

> 692:         s.defaultWriteObject();
> 693:         // Save the root, if it's Serializable.
> 694:         if (root instanceof Serializable ser) {

Suggestion:

        if (root instanceof Serializable) {

src/java.desktop/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java line 1221:

> 1219:         s.defaultWriteObject();
> 1220:         // Save the rowMapper, if it implements Serializable
> 1221:         if (rowMapper instanceof Serializable ser) {

Suggestion:

        if (rowMapper instanceof Serializable) {

src/java.desktop/unix/classes/sun/awt/X11/XWindow.java line 312:

> 310:         }
> 311: 
> 312:         return window.getContentWindow();

Is the branch where 0 was returned impossible?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5482


From duke at openjdk.java.net  Sat Nov 27 22:54:16 2021
From: duke at openjdk.java.net (Michael Bien)
Date: Sat, 27 Nov 2021 22:54:16 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
In-Reply-To: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
Message-ID: <FePjU3YtcoGQx5qyfQX4eeb32FD48zgkuaVPlpSI_9s=.4cecb850-3bce-4e7f-b5ce-517eb7ea65f3@github.com>

On Fri, 26 Nov 2021 12:46:59 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> Instead of something like
> 
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
> 
> we can use `return Long.compare(x, y);`
> 
> All replacements are done with IDE.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 249:

> 247: 
> 248:         private static int sign(int num) {
> 249:             return Integer.compare(num, 0);

=> Integer.signum(num)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6575


From duke at openjdk.java.net  Mon Nov 29 08:05:08 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 29 Nov 2021 08:05:08 GMT
Subject: RFR: 8274640: Cleanup unnecessary null comparison before
 instanceof check in java.desktop
In-Reply-To: <tRXWyvjxILGa6Ueq9XfxU9Q52I2NylXnz38Ik_5RFmo=.b478e5ed-ac16-44d6-9550-267d74e9fdd9@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
 <tRXWyvjxILGa6Ueq9XfxU9Q52I2NylXnz38Ik_5RFmo=.b478e5ed-ac16-44d6-9550-267d74e9fdd9@github.com>
Message-ID: <HNZ6Zc-qVuD5J5QTHUWY2DkfnSNaJiytNM4mdZHXOh8=.723e0011-1ef1-43b1-b1e5-8d08d4b96551@github.com>

On Sat, 27 Nov 2021 16:37:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Updated code checks both non-null and instance of a class in java.desktop module classes.
>> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. 
>> Similar cleanups
>> 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming
>> 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaRootPaneUI.java line 78:
> 
>> 76:         final Component parent = c.getParent();
>> 77: 
>> 78:         if (parent instanceof JFrame frameParent) {
> 
> The `frameParent` variable was declared `final` before.
> Suggestion:
> 
>         if (parent instanceof final JFrame frameParent) {

Does it really worth keeping `final` here?
In my opinion it makes code unnecessary longer and harder to read in this case

> src/java.desktop/unix/classes/sun/awt/X11/XWindow.java line 312:
> 
>> 310:         }
>> 311: 
>> 312:         return window.getContentWindow();
> 
> Is the branch where 0 was returned impossible?

Yes. It was impossible.
Only way out of this cycle is when `peer instanceof XWindow` is `true`
https://github.com/openjdk/jdk/blob/0c7a4b8aa8bb672e87aae7090494719db018b9b1/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java#L306-L310

-------------

PR: https://git.openjdk.java.net/jdk/pull/5482


From duke at openjdk.java.net  Mon Nov 29 08:17:41 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 29 Nov 2021 08:17:41 GMT
Subject: RFR: 8274640: Cleanup unnecessary null comparison before
 instanceof check in java.desktop [v2]
In-Reply-To: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
Message-ID: <13h9kfZ5bm6SzxmSe-1NjltlocI-qRZgA40Ihy-_QXI=.4ab29473-afea-4bc3-b887-abc372143a22@github.com>

> Updated code checks both non-null and instance of a class in java.desktop module classes.
> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. 
> Similar cleanups
> 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming
> 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8274640: Cleanup unnecessary null comparison before instanceof check in java.desktop
  apply review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5482/files
  - new: https://git.openjdk.java.net/jdk/pull/5482/files/250ba2c4..5a8cf2fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5482&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5482&range=00-01

  Stats: 32 lines in 8 files changed: 0 ins; 1 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5482/head:pull/5482

PR: https://git.openjdk.java.net/jdk/pull/5482


From duke at openjdk.java.net  Mon Nov 29 08:17:53 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 29 Nov 2021 08:17:53 GMT
Subject: RFR: 8274640: Cleanup unnecessary null comparison before
 instanceof check in java.desktop [v2]
In-Reply-To: <tRXWyvjxILGa6Ueq9XfxU9Q52I2NylXnz38Ik_5RFmo=.b478e5ed-ac16-44d6-9550-267d74e9fdd9@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
 <tRXWyvjxILGa6Ueq9XfxU9Q52I2NylXnz38Ik_5RFmo=.b478e5ed-ac16-44d6-9550-267d74e9fdd9@github.com>
Message-ID: <MwTBY51lFn3B2eMsLym-Z0o77g_KzPt5Bd1JXfQhuJE=.0e894be2-97c3-4182-afbf-1a7993bbc38b@github.com>

On Sat, 27 Nov 2021 16:27:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274640: Cleanup unnecessary null comparison before instanceof check in java.desktop
>>   apply review comments
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderUI.java line 148:
> 
>> 146:     protected static TableColumn getTableColumn(final JTableHeader target, final Object value) {
>> 147:         if (!(value instanceof Integer idx)) return null;
>> 148:         final int columnIndex = idx;
> 
> Probably, this expression could be simplified?
> Suggestion:
> 
>         if (!(value instanceof final Integer columnIndex)) return null;

done

> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 247:
> 
>> 245:         }},
>> 246:         new Property<CPlatformWindow>(WINDOW_DOCUMENT_FILE) { public void applyProperty(final CPlatformWindow c, final Object value) {
>> 247:             if (!(value instanceof java.io.File f)) {
> 
> Is `file` a better name?

updated

> src/java.desktop/share/classes/javax/swing/JOptionPane.java line 2336:
> 
>> 2334:         if (icon instanceof Serializable ser) {
>> 2335:             values.addElement("icon");
>> 2336:             values.addElement(ser);
> 
> I suggest omitting `ser` variable declaration: it's not used as `Serializable`, checking with `instanceof` is enough. This comment applies to all similar if-conditions below.

ok

> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 1338:
> 
>> 1336:         }
>> 1337:         // Save the popup, if it's Serializable.
>> 1338:         if (popup instanceof Serializable ser) {
> 
> Suggestion:
> 
>         if (popup instanceof Serializable) {

updated

> src/java.desktop/share/classes/javax/swing/JTree.java line 3132:
> 
>> 3130:         s.defaultWriteObject();
>> 3131:         // Save the cellRenderer, if it's Serializable.
>> 3132:         if (cellRenderer instanceof Serializable ser) {
> 
> Suggestion:
> 
>         if (cellRenderer instanceof Serializable) {

updated

> src/java.desktop/share/classes/javax/swing/tree/DefaultMutableTreeNode.java line 1301:
> 
>> 1299:         s.defaultWriteObject();
>> 1300:         // Save the userObject, if it's Serializable.
>> 1301:         if (userObject instanceof Serializable ser) {
> 
> Suggestion:
> 
>         if (userObject instanceof Serializable) {

updated

> src/java.desktop/share/classes/javax/swing/tree/DefaultTreeModel.java line 694:
> 
>> 692:         s.defaultWriteObject();
>> 693:         // Save the root, if it's Serializable.
>> 694:         if (root instanceof Serializable ser) {
> 
> Suggestion:
> 
>         if (root instanceof Serializable) {

updated

> src/java.desktop/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java line 1221:
> 
>> 1219:         s.defaultWriteObject();
>> 1220:         // Save the rowMapper, if it implements Serializable
>> 1221:         if (rowMapper instanceof Serializable ser) {
> 
> Suggestion:
> 
>         if (rowMapper instanceof Serializable) {

updated

-------------

PR: https://git.openjdk.java.net/jdk/pull/5482


From duke at openjdk.java.net  Mon Nov 29 08:18:47 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 29 Nov 2021 08:18:47 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v2]
In-Reply-To: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
Message-ID: <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>

> Instead of something like
> 
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
> 
> we can use `return Long.compare(x, y);`
> 
> All replacements are done with IDE.

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8277868: Use Integer.signum() in BasicTableUI

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6575/files
  - new: https://git.openjdk.java.net/jdk/pull/6575/files/8fa8242a..6744a562

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6575&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6575&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6575.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6575/head:pull/6575

PR: https://git.openjdk.java.net/jdk/pull/6575


From duke at openjdk.java.net  Mon Nov 29 08:18:50 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 29 Nov 2021 08:18:50 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v2]
In-Reply-To: <FePjU3YtcoGQx5qyfQX4eeb32FD48zgkuaVPlpSI_9s=.4cecb850-3bce-4e7f-b5ce-517eb7ea65f3@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <FePjU3YtcoGQx5qyfQX4eeb32FD48zgkuaVPlpSI_9s=.4cecb850-3bce-4e7f-b5ce-517eb7ea65f3@github.com>
Message-ID: <J_1CFL2TOKhoTP9aRpby8TkVZFZusYE8fxP4ZssRkeU=.4c08f82b-edf8-447b-b8bb-e036465563cb@github.com>

On Sat, 27 Nov 2021 22:50:55 GMT, Michael Bien <duke at openjdk.java.net> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277868: Use Integer.signum() in BasicTableUI
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 249:
> 
>> 247: 
>> 248:         private static int sign(int num) {
>> 249:             return Integer.compare(num, 0);
> 
> => Integer.signum(num)

Done!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6575


From aivanov at openjdk.java.net  Mon Nov 29 11:20:17 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 29 Nov 2021 11:20:17 GMT
Subject: RFR: 8274640: Cleanup unnecessary null comparison before
 instanceof check in java.desktop [v2]
In-Reply-To: <HNZ6Zc-qVuD5J5QTHUWY2DkfnSNaJiytNM4mdZHXOh8=.723e0011-1ef1-43b1-b1e5-8d08d4b96551@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
 <tRXWyvjxILGa6Ueq9XfxU9Q52I2NylXnz38Ik_5RFmo=.b478e5ed-ac16-44d6-9550-267d74e9fdd9@github.com>
 <HNZ6Zc-qVuD5J5QTHUWY2DkfnSNaJiytNM4mdZHXOh8=.723e0011-1ef1-43b1-b1e5-8d08d4b96551@github.com>
Message-ID: <AeEWZbGNBoruJxZyWGkiRP_0FVNCLE6gI5i_Iwx1bLA=.19095e1e-71a3-4dd4-b62a-5542d75a6c1c@github.com>

On Mon, 29 Nov 2021 08:00:19 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> src/java.desktop/unix/classes/sun/awt/X11/XWindow.java line 312:
>> 
>>> 310:         }
>>> 311: 
>>> 312:         return window.getContentWindow();
>> 
>> Is the branch where 0 was returned impossible?
>
> Yes. It was impossible.
> Only way out of this cycle is when `peer instanceof XWindow` is `true`
> https://github.com/openjdk/jdk/blob/0c7a4b8aa8bb672e87aae7090494719db018b9b1/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java#L306-L310

Thanks, I just wanted to confirm my own understanding.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5482


From aivanov at openjdk.java.net  Mon Nov 29 11:23:11 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 29 Nov 2021 11:23:11 GMT
Subject: RFR: 8274640: Cleanup unnecessary null comparison before
 instanceof check in java.desktop [v2]
In-Reply-To: <13h9kfZ5bm6SzxmSe-1NjltlocI-qRZgA40Ihy-_QXI=.4ab29473-afea-4bc3-b887-abc372143a22@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
 <13h9kfZ5bm6SzxmSe-1NjltlocI-qRZgA40Ihy-_QXI=.4ab29473-afea-4bc3-b887-abc372143a22@github.com>
Message-ID: <NXbSZQKsXkynrVaRmHlIA2dC27DAzMsag4fQdSX7EVQ=.8b0fb80b-31be-49eb-bb24-ac316dab236f@github.com>

On Mon, 29 Nov 2021 08:17:41 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> Updated code checks both non-null and instance of a class in java.desktop module classes.
>> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. 
>> Similar cleanups
>> 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming
>> 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274640: Cleanup unnecessary null comparison before instanceof check in java.desktop
>   apply review comments

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5482


From aivanov at openjdk.java.net  Mon Nov 29 11:23:12 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 29 Nov 2021 11:23:12 GMT
Subject: RFR: 8274640: Cleanup unnecessary null comparison before
 instanceof check in java.desktop [v2]
In-Reply-To: <HNZ6Zc-qVuD5J5QTHUWY2DkfnSNaJiytNM4mdZHXOh8=.723e0011-1ef1-43b1-b1e5-8d08d4b96551@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
 <tRXWyvjxILGa6Ueq9XfxU9Q52I2NylXnz38Ik_5RFmo=.b478e5ed-ac16-44d6-9550-267d74e9fdd9@github.com>
 <HNZ6Zc-qVuD5J5QTHUWY2DkfnSNaJiytNM4mdZHXOh8=.723e0011-1ef1-43b1-b1e5-8d08d4b96551@github.com>
Message-ID: <DNbDrBxvJbq0N8aVGQKi0_rcFjHuW-2cJYtREFoUORw=.65f3a4e7-d609-4507-ab34-ee6549578c0b@github.com>

On Mon, 29 Nov 2021 08:01:56 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaRootPaneUI.java line 78:
>> 
>>> 76:         final Component parent = c.getParent();
>>> 77: 
>>> 78:         if (parent instanceof JFrame frameParent) {
>> 
>> The `frameParent` variable was declared `final` before.
>> Suggestion:
>> 
>>         if (parent instanceof final JFrame frameParent) {
>
> Does it really worth keeping `final` here?
> In my opinion it makes code unnecessary longer and harder to read in this case

Agree, `final` doesn't add much value, it's clear the value of `frameParent` doesn't change in the following three lines.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5482


From myano at openjdk.java.net  Mon Nov 29 11:30:16 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 29 Nov 2021 11:30:16 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
Message-ID: <kTUnPDs33UT9VEyWWsnOKxsSD-Tz9gajr3CqrDUQ-7Y=.5a79648c-28ae-4d13-b0a0-d3c4b81a0b01@github.com>

On Thu, 28 Oct 2021 08:27:44 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8275715 bug fixes?
>> 
>> I think D3DScreenUpdateManager posts unnecessary PaintEvent during processing PaintEvent. When the validate method is called from createGraphics, repaintPeerTarget should not be called.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8275715: D3D pipeline processes multiple PaintEvent at initial drawing

@mrserb Could you please reply to the above comment?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6064


From vdyakov at openjdk.java.net  Mon Nov 29 17:53:08 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Mon, 29 Nov 2021 17:53:08 GMT
Subject: RFR: 8272392 Lanai: SwingSet2. Black background on expanding tree
 node [v2]
In-Reply-To: <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>
References: <j43XsVmt-JoPBbf2zmSprcycbHlkZF2GSBXas3T7BRk=.fcee72ac-9edf-423d-b71d-89612e6d2e52@github.com>
 <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>
Message-ID: <hBG_F_aZQ8M-c3yoJMmpHERSZjL4CGkbgjR8naFo9Nk=.95242ccb-ba2f-4390-8766-d92795447779@github.com>

On Fri, 26 Nov 2021 09:02:37 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Removed creation of the separate encoder depending on destination properties as we don't use this info to customize the encoder properties
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272392 Lanai: SwingSet2. Black background on expanding tree node
>   
>   Fixed incorrect addition of the values into pipeline state cache. Refactored index initialization. Removed unused flags from MTLClip.

@jayathirthrao @aghaisas please review

-------------

PR: https://git.openjdk.java.net/jdk/pull/6529


From kizune at openjdk.java.net  Mon Nov 29 20:13:05 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 29 Nov 2021 20:13:05 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v4]
In-Reply-To: <vYE-fKcVR2z6FtIBQHhz2eZCwA6eNjiYlrHa7-pgRJI=.34e5d6af-7ee9-4087-9a1c-31a7c8ff2ce5@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
 <vYE-fKcVR2z6FtIBQHhz2eZCwA6eNjiYlrHa7-pgRJI=.34e5d6af-7ee9-4087-9a1c-31a7c8ff2ce5@github.com>
Message-ID: <_Avm119Kvq86MShuHPw08g3pT9JZ-e_Pa_YvhsRJRO8=.8222077e-605d-4c84-adca-fd86c5eccb3c@github.com>

On Thu, 25 Nov 2021 09:00:32 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> Testing https://bugs.openjdk.java.net/browse/JDK-8271071 
>> Step to reproduce 
>> 1) Run SwingSet2 in JDK 18 ( I used b24 ) 
>> 2) Enable Voiceover. 
>> 3) Select JTable demo 
>> 4) Click any row in the table or select the first row . Observe that row is selected & VoiceOver reads the column values or navigate the columns one by one by pressing tab key. When the focus reaches the last column ( Favourite Food ) Observe that column value is read as null. If you hear the same then the bug is reproduced.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Probably it should somehow ask the icon itself about possible description? I guess the JLabel should work similar to Icon/ImageIcon/AccessibleImageIcon/etc when the text is empty but the icon is set. But I am not sure that the iicons are supported by the a11y in Swing, for example how the reader will cover the simple Icon? Will it say something?

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6538


From duke at openjdk.java.net  Mon Nov 29 23:39:08 2021
From: duke at openjdk.java.net (duke)
Date: Mon, 29 Nov 2021 23:39:08 GMT
Subject: Withdrawn: 8274597: [TESTBUG] Two of the dnd tests times out and fails
In-Reply-To: <0ISZ7X0xu1zN3SLn-p1XkZm8Brkb-Ozu_nTe3RF8xXg=.f3b3c6ed-3719-4347-8f13-a8b89bc1d836@github.com>
References: <0ISZ7X0xu1zN3SLn-p1XkZm8Brkb-Ozu_nTe3RF8xXg=.f3b3c6ed-3719-4347-8f13-a8b89bc1d836@github.com>
Message-ID: <3Bs6BL7G4YMkLoxUGS3sNRQ-Dg2Sp_1z_XUWx-Cw124=.64a427fb-9060-4b41-a4a0-fb5c87199f5b@github.com>

On Thu, 30 Sep 2021 14:24:50 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> These two dnd tests fails most of the time with a time out, mostly noticed in windows 11 machines.
> 1. java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java
> 2. java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
> 
> Fix:
> From the logs, I have noticed that some of the non-daemon threads are still waiting even after the test execution is complete. So it could be possible that java is waiting for these threads to be finished execution before the main thread exits.
> As a fix for this, I have put a Thread.sleep(100) at the end of the main() in order to enable other non-daemon threads get a chance to finish their execution before the main thread completes.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5777


From cushon at openjdk.java.net  Tue Nov 30 01:37:23 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 30 Nov 2021 01:37:23 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy
Message-ID: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>

This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` after [JDK-8271623](https://bugs.openjdk.java.net/browse/JDK-8271623), using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).

-------------

Commit messages:
 - 8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy

Changes: https://git.openjdk.java.net/jdk/pull/6603/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6603&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277817
  Stats: 0 lines in 6 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6603.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6603/head:pull/6603

PR: https://git.openjdk.java.net/jdk/pull/6603


From alexey.ushakov at jetbrains.com  Tue Nov 30 12:14:59 2021
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Tue, 30 Nov 2021 13:14:59 +0100
Subject: RFR: 8272392 Lanai: SwingSet2. Black background on expanding tree
 node [v2]
In-Reply-To: <hBG_F_aZQ8M-c3yoJMmpHERSZjL4CGkbgjR8naFo9Nk=.95242ccb-ba2f-4390-8766-d92795447779@github.com>
References: <j43XsVmt-JoPBbf2zmSprcycbHlkZF2GSBXas3T7BRk=.fcee72ac-9edf-423d-b71d-89612e6d2e52@github.com>
 <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>
 <hBG_F_aZQ8M-c3yoJMmpHERSZjL4CGkbgjR8naFo9Nk=.95242ccb-ba2f-4390-8766-d92795447779@github.com>
Message-ID: <F0EAA125-1743-4079-B574-250D4D9BC450@jetbrains.com>

Yes, could you please review it. During the fix of the original issue I?ve uncovered the real problem with pipeline state cache that can lead to OOMs, obtaining wrong rendering states ?

Best Regards,
Alexey

> On 29 Nov 2021, at 18:53, Victor Dyakov <vdyakov at openjdk.java.net> wrote:
> 
> On Fri, 26 Nov 2021 09:02:37 GMT, Alexey Ushakov <avu at openjdk.org> wrote:
> 
>>> Removed creation of the separate encoder depending on destination properties as we don't use this info to customize the encoder properties
>> 
>> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  8272392 Lanai: SwingSet2. Black background on expanding tree node
>> 
>>  Fixed incorrect addition of the values into pipeline state cache. Refactored index initialization. Removed unused flags from MTLClip.
> 
> @jayathirthrao @aghaisas please review
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/6529



From prr at openjdk.java.net  Tue Nov 30 20:42:09 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 30 Nov 2021 20:42:09 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy
In-Reply-To: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
Message-ID: <edpcdeGJVGoGO3RUyL3IlQc1TVU9kjh4UHGGH8S2vdE=.f40b929f-9312-402d-ad54-4d9fcfcde28d@github.com>

On Tue, 30 Nov 2021 01:31:24 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).

I must be losing it since I can't find a code review for the fix for https://bugs.openjdk.java.net/browse/JDK-8039082
Presumably the "fix" is to regenerate the serialized object files on some other platform beside mac ?
But 8039082 was supposed to have done that, yet we clearly have a macOS class in here.
I question the whole wisdom of including any Swing related classes in such a serialized form since Swing only supports short-term serialization. Not across platforms, not across releases. But still .. 

And isn't it just one of these cases that failed ? Did you have to re-generate all of them ?

On which platform did you re-generate these ? And on which platforms did you then test the result ?
I don't want to replace one failure with another.

Also the test is now being problem-listed. https://github.com/openjdk/jdk/pull/6624
So this fix will need to de-problem list it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6603


From dcubed at openjdk.java.net  Tue Nov 30 20:44:28 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 30 Nov 2021 20:44:28 GMT
Subject: Integrated: 8278019: ProblemList
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java on linux and
 windows
Message-ID: <eT4h8NNTcrwOnJXVGuYcy-xagXjcSticeqS7CUp-JQ0=.7ecca3ae-2799-4ef5-8015-d78cc71eae1f@github.com>

A trivial fix to ProblemList java/awt/dnd/BadSerializationTest/BadSerializationTest.java on linux and windows

-------------

Commit messages:
 - 8278019: ProblemList java/awt/dnd/BadSerializationTest/BadSerializationTest.java on linux and windows

Changes: https://git.openjdk.java.net/jdk/pull/6624/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6624&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278019
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6624.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6624/head:pull/6624

PR: https://git.openjdk.java.net/jdk/pull/6624


From prr at openjdk.java.net  Tue Nov 30 20:44:29 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 30 Nov 2021 20:44:29 GMT
Subject: Integrated: 8278019: ProblemList
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java on linux and
 windows
In-Reply-To: <eT4h8NNTcrwOnJXVGuYcy-xagXjcSticeqS7CUp-JQ0=.7ecca3ae-2799-4ef5-8015-d78cc71eae1f@github.com>
References: <eT4h8NNTcrwOnJXVGuYcy-xagXjcSticeqS7CUp-JQ0=.7ecca3ae-2799-4ef5-8015-d78cc71eae1f@github.com>
Message-ID: <XMuNt-QhRQEUYk1Lri7_SusMT53XK4Xa-VvlEsum5JM=.5744d443-92a8-4b9d-86be-72da4e32ad60@github.com>

On Tue, 30 Nov 2021 20:33:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/dnd/BadSerializationTest/BadSerializationTest.java on linux and windows

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6624


From dcubed at openjdk.java.net  Tue Nov 30 20:44:29 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 30 Nov 2021 20:44:29 GMT
Subject: Integrated: 8278019: ProblemList
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java on linux and
 windows
In-Reply-To: <XMuNt-QhRQEUYk1Lri7_SusMT53XK4Xa-VvlEsum5JM=.5744d443-92a8-4b9d-86be-72da4e32ad60@github.com>
References: <eT4h8NNTcrwOnJXVGuYcy-xagXjcSticeqS7CUp-JQ0=.7ecca3ae-2799-4ef5-8015-d78cc71eae1f@github.com>
 <XMuNt-QhRQEUYk1Lri7_SusMT53XK4Xa-VvlEsum5JM=.5744d443-92a8-4b9d-86be-72da4e32ad60@github.com>
Message-ID: <fgsy5CTs-OF4kqbJ7D4pjyACEYfYgQxLDWMefF7leWY=.a3308afc-26b5-419b-9396-d8de9e6be586@github.com>

On Tue, 30 Nov 2021 20:37:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> A trivial fix to ProblemList java/awt/dnd/BadSerializationTest/BadSerializationTest.java on linux and windows
>
> Marked as reviewed by prr (Reviewer).

@prrace - Thanks for the lightning fast review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6624


From dcubed at openjdk.java.net  Tue Nov 30 20:44:29 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 30 Nov 2021 20:44:29 GMT
Subject: Integrated: 8278019: ProblemList
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java on linux and
 windows
In-Reply-To: <eT4h8NNTcrwOnJXVGuYcy-xagXjcSticeqS7CUp-JQ0=.7ecca3ae-2799-4ef5-8015-d78cc71eae1f@github.com>
References: <eT4h8NNTcrwOnJXVGuYcy-xagXjcSticeqS7CUp-JQ0=.7ecca3ae-2799-4ef5-8015-d78cc71eae1f@github.com>
Message-ID: <h5caKBHCv2641kQH4T1cVcwlAcd9EQl75uwYhe8ii24=.8bf9430f-a00c-4db8-861e-db12180c8828@github.com>

On Tue, 30 Nov 2021 20:33:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/dnd/BadSerializationTest/BadSerializationTest.java on linux and windows

This pull request has now been integrated.

Changeset: 5a4a9bb9
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5a4a9bb9d55134deac0e02cf37f31d1dd2223024
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8278019: ProblemList java/awt/dnd/BadSerializationTest/BadSerializationTest.java on linux and windows

Reviewed-by: prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/6624


From cushon at openjdk.java.net  Tue Nov 30 20:50:09 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 30 Nov 2021 20:50:09 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy
In-Reply-To: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
Message-ID: <zGxFr0_MqwFe1GB9uRdo_NsVlrJv4weEwt37k3nwxyo=.c5364c7f-1e60-4722-b020-522a2615bd54@github.com>

On Tue, 30 Nov 2021 01:31:24 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).

I couldn't find the review either.

I regenerated it by following the instructions to compile and run the test class as a standalone tool on `x86_64 GNU/Linux`, which updated all of the existing files. I verified it fixes the test on that platform, I don't have a great way to test it on the other platforms right now.

* https://github.com/openjdk/jdk/blob/5a4a9bb9d55134deac0e02cf37f31d1dd2223024/test/jdk/java/awt/dnd/BadSerializationTest/BadSerializationTest.java#L64-L65

* https://github.com/openjdk/jdk/blob/5a4a9bb9d55134deac0e02cf37f31d1dd2223024/test/jdk/java/awt/dnd/BadSerializationTest/BadSerializationTest.java#L95-L96

I started investigating this when I thought it was related to [JDK-8271623](https://bugs.openjdk.java.net/browse/JDK-8271623), if anyone wants to take this over (especially now that it's problem-listed) please feel free :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6603


From rriggs at openjdk.java.net  Tue Nov 30 21:06:09 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 30 Nov 2021 21:06:09 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v2]
In-Reply-To: <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
Message-ID: <UF7L_-UyjOPrjT0YxgBBcgzcqXnF3ecehk6GPVhQuMA=.d0969a24-13a7-4c26-aec0-2cfd7fdda0f4@github.com>

On Mon, 29 Nov 2021 08:18:47 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> Instead of something like
>> 
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>> 
>> we can use `return Long.compare(x, y);`
>> 
>> All replacements are done with IDE.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277868: Use Integer.signum() in BasicTableUI

The core-libs file changes look fine.
A 'client' reviewer should take a look too.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6575