From philip.race at oracle.com  Wed Sep  1 22:05:06 2021
From: philip.race at oracle.com (Philip Race)
Date: Wed, 1 Sep 2021 15:05:06 -0700
Subject: Fwd: Project Wakefield announcement and welcome
In-Reply-To: <09dddbdd-d4d2-c6f4-1622-583239d91e4a@oracle.com>
References: <09dddbdd-d4d2-c6f4-1622-583239d91e4a@oracle.com>
Message-ID: <a2e9098a-7090-d141-ca9f-b9a5c54c24f9@oracle.com>

FYI

-phil


-------- Forwarded Message --------
Subject: 	Project Wakefield announcement and welcome
Date: 	Wed, 1 Sep 2021 14:59:30 -0700
From: 	Philip Race <philip.race at oracle.com>
To: 	wakefield-dev at openjdk.java.net



Hi all,

The project has been recorded in the OpenJDK census : 
https://openjdk.java.net/census#wakefield

The email list (to which I sent this)
https://mail.openjdk.java.net/mailman/listinfo/wakefield-dev
has been set up pre-populated with the initial committers.
If you are a committer who did not previously have an OpenJDK ID you 
should have received
an invitation to register. Don't ignore it - it will expire in 14 days 
from when it was sent.

We also have a web page https://openjdk.java.net/projects/wakefield/ 
<https://openjdk.java.net/projects/wakefield/> which is still just pro-forma
I'll add something more once we have it :-)

The wiki is also being set up : 
https://wiki.openjdk.java.net/display/wakefield 
<https://wiki.openjdk.java.net/display/wakefield>

Unlike the Project Page everyone who is a committer will be able to edit 
the wiki

The project repo has not yet been created but is expected to be created 
this week.
I will send a follow up on that once it is done.

I'll also inform the various client lists (forward please do NOT cross 
post !)? of the new mailing list

-phil.



From iris at openjdk.java.net  Tue Sep  7 19:21:25 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 7 Sep 2021 19:21:25 GMT
Subject: RFR: 8273102: Delete deprecated for removal the empty finalize()
 in java.desktop module
In-Reply-To: <OAhmO3Akwb17uxlk-Kn3_8ZJNy1Tkqds13JLAevCfs0=.df8f6c03-48da-4d05-8575-d304c7d97b6d@github.com>
References: <OAhmO3Akwb17uxlk-Kn3_8ZJNy1Tkqds13JLAevCfs0=.df8f6c03-48da-4d05-8575-d304c7d97b6d@github.com>
Message-ID: <XhlhoWO51Jl6SOVbiy_7yHmuXaZuXTfMt_qlAEVL8KU=.f59727ad-d807-4997-a491-27dc94f1251c@github.com>

On Sun, 29 Aug 2021 01:09:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "java.desktop" module has a few implementations of the finalize() which do nothing, deprecated since jdk9, and are marked "forRemoval = true" since jdk16. 
> 
> This is a request to delete such empty methods. 
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8273103

Associated CSR also reviewed.

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

Marked as reviewed by iris (Reviewer).

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


From aivanov at openjdk.java.net  Tue Sep  7 19:50:11 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Sep 2021 19:50:11 GMT
Subject: RFR: 8273375: Remove redundant 'new String' calls after
 concatenation in java.desktop
In-Reply-To: <tR92hTComDv55m6hbPjMJKmYojUYSl6cw6094uwpOS4=.bfb38bbe-4848-474b-b907-cdb35dad38fb@github.com>
References: <tR92hTComDv55m6hbPjMJKmYojUYSl6cw6094uwpOS4=.bfb38bbe-4848-474b-b907-cdb35dad38fb@github.com>
Message-ID: <HKwTu7MImJT_vXguMsnuHwbjNS3dVddJTmHLtlHlBxk=.b3813a9f-e8fd-4943-82de-b17367ceb8d0@github.com>

On Fri, 3 Sep 2021 07:53:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Result of string concatenation is a newly created `String` object. There is no need it wrap it in another `new String` call.
> Such calls are confusing and produce warnings in IDE. Without them code is easier to read.

src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java line 3209:

> 3207: 
> 3208:         public String toString() {
> 3209:             return "viewport.viewSize=" + viewport.getViewSize() + "\n" + "viewport.viewRectangle=" + viewport.getViewRect() + "\n" + "leadingTabIndex=" + leadingTabIndex + "\n" + "tabViewPosition=" + tabViewPosition;

Does it make sense to break this long line?

src/java.desktop/share/classes/java/awt/image/DirectColorModel.java line 1414:

> 1412:                 + Integer.toHexString(green_mask) + " bmask="
> 1413:                 + Integer.toHexString(blue_mask) + " amask="
> 1414:                 + Integer.toHexString(alpha_mask);

Suggestion:

        return "DirectColorModel: rmask=" + Integer.toHexString(red_mask)
                + " gmask=" + Integer.toHexString(green_mask)
                + " bmask=" + Integer.toHexString(blue_mask)
                + " amask=" + Integer.toHexString(alpha_mask);

Is it easier to read?

src/java.desktop/share/classes/sun/awt/image/ShortBandedRaster.java line 806:

> 804: 
> 805:     public String toString() {
> 806:         return "ShortBandedRaster: width = " + width + " height = "

Maybe wrap `height` to the next line like it's done in several other files above?
Perhaps, wrap in all -Raster classes for consistency, also it's easier to read when each field is concatenated on its own line.

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

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


From aivanov at openjdk.java.net  Tue Sep  7 20:01:11 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Sep 2021 20:01:11 GMT
Subject: RFR: 8273168: Remove superfluous use of boxing in java.desktop
 [v2]
In-Reply-To: <wR-f__1H4jD2BPP2Pg01oTEawlU5BzrlatMmiJJRunQ=.0f4f558d-9449-4196-b45d-6b8d0acd3197@github.com>
References: <ENddbU3bDr91U0nC1Gztf9pIio2dIOzXFlitpqNmoso=.a201e7b5-184c-4424-9609-645095752540@github.com>
 <wR-f__1H4jD2BPP2Pg01oTEawlU5BzrlatMmiJJRunQ=.0f4f558d-9449-4196-b45d-6b8d0acd3197@github.com>
Message-ID: <gBb2ofp2EsH8fi8VnyWmyyBomzsnzHJ17xqIFAoXqOM=.da7d74db-f52a-4385-b57b-d202f3695eff@github.com>

On Wed, 1 Sep 2021 10:44:07 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> parseInt/parseLong/parseShort/parseByte/parseFloat should be preferred, as they return primitives. While valueOf returns boxed object.
>
> Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into redundant_boxing_in_java.desktop
>  - [PATCH] Cleanup redundant boxing in java.desktop module
>    parseInt/parseLong/parseShort/parseByte/parseFloat should be preferred, as they return primitives. While valueOf returns boxed object.

Marked as reviewed by aivanov (Reviewer).

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

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


From github.com+741251+turbanoff at openjdk.java.net  Tue Sep  7 21:16:07 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 7 Sep 2021 21:16:07 GMT
Subject: Integrated: 8273168: Remove superfluous use of boxing in java.desktop
In-Reply-To: <ENddbU3bDr91U0nC1Gztf9pIio2dIOzXFlitpqNmoso=.a201e7b5-184c-4424-9609-645095752540@github.com>
References: <ENddbU3bDr91U0nC1Gztf9pIio2dIOzXFlitpqNmoso=.a201e7b5-184c-4424-9609-645095752540@github.com>
Message-ID: <kN40WvPKsn3WZ7e57d9O0JmxNZCtd7ZhJUlwP-cGhlQ=.bbfcbde8-dbda-4389-a92d-738ecb35dcf2@github.com>

On Tue, 31 Aug 2021 07:37:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> parseInt/parseLong/parseShort/parseByte/parseFloat should be preferred, as they return primitives. While valueOf returns boxed object.

This pull request has now been integrated.

Changeset: 708407ed
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/708407eddc9d52c01de02e3986c05e1c6225fa85
Stats:     18 lines in 7 files changed: 0 ins; 1 del; 17 mod

8273168: Remove superfluous use of boxing in java.desktop

Reviewed-by: aivanov

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

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


From djgredler at gmail.com  Tue Sep  7 23:43:33 2021
From: djgredler at gmail.com (Daniel Gredler)
Date: Tue, 7 Sep 2021 19:43:33 -0400
Subject: JDK-8269888: Thai text rendered incorrectly using some
 AffineTransform-derived fonts
Message-ID: <CAPA+ug6qS_1XNBAX0GJprZ8wzJFEykvYCpSzeoxCQSWTjwPdUA@mail.gmail.com>

Hi all,

I'm trying to figure out a fix for JDK-8269888 [1]. The font that I'm using
to replicate the issue, Google Noto Sans Thai Regular [2], uses the GPOS
table internally. It looks like the GPOS adjustment in HB is a two-step
process, where HB first sets the glyph position x_offset using anchor data
from the GPOS table [3], and then adjusts that x_offset using existing
x_advance data [4], all coordinated via the
HB_BUFFER_SCRATCH_FLAG_HAS_GPOS_ATTACHMENT scratch flag.

Internally, OpenJDK is using the font_funcs virtual method functionality
[5] to customize most of the font property callbacks [6]. Java provides
users two ways to customize the size of a font: you can set the pt size, or
you can set an affine transform (scale, rotate, shear, translate, etc).
When you use the pt size approach, OpenJDK calls hb_font_set_scale with the
appropriate pt size [7]. However, when a scaling affine transform is used,
the pt size is technically unchanged, and a value of 1pt is used. Usually
this works fine, because Java's font_funcs callbacks are providing scaled
origin and advance numbers back to HB, but this breaks the two-step GPOS
attachment logic: the first step is not aware of the scaling applied by the
OpenJDK font_funcs callbacks (especially the
hb_font_get_glyph_h_advance_func_t), but the second step uses a scaled
advance value provided by an OpenJDK callback. In practice, at e.g. x50
scaling, this means that the first step sets the x_offset to a relatively
small value (e.g. 32899), but the second step adjusts the x_offset by a
relatively large value (e.g. 1612184).

A possible fix would be for OpenJDK to take the affine transform scale into
account when setting the font size via hb_font_set_scale, and the HarfBuzz
team has confirmed that this seems like the sensible approach [8]. In fact,
it seems like prior to 2016 this was indeed the case [9], but the logic was
changed to fix JDK-8145901 (Printed content is overlapping). JDK-8145901
doesn't seem to be public in the bug tracker, and I'm not sure where to
find the HB_NODEVTX trigger used to request initialization of devScale in
HBShaper.c, so I'm not sure how to fix JDK-8269888 without risking a
regression on JDK-8145901. Is devScale still needed? Can we use xPtSize and
yPtSize (instead of ptSize*devScale) in _hb_jdk_font_create() and
_hb_jdk_ct_font_create()? I've confirmed that using xPtSize and yPtSize
fixes the Thai text rendering use case, at least.

Thanks!

Daniel

[1] https://bugs.openjdk.java.net/browse/JDK-8269888
[2] https://www.google.com/get/noto/#sans-thai
[3]
https://github.com/harfbuzz/harfbuzz/blob/bbeb3a62b0efbb598d8683f7c4b6cc7069a58aeb/src/hb-ot-layout-gpos-table.hh#L708
[4]
https://github.com/harfbuzz/harfbuzz/blob/bbeb3a62b0efbb598d8683f7c4b6cc7069a58aeb/src/hb-ot-layout-gpos-table.hh#L2922
[5] https://harfbuzz.github.io/fonts-and-faces-custom-functions.html
[6]
https://github.com/openjdk/jdk/blob/005d8a7fca8b4d9519d2bde0a7cdbbece1cd3981/src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc#L271
[7]
https://github.com/openjdk/jdk/blob/005d8a7fca8b4d9519d2bde0a7cdbbece1cd3981/src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc#L422
[8] https://github.com/harfbuzz/harfbuzz/discussions/3191
[9]
https://github.com/openjdk/jdk/commit/5935292ae022e970bd4075de4d704719f3b05575#diff-6a155985752d3cc5ca8a74d4bf51c899d80ea0337e30029a4fafe856893456f3L327-L328


From pbansal at openjdk.java.net  Wed Sep  8 04:20:03 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 8 Sep 2021 04:20:03 GMT
Subject: RFR: JDK-8273387: remove some unreferenced gtk-related functions
In-Reply-To: <EwiIDZeQXrzO6JMqVJfrH8ShJt25y6dkMhneE2Pd1ws=.509bad60-6874-407f-bc27-a7ed7e089b0a@github.com>
References: <EwiIDZeQXrzO6JMqVJfrH8ShJt25y6dkMhneE2Pd1ws=.509bad60-6874-407f-bc27-a7ed7e089b0a@github.com>
Message-ID: <jPecbqOvTzEWRVpaCzwPG-5yIYrQv-FyFAquWPvB6kM=.5eb0963e-32cb-47b4-a686-a139e43103a3@github.com>

On Tue, 7 Sep 2021 07:29:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small change.
> Looks like there are a few functions, like gtk2_paint_diamond, that are unreferenced and can be removed.
> 
> Thanks, Matthias

src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c line 1853:

> 1851: }
> 1852: 
> 1853: static void gtk2_paint_diamond(WidgetType widget_type, GtkStateType state_type,

I think the function pointer initialiasation of this function `fp_gtk_paint_diamond` should also be removed along with removing the function definition.

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

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


From github.com+741251+turbanoff at openjdk.java.net  Wed Sep  8 04:40:18 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 8 Sep 2021 04:40:18 GMT
Subject: Integrated: 8271603: Unnecessary Vector usage in java.desktop
In-Reply-To: <hdHdAw2YkFb3bjjiY9aVTPYa92cFVn0reO2hlZR0vxw=.60aecb76-ae37-47d9-9650-486f5c513455@github.com>
References: <hdHdAw2YkFb3bjjiY9aVTPYa92cFVn0reO2hlZR0vxw=.60aecb76-ae37-47d9-9650-486f5c513455@github.com>
Message-ID: <soATMn1pu-pRQjO4kz7YNsC6h5x9WfiWM3KwOxCI65k=.44de4811-3b00-4bc9-abc6-b75d66fad158@github.com>

On Sun, 4 Jul 2021 20:42:41 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized.
> I checked only places where `Vector` was used as local variable.

This pull request has now been integrated.

Changeset: 1513dc7a
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1513dc7afc33386106439ccb9b7b16956b3c534a
Stats:     271 lines in 34 files changed: 19 ins; 31 del; 221 mod

8271603: Unnecessary Vector usage in java.desktop

Reviewed-by: prr, serb

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

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


From serb at openjdk.java.net  Wed Sep  8 06:27:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 8 Sep 2021 06:27:09 GMT
Subject: RFR: 8271923: [macos] the text color on the selected disabled
 tabbed pane button remains white making text unreadable [v2]
In-Reply-To: <mOq3GsnoeK9UpYOKlnwR40aWO9TtWAv54nlMJyqMZrU=.1eb29f34-bce2-431b-ab5c-38a78d9a5022@github.com>
References: <CfPWU8kqPqInYwtW5Ddzdj_C1yWCBrEIFDf9buMJixo=.d526022a-431d-4b53-93d2-e827a91bff44@github.com>
 <mOq3GsnoeK9UpYOKlnwR40aWO9TtWAv54nlMJyqMZrU=.1eb29f34-bce2-431b-ab5c-38a78d9a5022@github.com>
Message-ID: <US00XMu3qSdy6_JxnYuo6A4-cL9Nf-ig6a2ZwDOg-UA=.df43b16f-60e5-4793-8405-23a812f5e4c8@github.com>

On Mon, 6 Sep 2021 08:00:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It is seen that  if a JTabbedPane is unfocused, it's title is painted with **white** text on grey background 
>> as opposed to **black** text on grey background in unfoucsed native app on macOSX Catalina
>> and is somewhat not legible. 
>> This can be seen with SwingSet2 demo with InternalFrame or JTabbedPane demo and any native app, making focus toggle between the two.
>> 
>> Issue was TabbedPane always draw with "selectedTabTitleNormalColor" which is white. Although Aqua L&F defined selectedTabTitleDisabledColor but it is not used as TabbedPane does not check if focus is there in current frame and draw accordingly, which native app does.
>> 
>> Proposed fix is to check for frame is active or not and draw text color accordingly. 
>> Since it is not affecting BigSur (where even if native app active or not text is always drawn in same color), it is only restricted to Catalina and lower.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use NonFocus color

I just completed a review of the previous fix(JDK-8269984) for jdk11, and found that the text is still unreadable if the selected tab is pressed by the user, look like it is still reproduced after this fix as well, please take a look.

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

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


From mbaesken at openjdk.java.net  Wed Sep  8 07:03:39 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 8 Sep 2021 07:03:39 GMT
Subject: RFR: JDK-8273387: remove some unreferenced gtk-related functions
 [v2]
In-Reply-To: <EwiIDZeQXrzO6JMqVJfrH8ShJt25y6dkMhneE2Pd1ws=.509bad60-6874-407f-bc27-a7ed7e089b0a@github.com>
References: <EwiIDZeQXrzO6JMqVJfrH8ShJt25y6dkMhneE2Pd1ws=.509bad60-6874-407f-bc27-a7ed7e089b0a@github.com>
Message-ID: <d6_hESIFbflCUt8hlBiWeCNp_lStCbqLlg_TA8MV56g=.2a5e0db0-4f2c-45fe-b1c1-3bc08e211e7e@github.com>

> Please review this small change.
> Looks like there are a few functions, like gtk2_paint_diamond, that are unreferenced and can be removed.
> 
> Thanks, Matthias

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

  remove fp_gtk_paint_diamond function pointer init

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5384/files
  - new: https://git.openjdk.java.net/jdk/pull/5384/files/3434b114..627cffa0

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

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

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


From mbaesken at openjdk.java.net  Wed Sep  8 07:03:43 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 8 Sep 2021 07:03:43 GMT
Subject: RFR: JDK-8273387: remove some unreferenced gtk-related functions
 [v2]
In-Reply-To: <jPecbqOvTzEWRVpaCzwPG-5yIYrQv-FyFAquWPvB6kM=.5eb0963e-32cb-47b4-a686-a139e43103a3@github.com>
References: <EwiIDZeQXrzO6JMqVJfrH8ShJt25y6dkMhneE2Pd1ws=.509bad60-6874-407f-bc27-a7ed7e089b0a@github.com>
 <jPecbqOvTzEWRVpaCzwPG-5yIYrQv-FyFAquWPvB6kM=.5eb0963e-32cb-47b4-a686-a139e43103a3@github.com>
Message-ID: <guzN127LgXOKy2qB4CMaOAFWRyGZ0NEgCT565iI9zPk=.a0558d7d-2d2e-40af-b749-dc66d41d8add@github.com>

On Wed, 8 Sep 2021 04:17:10 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove fp_gtk_paint_diamond function pointer init
>
> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c line 1853:
> 
>> 1851: }
>> 1852: 
>> 1853: static void gtk2_paint_diamond(WidgetType widget_type, GtkStateType state_type,
> 
> I think the function pointer initialiasation of this function `fp_gtk_paint_diamond` should also be removed along with removing the function definition.

Thanks for the hint , I removed the initialization you mentioned.

Best regards, Matthias

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

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


From psadhukhan at openjdk.java.net  Wed Sep  8 08:31:10 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 8 Sep 2021 08:31:10 GMT
Subject: RFR: 8271923: [macos] the text color on the selected disabled
 tabbed pane button remains white making text unreadable [v2]
In-Reply-To: <mOq3GsnoeK9UpYOKlnwR40aWO9TtWAv54nlMJyqMZrU=.1eb29f34-bce2-431b-ab5c-38a78d9a5022@github.com>
References: <CfPWU8kqPqInYwtW5Ddzdj_C1yWCBrEIFDf9buMJixo=.d526022a-431d-4b53-93d2-e827a91bff44@github.com>
 <mOq3GsnoeK9UpYOKlnwR40aWO9TtWAv54nlMJyqMZrU=.1eb29f34-bce2-431b-ab5c-38a78d9a5022@github.com>
Message-ID: <0wl_2q4IkBWIjtwrEcnf-twadUX2sP3LnyYm8nOyVpU=.f0b4cc28-602b-4d9d-8417-a72f5c7344f8@github.com>

On Mon, 6 Sep 2021 08:00:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It is seen that  if a JTabbedPane is unfocused, it's title is painted with **white** text on grey background 
>> as opposed to **black** text on grey background in unfoucsed native app on macOSX Catalina
>> and is somewhat not legible. 
>> This can be seen with SwingSet2 demo with InternalFrame or JTabbedPane demo and any native app, making focus toggle between the two.
>> 
>> Issue was TabbedPane always draw with "selectedTabTitleNormalColor" which is white. Although Aqua L&F defined selectedTabTitleDisabledColor but it is not used as TabbedPane does not check if focus is there in current frame and draw accordingly, which native app does.
>> 
>> Proposed fix is to check for frame is active or not and draw text color accordingly. 
>> Since it is not affecting BigSur (where even if native app active or not text is always drawn in same color), it is only restricted to Catalina and lower.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use NonFocus color

It's not clear where you tried 8269984 and this fix, is it on BigSur or Catalina? FYI, this fix is to cater to Catalina problem and will not have any effect on BigSur.

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

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


From psadhukhan at openjdk.java.net  Wed Sep  8 09:12:25 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 8 Sep 2021 09:12:25 GMT
Subject: RFR: 8273478: [macos11] JTabbedPane selected and pressed tab is not
 legible
Message-ID: <e-ugeGbJPsC79Gzj1JnU8rVlYjIsQlP0_d-8FXyJYLA=.771ab22e-029b-44b1-b953-305933c3c8f1@github.com>

On macOS 11 (bigsur), using the Swing Aqua Look and Feel,
the text of the selected and "pressed" JTabbedPane tab title text is just a light gray outline of white text on a white background which is not readable. 
Fix is to use selectedControlTextColor for TabbedPane.selectedTabTitlePressedColor same as what we use for TabbedPane.selectedTabTitleNormalColor. Result is black over white text same as what is seen for native app pressed tabbedpane.

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

Commit messages:
 - 8273478: [macos11] JTabbedPane selected and pressed tab is not legible

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

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


From github.com+741251+turbanoff at openjdk.java.net  Wed Sep  8 09:43:11 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 8 Sep 2021 09:43:11 GMT
Subject: RFR: 8273375: Remove redundant 'new String' calls after
 concatenation in java.desktop
In-Reply-To: <HKwTu7MImJT_vXguMsnuHwbjNS3dVddJTmHLtlHlBxk=.b3813a9f-e8fd-4943-82de-b17367ceb8d0@github.com>
References: <tR92hTComDv55m6hbPjMJKmYojUYSl6cw6094uwpOS4=.bfb38bbe-4848-474b-b907-cdb35dad38fb@github.com>
 <HKwTu7MImJT_vXguMsnuHwbjNS3dVddJTmHLtlHlBxk=.b3813a9f-e8fd-4943-82de-b17367ceb8d0@github.com>
Message-ID: <46GNtaupcQShwP9tNfRGxaINU6OAYPZrmAztTTZDBoA=.823bea7e-b0c8-4eb8-8e6b-a3a13fda1461@github.com>

On Tue, 7 Sep 2021 19:33:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Result of string concatenation is a newly created `String` object. There is no need it wrap it in another `new String` call.
>> Such calls are confusing and produce warnings in IDE. Without them code is easier to read.
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java line 3209:
> 
>> 3207: 
>> 3208:         public String toString() {
>> 3209:             return "viewport.viewSize=" + viewport.getViewSize() + "\n" + "viewport.viewRectangle=" + viewport.getViewRect() + "\n" + "leadingTabIndex=" + leadingTabIndex + "\n" + "tabViewPosition=" + tabViewPosition;
> 
> Does it make sense to break this long line?

Improved

> src/java.desktop/share/classes/java/awt/image/DirectColorModel.java line 1414:
> 
>> 1412:                 + Integer.toHexString(green_mask) + " bmask="
>> 1413:                 + Integer.toHexString(blue_mask) + " amask="
>> 1414:                 + Integer.toHexString(alpha_mask);
> 
> Suggestion:
> 
>         return "DirectColorModel: rmask=" + Integer.toHexString(red_mask)
>                 + " gmask=" + Integer.toHexString(green_mask)
>                 + " bmask=" + Integer.toHexString(blue_mask)
>                 + " amask=" + Integer.toHexString(alpha_mask);
> 
> Is it easier to read?

Thank you for suggestion

> src/java.desktop/share/classes/sun/awt/image/ShortBandedRaster.java line 806:
> 
>> 804: 
>> 805:     public String toString() {
>> 806:         return "ShortBandedRaster: width = " + width + " height = "
> 
> Maybe wrap `height` to the next line like it's done in several other files above?
> Perhaps, wrap in all -Raster classes for consistency, also it's easier to read when each field is concatenated on its own line.

did it

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

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


From github.com+741251+turbanoff at openjdk.java.net  Wed Sep  8 09:49:25 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 8 Sep 2021 09:49:25 GMT
Subject: RFR: 8273375: Remove redundant 'new String' calls after
 concatenation in java.desktop [v2]
In-Reply-To: <tR92hTComDv55m6hbPjMJKmYojUYSl6cw6094uwpOS4=.bfb38bbe-4848-474b-b907-cdb35dad38fb@github.com>
References: <tR92hTComDv55m6hbPjMJKmYojUYSl6cw6094uwpOS4=.bfb38bbe-4848-474b-b907-cdb35dad38fb@github.com>
Message-ID: <UWgD9fgoDe29ArcTzvx4wVudIe1GgkHsXY10CCMfSaA=.1ecc5e67-9533-4ec8-94c9-a9be71da536d@github.com>

> Result of string concatenation is a newly created `String` object. There is no need it wrap it in another `new String` call.
> Such calls are confusing and produce warnings in IDE. Without them code is easier to read.

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

  8273375: Remove redundant 'new String' calls after concatenation in java.desktop
  post-review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5356/files
  - new: https://git.openjdk.java.net/jdk/pull/5356/files/4f70a7e8..a4fd58fe

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

  Stats: 21 lines in 7 files changed: 5 ins; 1 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5356.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5356/head:pull/5356

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


From pbansal at openjdk.java.net  Wed Sep  8 11:38:08 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 8 Sep 2021 11:38:08 GMT
Subject: RFR: JDK-8273387: remove some unreferenced gtk-related functions
 [v2]
In-Reply-To: <guzN127LgXOKy2qB4CMaOAFWRyGZ0NEgCT565iI9zPk=.a0558d7d-2d2e-40af-b749-dc66d41d8add@github.com>
References: <EwiIDZeQXrzO6JMqVJfrH8ShJt25y6dkMhneE2Pd1ws=.509bad60-6874-407f-bc27-a7ed7e089b0a@github.com>
 <jPecbqOvTzEWRVpaCzwPG-5yIYrQv-FyFAquWPvB6kM=.5eb0963e-32cb-47b4-a686-a139e43103a3@github.com>
 <guzN127LgXOKy2qB4CMaOAFWRyGZ0NEgCT565iI9zPk=.a0558d7d-2d2e-40af-b749-dc66d41d8add@github.com>
Message-ID: <H8XfgpPAPf6oXRRvy4fjrWQt2FtZBUW2sDF8gLLIWnQ=.8d0416f9-ac75-48ca-8cee-fdfa34351139@github.com>

On Wed, 8 Sep 2021 07:00:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c line 1853:
>> 
>>> 1851: }
>>> 1852: 
>>> 1853: static void gtk2_paint_diamond(WidgetType widget_type, GtkStateType state_type,
>> 
>> I think the function pointer initialiasation of this function `fp_gtk_paint_diamond` should also be removed along with removing the function definition.
>
> Thanks for the hint , I removed the initialization you mentioned.
> 
> Best regards, Matthias

I think the declaration of function pointer should also be removed. So following should be removed from line no 150
static void (*fp_gtk_paint_diamond)(GtkStyle* style, GdkWindow* window,
        GtkStateType state_type, GtkShadowType shadow_type,
        GdkRectangle* area, GtkWidget* widget, const gchar* detail,
        gint x, gint y, gint width, gint height);

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

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


From mbaesken at openjdk.java.net  Wed Sep  8 11:56:39 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 8 Sep 2021 11:56:39 GMT
Subject: RFR: JDK-8273387: remove some unreferenced gtk-related functions
 [v3]
In-Reply-To: <EwiIDZeQXrzO6JMqVJfrH8ShJt25y6dkMhneE2Pd1ws=.509bad60-6874-407f-bc27-a7ed7e089b0a@github.com>
References: <EwiIDZeQXrzO6JMqVJfrH8ShJt25y6dkMhneE2Pd1ws=.509bad60-6874-407f-bc27-a7ed7e089b0a@github.com>
Message-ID: <3sW8mv3EAFgTsTdUFAP-UvaKtUO6Afm3ytFb6sln_eI=.aa922086-cb72-4144-bf59-acc4941df9f3@github.com>

> Please review this small change.
> Looks like there are a few functions, like gtk2_paint_diamond, that are unreferenced and can be removed.
> 
> Thanks, Matthias

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

  remove declaration

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5384/files
  - new: https://git.openjdk.java.net/jdk/pull/5384/files/627cffa0..46b90ad9

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

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

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


From mbaesken at openjdk.java.net  Wed Sep  8 11:56:41 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 8 Sep 2021 11:56:41 GMT
Subject: RFR: JDK-8273387: remove some unreferenced gtk-related functions
 [v3]
In-Reply-To: <H8XfgpPAPf6oXRRvy4fjrWQt2FtZBUW2sDF8gLLIWnQ=.8d0416f9-ac75-48ca-8cee-fdfa34351139@github.com>
References: <EwiIDZeQXrzO6JMqVJfrH8ShJt25y6dkMhneE2Pd1ws=.509bad60-6874-407f-bc27-a7ed7e089b0a@github.com>
 <jPecbqOvTzEWRVpaCzwPG-5yIYrQv-FyFAquWPvB6kM=.5eb0963e-32cb-47b4-a686-a139e43103a3@github.com>
 <guzN127LgXOKy2qB4CMaOAFWRyGZ0NEgCT565iI9zPk=.a0558d7d-2d2e-40af-b749-dc66d41d8add@github.com>
 <H8XfgpPAPf6oXRRvy4fjrWQt2FtZBUW2sDF8gLLIWnQ=.8d0416f9-ac75-48ca-8cee-fdfa34351139@github.com>
Message-ID: <H77uqKQo6r4l_3F8TDrLiIpYFrdkRmK1CxmQFmTk6bQ=.cdc316d1-5629-417a-8d25-6d9727a7cefa@github.com>

On Wed, 8 Sep 2021 11:34:48 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Thanks for the hint , I removed the initialization you mentioned.
>> 
>> Best regards, Matthias
>
> I think the declaration of function pointer should also be removed. So following should be removed from line no 150
> static void (*fp_gtk_paint_diamond)(GtkStyle* style, GdkWindow* window,
>         GtkStateType state_type, GtkShadowType shadow_type,
>         GdkRectangle* area, GtkWidget* widget, const gchar* detail,
>         gint x, gint y, gint width, gint height);

Thanks, I removed the declaration you mentioned.
Best regards, Matthias

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

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


From aivanov at openjdk.java.net  Wed Sep  8 12:41:09 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 8 Sep 2021 12:41:09 GMT
Subject: RFR: 8273375: Remove redundant 'new String' calls after
 concatenation in java.desktop [v2]
In-Reply-To: <UWgD9fgoDe29ArcTzvx4wVudIe1GgkHsXY10CCMfSaA=.1ecc5e67-9533-4ec8-94c9-a9be71da536d@github.com>
References: <tR92hTComDv55m6hbPjMJKmYojUYSl6cw6094uwpOS4=.bfb38bbe-4848-474b-b907-cdb35dad38fb@github.com>
 <UWgD9fgoDe29ArcTzvx4wVudIe1GgkHsXY10CCMfSaA=.1ecc5e67-9533-4ec8-94c9-a9be71da536d@github.com>
Message-ID: <avppVjWh-c0gDiL1rrxqMAD0FxanJQBPm0PGbREoCX8=.8fedd9e0-7ac8-414c-9250-9ac5e22afc77@github.com>

On Wed, 8 Sep 2021 09:49:25 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Result of string concatenation is a newly created `String` object. There is no need it wrap it in another `new String` call.
>> Such calls are confusing and produce warnings in IDE. Without them code is easier to read.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273375: Remove redundant 'new String' calls after concatenation in java.desktop
>   post-review

Marked as reviewed by aivanov (Reviewer).

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

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


From github.com+741251+turbanoff at openjdk.java.net  Wed Sep  8 14:31:14 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 8 Sep 2021 14:31:14 GMT
Subject: Integrated: 8273375: Remove redundant 'new String' calls after
 concatenation in java.desktop
In-Reply-To: <tR92hTComDv55m6hbPjMJKmYojUYSl6cw6094uwpOS4=.bfb38bbe-4848-474b-b907-cdb35dad38fb@github.com>
References: <tR92hTComDv55m6hbPjMJKmYojUYSl6cw6094uwpOS4=.bfb38bbe-4848-474b-b907-cdb35dad38fb@github.com>
Message-ID: <b3irZEGJMfTHP7r4OIGxEfQA_YyRkcdI32g9iITbViU=.37f023c0-6337-4aab-a3ec-297bdddc9832@github.com>

On Fri, 3 Sep 2021 07:53:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Result of string concatenation is a newly created `String` object. There is no need it wrap it in another `new String` call.
> Such calls are confusing and produce warnings in IDE. Without them code is easier to read.

This pull request has now been integrated.

Changeset: 59c9f750
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/59c9f750414e4f131c906a5bc20f32f2f9cfe9ec
Stats:     96 lines in 15 files changed: 13 ins; 3 del; 80 mod

8273375: Remove redundant 'new String' calls after concatenation in java.desktop

Reviewed-by: aivanov

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

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


From javalists at cbfiddle.com  Wed Sep  8 16:23:22 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 8 Sep 2021 09:23:22 -0700
Subject: [+AWTFont nsFontForJavaFont:env:]
Message-ID: <DFB8AB8E-9430-497A-B8EE-3BC1759A4B3D@cbfiddle.com>

Is this method obsolete?

I?m not finding any uses. (Actually, IDEA is not finding any uses. Perhaps the index is broken?)

  Alan



From prr at openjdk.java.net  Wed Sep  8 16:58:25 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 8 Sep 2021 16:58:25 GMT
Subject: RFR: 8273358: macOS Monterey does not have the font Times needed by
 Serif
Message-ID: <aAHjceTUeA1BFRU7WVvTO-UrfDLtFUn7c5W-pnycVfs=.47947ed1-82ba-4dc0-9820-2b7280426bf8@github.com>

Times has been the hard coded name for Serif in the JDK sources for macOS since the port was contributed by Apple.
But it seems that macOS Monterey doesn't have this font.
And the hard-coded fallback is also Times ! So we end up returning Dialog which is very bad.

The safest fix here is to make Times New Roman the fall back, so that on older macOS versions there
is absolutely no change. Only on Monterey and presumably later, will it use Times New Roman which,
I suspect, is what Times actually ends up being anyway.

Also to prevent unconditional warnings being printed I needed to change those to be conditional on logging being set.

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

Commit messages:
 - 8273358: macOS Monterey does not have the font Times needed by Serif

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

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


From serb at openjdk.java.net  Wed Sep  8 18:22:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 8 Sep 2021 18:22:10 GMT
Subject: RFR: 8271923: [macos] the text color on the selected disabled
 tabbed pane button remains white making text unreadable [v2]
In-Reply-To: <mOq3GsnoeK9UpYOKlnwR40aWO9TtWAv54nlMJyqMZrU=.1eb29f34-bce2-431b-ab5c-38a78d9a5022@github.com>
References: <CfPWU8kqPqInYwtW5Ddzdj_C1yWCBrEIFDf9buMJixo=.d526022a-431d-4b53-93d2-e827a91bff44@github.com>
 <mOq3GsnoeK9UpYOKlnwR40aWO9TtWAv54nlMJyqMZrU=.1eb29f34-bce2-431b-ab5c-38a78d9a5022@github.com>
Message-ID: <GQ763yasfl5tFqAEZhoyB0rNcdUtLDc8EghVu5PA4Ek=.8fe51f8d-e055-4e94-9e49-6b75881ba2de@github.com>

On Mon, 6 Sep 2021 08:00:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It is seen that  if a JTabbedPane is unfocused, it's title is painted with **white** text on grey background 
>> as opposed to **black** text on grey background in unfoucsed native app on macOSX Catalina
>> and is somewhat not legible. 
>> This can be seen with SwingSet2 demo with InternalFrame or JTabbedPane demo and any native app, making focus toggle between the two.
>> 
>> Issue was TabbedPane always draw with "selectedTabTitleNormalColor" which is white. Although Aqua L&F defined selectedTabTitleDisabledColor but it is not used as TabbedPane does not check if focus is there in current frame and draw accordingly, which native app does.
>> 
>> Proposed fix is to check for frame is active or not and draw text color accordingly. 
>> Since it is not affecting BigSur (where even if native app active or not text is always drawn in same color), it is only restricted to Catalina and lower.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use NonFocus color

I tested macos 11.5

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

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


From philip.race at oracle.com  Wed Sep  8 18:39:47 2021
From: philip.race at oracle.com (Philip Race)
Date: Wed, 8 Sep 2021 11:39:47 -0700
Subject: JDK-8269888: Thai text rendered incorrectly using some
 AffineTransform-derived fonts
In-Reply-To: <CAPA+ug6qS_1XNBAX0GJprZ8wzJFEykvYCpSzeoxCQSWTjwPdUA@mail.gmail.com>
References: <CAPA+ug6qS_1XNBAX0GJprZ8wzJFEykvYCpSzeoxCQSWTjwPdUA@mail.gmail.com>
Message-ID: <446d493d-ca0b-3244-7184-7c4e3f7b9f94@oracle.com>

JDK-8145901 isn't accessible because some confidential information is in the description and attachments ..
and in fact it was JCK failure so we need to be careful not to regress that
But I guess you found the changeset for it.

The problem we were trying to solve there was
===
The font interface supplied to harfbuzz is setting the point size (scale)
based on the device size font. When printing, this is scaled from the
user size font by (typically) around 4X.
So when performing a kerning adjustment the affected glyphs are
moved accordingly.

But advances are being provided in user space and so the kerning
adjustment is too great relative to the advances.==== I'd need to spend 
some time refreshing my memory on this 5 yr old issue so I can't say 
offhand that what you propose won't need fix up elsewhere. But I can say 
that testing this will need to do on screen rendering as well as 
printing of kerned and ligatured text under various tranforms .. inc. 
rotations, scales, -phil.


On 9/7/21 4:43 PM, Daniel Gredler wrote:
> Hi all,
>
> I'm trying to figure out a fix for JDK-8269888 [1]. The font that I'm using
> to replicate the issue, Google Noto Sans Thai Regular [2], uses the GPOS
> table internally. It looks like the GPOS adjustment in HB is a two-step
> process, where HB first sets the glyph position x_offset using anchor data
> from the GPOS table [3], and then adjusts that x_offset using existing
> x_advance data [4], all coordinated via the
> HB_BUFFER_SCRATCH_FLAG_HAS_GPOS_ATTACHMENT scratch flag.
>
> Internally, OpenJDK is using the font_funcs virtual method functionality
> [5] to customize most of the font property callbacks [6]. Java provides
> users two ways to customize the size of a font: you can set the pt size, or
> you can set an affine transform (scale, rotate, shear, translate, etc).
> When you use the pt size approach, OpenJDK calls hb_font_set_scale with the
> appropriate pt size [7]. However, when a scaling affine transform is used,
> the pt size is technically unchanged, and a value of 1pt is used. Usually
> this works fine, because Java's font_funcs callbacks are providing scaled
> origin and advance numbers back to HB, but this breaks the two-step GPOS
> attachment logic: the first step is not aware of the scaling applied by the
> OpenJDK font_funcs callbacks (especially the
> hb_font_get_glyph_h_advance_func_t), but the second step uses a scaled
> advance value provided by an OpenJDK callback. In practice, at e.g. x50
> scaling, this means that the first step sets the x_offset to a relatively
> small value (e.g. 32899), but the second step adjusts the x_offset by a
> relatively large value (e.g. 1612184).
>
> A possible fix would be for OpenJDK to take the affine transform scale into
> account when setting the font size via hb_font_set_scale, and the HarfBuzz
> team has confirmed that this seems like the sensible approach [8]. In fact,
> it seems like prior to 2016 this was indeed the case [9], but the logic was
> changed to fix JDK-8145901 (Printed content is overlapping). JDK-8145901
> doesn't seem to be public in the bug tracker, and I'm not sure where to
> find the HB_NODEVTX trigger used to request initialization of devScale in
> HBShaper.c, so I'm not sure how to fix JDK-8269888 without risking a
> regression on JDK-8145901. Is devScale still needed? Can we use xPtSize and
> yPtSize (instead of ptSize*devScale) in _hb_jdk_font_create() and
> _hb_jdk_ct_font_create()? I've confirmed that using xPtSize and yPtSize
> fixes the Thai text rendering use case, at least.
>
> Thanks!
>
> Daniel
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8269888
> [2] https://www.google.com/get/noto/#sans-thai
> [3]
> https://github.com/harfbuzz/harfbuzz/blob/bbeb3a62b0efbb598d8683f7c4b6cc7069a58aeb/src/hb-ot-layout-gpos-table.hh#L708
> [4]
> https://github.com/harfbuzz/harfbuzz/blob/bbeb3a62b0efbb598d8683f7c4b6cc7069a58aeb/src/hb-ot-layout-gpos-table.hh#L2922
> [5] https://harfbuzz.github.io/fonts-and-faces-custom-functions.html
> [6]
> https://github.com/openjdk/jdk/blob/005d8a7fca8b4d9519d2bde0a7cdbbece1cd3981/src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc#L271
> [7]
> https://github.com/openjdk/jdk/blob/005d8a7fca8b4d9519d2bde0a7cdbbece1cd3981/src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc#L422
> [8] https://github.com/harfbuzz/harfbuzz/discussions/3191
> [9]
> https://github.com/openjdk/jdk/commit/5935292ae022e970bd4075de4d704719f3b05575#diff-6a155985752d3cc5ca8a74d4bf51c899d80ea0337e30029a4fafe856893456f3L327-L328



From kizune at openjdk.java.net  Wed Sep  8 20:39:05 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 8 Sep 2021 20:39:05 GMT
Subject: RFR: 8273358: macOS Monterey does not have the font Times needed
 by Serif
In-Reply-To: <aAHjceTUeA1BFRU7WVvTO-UrfDLtFUn7c5W-pnycVfs=.47947ed1-82ba-4dc0-9820-2b7280426bf8@github.com>
References: <aAHjceTUeA1BFRU7WVvTO-UrfDLtFUn7c5W-pnycVfs=.47947ed1-82ba-4dc0-9820-2b7280426bf8@github.com>
Message-ID: <BdmSBcRNawS5DiyfI8kDKgDOwQoaMoBJ5ouHuvtfewk=.cd4b3b47-a03f-466a-bfb9-2d1c5abff781@github.com>

On Wed, 8 Sep 2021 16:49:26 GMT, Phil Race <prr at openjdk.org> wrote:

> Times has been the hard coded name for Serif in the JDK sources for macOS since the port was contributed by Apple.
> But it seems that macOS Monterey doesn't have this font.
> And the hard-coded fallback is also Times ! So we end up returning Dialog which is very bad.
> 
> The safest fix here is to make Times New Roman the fall back, so that on older macOS versions there
> is absolutely no change. Only on Monterey and presumably later, will it use Times New Roman which,
> I suspect, is what Times actually ends up being anyway.
> 
> Also to prevent unconditional warnings being printed I needed to change those to be conditional on logging being set.

Marked as reviewed by kizune (Reviewer).

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

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


From serb at openjdk.java.net  Wed Sep  8 21:04:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 8 Sep 2021 21:04:06 GMT
Subject: RFR: 8268084: [macos] Disabled JMenuItem arrow is not disabled
 [v5]
In-Reply-To: <i1xlwr387bfisRrBrNagDgNuFFIyIV2T4seRwDzOA3s=.239c555b-fbf4-4639-ad89-cfef3909f0c2@github.com>
References: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>
 <i1xlwr387bfisRrBrNagDgNuFFIyIV2T4seRwDzOA3s=.239c555b-fbf4-4639-ad89-cfef3909f0c2@github.com>
Message-ID: <aCddUqnZVsQt14GqHM0nbISBwfQ1uR6SqFRr3THAffE=.799b11c7-9c56-4c70-af81-3a8e9360df11@github.com>

On Sat, 4 Sep 2021 11:09:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It is seen in macos disabled JMenuItem arrow is not disabled even though JMenuItem itself is disabled.
>> In native app, same menuitem arrow is disabled for disabled menuitem.
>> 
>> Issue is when AquaMenuPainter#paintMenuItem() is called, it tries to draw a ImageIcon image of the arrow via ImageIcon#paintIcon which tries to generate MultiResolutionCachedImage via getResolutionVariant() by calling AquaUtils#generateFilteredImage.
>> It does not take into account if disabled arrow icon image needs to be drawn or not, so it is always enabled.
>> 
>> Proposed fix is to generate a disabled ImageIcon image of the same arrow icon and use it for disabled state.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add menuitem checkicon test

src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java line 235:

> 233:     static class InvertableImageIcon extends ImageIcon implements InvertableIcon, UIResource {
> 234:         Icon invertedImage;
> 235:         Icon disabledIcon;

could be private

src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java line 244:

> 242:             if (!c.isEnabled()) {
> 243:                 if (disabledIcon == null) {
> 244:                     disabledIcon = new ImageIconUIResource(GrayFilter.

It is not necessary to use ImageIconUIResource since we never return this image but only draw it.

src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java line 254:

> 252: 
> 253:         @Override
> 254:         public Icon getInvertedIcon() {

When we draw result of this method? Is it possible that we use the getInvertedIcon for disabled menus as well?

test/jdk/javax/swing/plaf/aqua/JMenuItemDisableArrowButtonTest.java line 27:

> 25:  * @requires (os.family == "mac")
> 26:  * @bug 8268084
> 27:  * @summary  Verifies disabled JMenuItem arrow is disabled

arrow and check

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Wed Sep  8 22:00:22 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Wed, 8 Sep 2021 22:00:22 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2
Message-ID: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>

removed support for running demo from applet for J2Ddemo and SwingSet2
same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)

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

Commit messages:
 - 8205137: Remove Applet support from SwingSet2
 - 8205139: Remove Applet support from J2Ddemo

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

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


From serb at openjdk.java.net  Wed Sep  8 22:34:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 8 Sep 2021 22:34:57 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2
In-Reply-To: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
Message-ID: <k_RySD8RuLWx_WRXv8lL8EzMOVn7AqR1BP8I7allV_E=.eb42d34f-10d8-435e-9545-146d1057ad43@github.com>

On Tue, 7 Sep 2021 22:08:58 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> removed support for running demo from applet for J2Ddemo and SwingSet2
> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)

Probably the README in the "jdk/src/demo/share/" should be updated as well?
This block looks outdated:

In some cases, the default security settings may block an execution
of demo applets in a browser. To adjust the security settings, please
refer to the following resource:

http://java.com/en/download/help/java_blocked.xml

Some demo applets need to be accessed through the HTTP or HTTPS
protocols to enable access to the required resources.

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

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


From mik3hall at gmail.com  Wed Sep  8 22:50:33 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 8 Sep 2021 17:50:33 -0500
Subject: [+AWTFont nsFontForJavaFont:env:]
In-Reply-To: <DFB8AB8E-9430-497A-B8EE-3BC1759A4B3D@cbfiddle.com>
References: <DFB8AB8E-9430-497A-B8EE-3BC1759A4B3D@cbfiddle.com>
Message-ID: <153CFA27-41D7-41CF-B7A8-5DF7A58E615F@gmail.com>



> On Sep 8, 2021, at 11:23 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> Is this method obsolete?
> 
> I?m not finding any uses. (Actually, IDEA is not finding any uses. Perhaps the index is broken?)
> 
>  Alan
> 

BBEdit search of recent JDK GitHub clone only shows

~/jdk/src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.h:41: + (NSFont *) nsFontForJavaFont:(jobject)javaFont env:(JNIEnv *)env;
~/jdk/src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.m:116: + (NSFont *) nsFontForJavaFont:(jobject)javaFont env:(JNIEnv *)env {

No references in src directory.

From prr at openjdk.java.net  Wed Sep  8 23:56:03 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 8 Sep 2021 23:56:03 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2
In-Reply-To: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
Message-ID: <PjT-YC4WSKOqoH_LZ7yA_Nvz9kOBPoilBJYsqD-XY_k=.ff3c4dd9-2f55-4dd6-9426-609c65dfbb8d@github.com>

On Tue, 7 Sep 2021 22:08:58 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> removed support for running demo from applet for J2Ddemo and SwingSet2
> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)

The files that have JUST a (c) date update should all be reverted. You haven't touched them so there is nothing to (c).

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Thu Sep  9 00:03:01 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Thu, 9 Sep 2021 00:03:01 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2
In-Reply-To: <PjT-YC4WSKOqoH_LZ7yA_Nvz9kOBPoilBJYsqD-XY_k=.ff3c4dd9-2f55-4dd6-9426-609c65dfbb8d@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <PjT-YC4WSKOqoH_LZ7yA_Nvz9kOBPoilBJYsqD-XY_k=.ff3c4dd9-2f55-4dd6-9426-609c65dfbb8d@github.com>
Message-ID: <PIwTD66jO2PuF41ohV0Nh7sQp7vNisT-S_RNZSmqlJE=.0d9d4926-1643-4766-ba78-bdf8d8e873eb@github.com>

On Wed, 8 Sep 2021 23:52:32 GMT, Phil Race <prr at openjdk.org> wrote:

> The files that have JUST a (c) date update should all be reverted. You haven't touched them so there is nothing to (c).

I just removed the java.applet.* import for all of them. Should I revert the date if there's no other content change?

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

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


From avu at openjdk.java.net  Thu Sep  9 00:16:01 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Thu, 9 Sep 2021 00:16:01 GMT
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1
In-Reply-To: <gPtzMfGUoBCDlQnVy17AZgjRzcs32op73LIk64YQuhc=.bce7ff9c-cc45-453d-bac7-1c93e4c38033@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
 <SNyuR1X22y8s5fgY2SxbBC4YnTsbwRVGaDueDJUafGA=.b712f798-b360-4894-8efb-164f16010c9e@github.com>
 <gPtzMfGUoBCDlQnVy17AZgjRzcs32op73LIk64YQuhc=.bce7ff9c-cc45-453d-bac7-1c93e4c38033@github.com>
Message-ID: <9bL2RnessX94pH3VPEC3uDrofP1pI5zZDVdMk3fKNLA=.9fc8cb35-1dcf-4a18-bce7-185d06318fca@github.com>

On Sun, 5 Sep 2021 12:00:18 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> > Is it possible that the problem is in the performance, what happens if you just add a delay at that place to wait while the metal layer will be updated from the previous calls to updateOpaque?
> 
> I'll check it.

I did some more investigation and the answer is no, it's not a performance issue. The problem is that we never set the opacity to the platform window on IDEA tooltip appearance because of caching code in LWWindowPeer.setOpaque() that is called from  LWWindowPeer.initializeImpl. So, I think that a direct setting in the place that I've suggested is necessary.

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

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


From vdyakov at openjdk.java.net  Thu Sep  9 00:27:58 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Thu, 9 Sep 2021 00:27:58 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2
In-Reply-To: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
Message-ID: <GwGyhaFAMCqRNV0qW4Rd2SpGQB8QSagcJ-J2GQkby2I=.212a29f1-d444-4ca6-8875-381497f018b5@github.com>

On Tue, 7 Sep 2021 22:08:58 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> removed support for running demo from applet for J2Ddemo and SwingSet2
> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)

@azuev-java  please review

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

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


From prr at openjdk.java.net  Thu Sep  9 03:48:58 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 9 Sep 2021 03:48:58 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2
In-Reply-To: <PIwTD66jO2PuF41ohV0Nh7sQp7vNisT-S_RNZSmqlJE=.0d9d4926-1643-4766-ba78-bdf8d8e873eb@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <PjT-YC4WSKOqoH_LZ7yA_Nvz9kOBPoilBJYsqD-XY_k=.ff3c4dd9-2f55-4dd6-9426-609c65dfbb8d@github.com>
 <PIwTD66jO2PuF41ohV0Nh7sQp7vNisT-S_RNZSmqlJE=.0d9d4926-1643-4766-ba78-bdf8d8e873eb@github.com>
Message-ID: <5wxrXjnQvpCWFWsE92_LbQph-4FWGo8Hx-gLr2YhKTk=.cf1d8b1b-58d1-4bc5-8203-a4790923ec9f@github.com>

On Wed, 8 Sep 2021 23:59:34 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> > The files that have JUST a (c) date update should all be reverted. You haven't touched them so there is nothing to (c).
> 
> I just removed the java.applet.* import for all of them. Should I revert the date if there's no other content change?

Hmm .. I missed the delete.
Well .. what were those imports for ? Nothing used them.
Now, although arguably a separate issue, we have precedent for cleaning up imports at such a time.
There are LOTS of wild card imports. 
I'd like you to update this to current practice to explicitly enumerate the classes needed
so rather than 
import java.util.*;

import java.util.Map
etc ..
JUST those needed.

Then we may actually have something worthy of updating a (c) ..

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

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


From psadhukhan at openjdk.java.net  Thu Sep  9 05:13:08 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 9 Sep 2021 05:13:08 GMT
Subject: RFR: 8271923: [macos] the text color on the selected disabled
 tabbed pane button remains white making text unreadable [v2]
In-Reply-To: <mOq3GsnoeK9UpYOKlnwR40aWO9TtWAv54nlMJyqMZrU=.1eb29f34-bce2-431b-ab5c-38a78d9a5022@github.com>
References: <CfPWU8kqPqInYwtW5Ddzdj_C1yWCBrEIFDf9buMJixo=.d526022a-431d-4b53-93d2-e827a91bff44@github.com>
 <mOq3GsnoeK9UpYOKlnwR40aWO9TtWAv54nlMJyqMZrU=.1eb29f34-bce2-431b-ab5c-38a78d9a5022@github.com>
Message-ID: <7yhGJyiMRwZl8rMEbzZ_yya34m2Ds-LWqldj96YZzBM=.892bea30-f297-4ce6-be8c-51a1ff7a5e93@github.com>

On Mon, 6 Sep 2021 08:00:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It is seen that  if a JTabbedPane is unfocused, it's title is painted with **white** text on grey background 
>> as opposed to **black** text on grey background in unfoucsed native app on macOSX Catalina
>> and is somewhat not legible. 
>> This can be seen with SwingSet2 demo with InternalFrame or JTabbedPane demo and any native app, making focus toggle between the two.
>> 
>> Issue was TabbedPane always draw with "selectedTabTitleNormalColor" which is white. Although Aqua L&F defined selectedTabTitleDisabledColor but it is not used as TabbedPane does not check if focus is there in current frame and draw accordingly, which native app does.
>> 
>> Proposed fix is to check for frame is active or not and draw text color accordingly. 
>> Since it is not affecting BigSur (where even if native app active or not text is always drawn in same color), it is only restricted to Catalina and lower.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use NonFocus color

I raised https://git.openjdk.java.net/jdk/pull/5409 for the "pressed" issue on BigSur.

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

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


From serb at openjdk.java.net  Thu Sep  9 05:13:59 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 9 Sep 2021 05:13:59 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2
In-Reply-To: <5wxrXjnQvpCWFWsE92_LbQph-4FWGo8Hx-gLr2YhKTk=.cf1d8b1b-58d1-4bc5-8203-a4790923ec9f@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <PjT-YC4WSKOqoH_LZ7yA_Nvz9kOBPoilBJYsqD-XY_k=.ff3c4dd9-2f55-4dd6-9426-609c65dfbb8d@github.com>
 <PIwTD66jO2PuF41ohV0Nh7sQp7vNisT-S_RNZSmqlJE=.0d9d4926-1643-4766-ba78-bdf8d8e873eb@github.com>
 <5wxrXjnQvpCWFWsE92_LbQph-4FWGo8Hx-gLr2YhKTk=.cf1d8b1b-58d1-4bc5-8203-a4790923ec9f@github.com>
Message-ID: <r51UucVSgrYcMgb-6vZgV4Gdc2z4X3xcS9nBQ3Kxlmk=.fd1b386a-22c7-4fb9-9f5e-45296acecc3c@github.com>

On Thu, 9 Sep 2021 03:46:00 GMT, Phil Race <prr at openjdk.org> wrote:

> Hmm .. I missed the delete.
> Well .. what were those imports for ? Nothing used them.
> Now, although arguably a separate issue, we have precedent for cleaning up imports at such a time.

This helped to prove that the usage of applets is actually removed from these files, I found it quite useful during the review.

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

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


From pbansal at openjdk.java.net  Thu Sep  9 05:32:02 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 9 Sep 2021 05:32:02 GMT
Subject: RFR: JDK-8273387: remove some unreferenced gtk-related functions
 [v3]
In-Reply-To: <3sW8mv3EAFgTsTdUFAP-UvaKtUO6Afm3ytFb6sln_eI=.aa922086-cb72-4144-bf59-acc4941df9f3@github.com>
References: <EwiIDZeQXrzO6JMqVJfrH8ShJt25y6dkMhneE2Pd1ws=.509bad60-6874-407f-bc27-a7ed7e089b0a@github.com>
 <3sW8mv3EAFgTsTdUFAP-UvaKtUO6Afm3ytFb6sln_eI=.aa922086-cb72-4144-bf59-acc4941df9f3@github.com>
Message-ID: <VCMrBRXRaIyflasn1DF5FxyJEoMEFF6LCjTXnfAHNk4=.59ead9ed-febd-4d16-881a-26532c88c53e@github.com>

On Wed, 8 Sep 2021 11:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Please review this small change.
>> Looks like there are a few functions, like gtk2_paint_diamond, that are unreferenced and can be removed.
>> 
>> Thanks, Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove declaration

Looks good to me now. I have run SwingSet2 with both gtk2 and gtk3

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

Marked as reviewed by pbansal (Reviewer).

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


From serb at openjdk.java.net  Thu Sep  9 05:37:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 9 Sep 2021 05:37:57 GMT
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1
In-Reply-To: <9bL2RnessX94pH3VPEC3uDrofP1pI5zZDVdMk3fKNLA=.9fc8cb35-1dcf-4a18-bce7-185d06318fca@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
 <SNyuR1X22y8s5fgY2SxbBC4YnTsbwRVGaDueDJUafGA=.b712f798-b360-4894-8efb-164f16010c9e@github.com>
 <gPtzMfGUoBCDlQnVy17AZgjRzcs32op73LIk64YQuhc=.bce7ff9c-cc45-453d-bac7-1c93e4c38033@github.com>
 <9bL2RnessX94pH3VPEC3uDrofP1pI5zZDVdMk3fKNLA=.9fc8cb35-1dcf-4a18-bce7-185d06318fca@github.com>
Message-ID: <0D8uAWG2YiPNYP7erm_toYu2GfeIZS284OF3Rzq5v08=.0e7030f0-21ad-4f48-8070-475ede8baacb@github.com>

On Thu, 9 Sep 2021 00:12:31 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> I did some more investigation and the answer is no, it's not a performance issue. The problem is that we never set the opacity to the platform window on IDEA tooltip appearance because of caching code in LWWindowPeer.setOpaque() that is called from LWWindowPeer.initializeImpl. So, I think that a direct setting in the place that I've suggested is necessary.

There is no caching in the LWWindowPeer.setOpaque() it just do not call the updateOpaque() if the opaque property did not change. What you are want to do is to call the `CWrapper.NSWindow.setBackgroundColor` from the LWWindowPeer.setBackground(). So the native color will be in sync with the peer's color. That method actually was added as part of JDK-8033786 and removed in JDK-8253977.

I think that the root cause is in the performance, because the first thing we draw is the surface data which is initialized/filled by the background color. Probably in OGL it works fine because we draw mostly immediately, and in case of metal we are waiting for DisplayLink callback?

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

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


From clanger at openjdk.java.net  Thu Sep  9 06:09:00 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Thu, 9 Sep 2021 06:09:00 GMT
Subject: RFR: JDK-8273387: remove some unreferenced gtk-related functions
 [v3]
In-Reply-To: <3sW8mv3EAFgTsTdUFAP-UvaKtUO6Afm3ytFb6sln_eI=.aa922086-cb72-4144-bf59-acc4941df9f3@github.com>
References: <EwiIDZeQXrzO6JMqVJfrH8ShJt25y6dkMhneE2Pd1ws=.509bad60-6874-407f-bc27-a7ed7e089b0a@github.com>
 <3sW8mv3EAFgTsTdUFAP-UvaKtUO6Afm3ytFb6sln_eI=.aa922086-cb72-4144-bf59-acc4941df9f3@github.com>
Message-ID: <eqeyQzllhBQR2zXSkQjiMcbAZD_35xMYO2bqlo-jIn8=.be39afdd-2ccc-4eec-8216-1700ebfe200d@github.com>

On Wed, 8 Sep 2021 11:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Please review this small change.
>> Looks like there are a few functions, like gtk2_paint_diamond, that are unreferenced and can be removed.
>> 
>> Thanks, Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove declaration

Marked as reviewed by clanger (Reviewer).

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

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


From mbaesken at openjdk.java.net  Thu Sep  9 06:19:08 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 9 Sep 2021 06:19:08 GMT
Subject: Integrated: JDK-8273387: remove some unreferenced gtk-related
 functions
In-Reply-To: <EwiIDZeQXrzO6JMqVJfrH8ShJt25y6dkMhneE2Pd1ws=.509bad60-6874-407f-bc27-a7ed7e089b0a@github.com>
References: <EwiIDZeQXrzO6JMqVJfrH8ShJt25y6dkMhneE2Pd1ws=.509bad60-6874-407f-bc27-a7ed7e089b0a@github.com>
Message-ID: <sNjpA9nGKwdFRKXsVC67z57-H7Qh5GTl9BFU49seaHY=.6b179691-eaca-4ecf-b0f3-7d9e43220657@github.com>

On Tue, 7 Sep 2021 07:29:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small change.
> Looks like there are a few functions, like gtk2_paint_diamond, that are unreferenced and can be removed.
> 
> Thanks, Matthias

This pull request has now been integrated.

Changeset: 6eba4434
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6eba443428ff7abe7c0509047ec76432affebe65
Stats:     68 lines in 2 files changed: 0 ins; 66 del; 2 mod

8273387: remove some unreferenced gtk-related functions

Reviewed-by: pbansal, clanger

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

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


From github.com+741251+turbanoff at openjdk.java.net  Thu Sep  9 07:01:10 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 9 Sep 2021 07:01:10 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when converting
 stream to String
Message-ID: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>

Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

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

Commit messages:
 - [PATCH] Use ByteArrayOutputStream.toString to convert its content to the String

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

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


From serb at openjdk.java.net  Thu Sep  9 07:01:11 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 9 Sep 2021 07:01:11 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <EVPBMmA5TPBVRdkPLE9j0pU1uWB6dQCeNq_2SjCAffE=.5e59244b-f0c5-4b12-998d-f4ae7999713d@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

Looks fine

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

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


From psadhukhan at openjdk.java.net  Thu Sep  9 07:28:25 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 9 Sep 2021 07:28:25 GMT
Subject: RFR: 8273366: [testbug]
 javax/swing/UIDefaults/6302464/bug6302464.java fails on macOS12
Message-ID: <2EyNRUQjV3JMN_iuN7-Ls09BmrKhSHxZ-7OTHkOTBrY=.2f7ea803-8ead-4fdb-b27a-bbcbf1900ef2@github.com>

Test fails on macOS12 since the check was only upto macOS11..Extended the check for BigSurOrAbove.

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

Commit messages:
 - Check BigSurOrAbove

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

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


From psadhukhan at openjdk.java.net  Thu Sep  9 07:41:33 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 9 Sep 2021 07:41:33 GMT
Subject: RFR: 8268084: [macos] Disabled JMenuItem arrow is not disabled
 [v6]
In-Reply-To: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>
References: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>
Message-ID: <cazwxxl6yOHc_MF3DMR2a1asRMo9hbBc_vtUkcYwB3U=.4d5805ab-0051-4128-a04b-8f363525a87d@github.com>

> It is seen in macos disabled JMenuItem arrow is not disabled even though JMenuItem itself is disabled.
> In native app, same menuitem arrow is disabled for disabled menuitem.
> 
> Issue is when AquaMenuPainter#paintMenuItem() is called, it tries to draw a ImageIcon image of the arrow via ImageIcon#paintIcon which tries to generate MultiResolutionCachedImage via getResolutionVariant() by calling AquaUtils#generateFilteredImage.
> It does not take into account if disabled arrow icon image needs to be drawn or not, so it is always enabled.
> 
> Proposed fix is to generate a disabled ImageIcon image of the same arrow icon and use it for disabled state.

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

  Address review comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5310/files
  - new: https://git.openjdk.java.net/jdk/pull/5310/files/3c2f69fa..4f555095

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

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

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


From psadhukhan at openjdk.java.net  Thu Sep  9 07:41:41 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 9 Sep 2021 07:41:41 GMT
Subject: RFR: 8268084: [macos] Disabled JMenuItem arrow is not disabled
 [v5]
In-Reply-To: <aCddUqnZVsQt14GqHM0nbISBwfQ1uR6SqFRr3THAffE=.799b11c7-9c56-4c70-af81-3a8e9360df11@github.com>
References: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>
 <i1xlwr387bfisRrBrNagDgNuFFIyIV2T4seRwDzOA3s=.239c555b-fbf4-4639-ad89-cfef3909f0c2@github.com>
 <aCddUqnZVsQt14GqHM0nbISBwfQ1uR6SqFRr3THAffE=.799b11c7-9c56-4c70-af81-3a8e9360df11@github.com>
Message-ID: <GTii77pRHJs3FfUPvy8CdEKM1v-JH8vxUjqWMdOtDjY=.60927779-f41c-4fc6-910e-56d0ba2eae2d@github.com>

On Wed, 8 Sep 2021 20:55:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add menuitem checkicon test
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java line 235:
> 
>> 233:     static class InvertableImageIcon extends ImageIcon implements InvertableIcon, UIResource {
>> 234:         Icon invertedImage;
>> 235:         Icon disabledIcon;
> 
> could be private

done

> src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java line 244:
> 
>> 242:             if (!c.isEnabled()) {
>> 243:                 if (disabledIcon == null) {
>> 244:                     disabledIcon = new ImageIconUIResource(GrayFilter.
> 
> It is not necessary to use ImageIconUIResource since we never return this image but only draw it.

done

> test/jdk/javax/swing/plaf/aqua/JMenuItemDisableArrowButtonTest.java line 27:
> 
>> 25:  * @requires (os.family == "mac")
>> 26:  * @bug 8268084
>> 27:  * @summary  Verifies disabled JMenuItem arrow is disabled
> 
> arrow and check

done

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

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


From psadhukhan at openjdk.java.net  Thu Sep  9 07:44:08 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 9 Sep 2021 07:44:08 GMT
Subject: RFR: 8268084: [macos] Disabled JMenuItem arrow is not disabled
 [v5]
In-Reply-To: <aCddUqnZVsQt14GqHM0nbISBwfQ1uR6SqFRr3THAffE=.799b11c7-9c56-4c70-af81-3a8e9360df11@github.com>
References: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>
 <i1xlwr387bfisRrBrNagDgNuFFIyIV2T4seRwDzOA3s=.239c555b-fbf4-4639-ad89-cfef3909f0c2@github.com>
 <aCddUqnZVsQt14GqHM0nbISBwfQ1uR6SqFRr3THAffE=.799b11c7-9c56-4c70-af81-3a8e9360df11@github.com>
Message-ID: <7MNd_St4Kb02QqAk0592fMLT6xJiHWaQgLdOYtmhfpQ=.19cccd4a-0b29-460b-9ea8-bbfcd4b2fa65@github.com>

On Wed, 8 Sep 2021 21:00:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add menuitem checkicon test
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java line 254:
> 
>> 252: 
>> 253:         @Override
>> 254:         public Icon getInvertedIcon() {
> 
> When we draw result of this method? Is it possible that we use the getInvertedIcon for disabled menus as well?

It is called from AquaMenuPainter#405 and 378
if (c instanceof JMenu && (model.isArmed() || model.isSelected()) && arrowIcon instanceof InvertableIcon) {
            ((InvertableIcon)arrowIcon).getInvertedIcon().paintIcon(c, g, arrowIconRect.x, arrowIconRect.y);
        }
I could not find at what point arrowIcon or checkIcon would be instance of InvertableIcon...
I guess we can take one fix at a time since this normal icon disable issue itself is there from macox port origin 
and fix it later if any issue comes for InvertableIcon...

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

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


From avu at openjdk.java.net  Thu Sep  9 09:22:04 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Thu, 9 Sep 2021 09:22:04 GMT
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1
In-Reply-To: <mxWA-5d3U6qiYH8TAqxQiDEBnUGM6mibVtVUt6XTiBg=.8283df0c-66b3-4966-bcd6-f03656ad551c@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
 <L-cJxSbuMyElETwoUNfHN7dPQo9qiEzCk0he8nXtlpc=.1fa35792-493b-409d-ad71-9ab348d6d8b0@github.com>
 <mxWA-5d3U6qiYH8TAqxQiDEBnUGM6mibVtVUt6XTiBg=.8283df0c-66b3-4966-bcd6-f03656ad551c@github.com>
Message-ID: <8jbDxnVih6LRY_Nv4QPXKyu9am5xNObxRhjtg7_Iqn4=.e154ac9b-459d-4566-b0f0-99a901d803e3@github.com>

On Sun, 5 Sep 2021 11:49:18 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java line 295:
>> 
>>> 293:             // Set correct background for a window before making it visible
>>> 294:             platformWindow.setOpaque(!isTranslucent());
>>> 295:         }
>> 
>> This looks as if it will affect OpenGL as well as Metal.
>> Do you see the flckering with both pipelines ?
>> What testing have you done with both of them ?
>
> Yes, it affects both pipelines, but flickering was noticed only with Metal. I've tried IDEA on both pipelines and I've run desktop tests only with Metal. I'm going to run desktop ones with OGL too.

OGL desktop tests are OK.

> This looks as if it will affect OpenGL as well as Metal.
> Do you see the flckering with both pipelines ?
> What testing have you done with both of them ?

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

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


From serb at openjdk.java.net  Thu Sep  9 09:23:19 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 9 Sep 2021 09:23:19 GMT
Subject: RFR: 8273135:
 java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java crashes in
 liblcms.dylib with NULLSeek+0x7
Message-ID: <xSp6L73skKla4HU_yXoZExpBjJxz5x1l0PAvic41KtQ=.2cf91478-e1b1-42a9-aa60-8ebb3650efa6@github.com>

This bug was found by the test added by the https://github.com/openjdk/jdk/pull/5042. The crash is rarely reproduced, and in the default testrun, I was not able to crash it even once. But I have found that if the 1000 tests are executed in parallel a few crashes(less than 10) usually happen.

After the code inspection, I have found and report the problem to the [LCMS upstream](https://bugs.openjdk.java.net/browse/JDK-8273135?focusedCommentId=14445750&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14445750) 

In this PR, I would like to cherry-pick the fix from the upstream and apply it to the JDK. So we prevent the crash and will have an opportunity to find some other issues if any (two crashes were found by this test already).

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

Commit messages:
 - fix for JDK-8273135

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

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


From alexander.scherbatiy at bell-sw.com  Thu Sep  9 14:07:49 2021
From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy)
Date: Thu, 9 Sep 2021 17:07:49 +0300
Subject: Loading FontManager from sun.font.fontmanager property
Message-ID: <8268e3e1-c24f-5738-b08f-604bfb173769@bell-sw.com>

Hello,

There are two fixes which avoid using reflection during 
GraphicsEnvironment and Toolkit platform specific classes loading [1], [2]:
 ? 8130266 Change the mechanism by which JDK loads the platform-specific 
GraphicsEnvironment class
 ? 8212700 Change the mechanism by which JDK loads the platform-specific 
AWT Toolkit


The FontManagerFactory class still uses reflection to load platform 
specific FontManager class from "sun.font.fontmanager" property.

Should the "sun.font.fontmanager" property be removed in the same way as 
for GraphicsEnvironment and Toolkit properties and make FontManger 
loading from corresponding PlatformInfo classes?

[1] https://bugs.openjdk.java.net/browse/JDK-8130266
[2] https://bugs.openjdk.java.net/browse/JDK-8212700
[3] 
https://github.com/openjdk/jdk/blob/c81690d7166c32caff6ef3a55fe9b157049e2b56/src/java.desktop/share/classes/sun/font/FontManagerFactory.java#L79

Thanks,
Alexander.



From philip.race at oracle.com  Thu Sep  9 14:34:35 2021
From: philip.race at oracle.com (Philip Race)
Date: Thu, 9 Sep 2021 07:34:35 -0700
Subject: Loading FontManager from sun.font.fontmanager property
In-Reply-To: <8268e3e1-c24f-5738-b08f-604bfb173769@bell-sw.com>
References: <8268e3e1-c24f-5738-b08f-604bfb173769@bell-sw.com>
Message-ID: <5e8f3aef-9725-0a20-2e64-677797a9f2a0@oracle.com>

I think it can be, although the problem with the other cases was that 
they were set by the launcher
and always appeared in the enumeration of system properties.

This case is not documented and isn't set .. but is an effective waste 
of code since any kind of
external replacement isn't possible with the module system encapsulation 
and disallowance of
illegal access.

-phil.

On 9/9/21 7:07 AM, Alexander Scherbatiy wrote:
> Hello,
>
> There are two fixes which avoid using reflection during 
> GraphicsEnvironment and Toolkit platform specific classes loading [1], 
> [2]:
> ? 8130266 Change the mechanism by which JDK loads the 
> platform-specific GraphicsEnvironment class
> ? 8212700 Change the mechanism by which JDK loads the 
> platform-specific AWT Toolkit
>
>
> The FontManagerFactory class still uses reflection to load platform 
> specific FontManager class from "sun.font.fontmanager" property.
>
> Should the "sun.font.fontmanager" property be removed in the same way 
> as for GraphicsEnvironment and Toolkit properties and make FontManger 
> loading from corresponding PlatformInfo classes?
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8130266
> [2] https://bugs.openjdk.java.net/browse/JDK-8212700
> [3] 
> https://github.com/openjdk/jdk/blob/c81690d7166c32caff6ef3a55fe9b157049e2b56/src/java.desktop/share/classes/sun/font/FontManagerFactory.java#L79
>
> Thanks,
> Alexander.
>



From xuelei at openjdk.java.net  Thu Sep  9 16:04:07 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 9 Sep 2021 16:04:07 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <CVdGTu5leV7vfIkVNtHt5sfufvso7V0qwkFqTt3xjBE=.86a34926-0d70-49fd-b59f-5d10fd928520@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

Nice catch.  The update looks safe and good to me.  Thanks!

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

Marked as reviewed by xuelei (Reviewer).

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


From bpb at openjdk.java.net  Thu Sep  9 16:04:07 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 9 Sep 2021 16:04:07 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <fuyCMvosSYi2H5xDUBPUmRM_bKN2YUVv6UdPrmameV8=.398b89e2-79f1-4b93-a653-80cbb8245e2f@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

Marked as reviewed by bpb (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Thu Sep  9 16:54:06 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 9 Sep 2021 16:54:06 GMT
Subject: RFR: 8273358: macOS Monterey does not have the font Times needed
 by Serif
In-Reply-To: <aAHjceTUeA1BFRU7WVvTO-UrfDLtFUn7c5W-pnycVfs=.47947ed1-82ba-4dc0-9820-2b7280426bf8@github.com>
References: <aAHjceTUeA1BFRU7WVvTO-UrfDLtFUn7c5W-pnycVfs=.47947ed1-82ba-4dc0-9820-2b7280426bf8@github.com>
Message-ID: <HzjrJTgUruL4jFoCHZORiRxn1clG6OMSJJd7K55gf_E=.a0d7d1d3-7470-446c-ad35-1b01d4cad5e5@github.com>

On Wed, 8 Sep 2021 16:49:26 GMT, Phil Race <prr at openjdk.org> wrote:

> Times has been the hard coded name for Serif in the JDK sources for macOS since the port was contributed by Apple.
> But it seems that macOS Monterey doesn't have this font.
> And the hard-coded fallback is also Times ! So we end up returning Dialog which is very bad.
> 
> The safest fix here is to make Times New Roman the fall back, so that on older macOS versions there
> is absolutely no change. Only on Monterey and presumably later, will it use Times New Roman which,
> I suspect, is what Times actually ends up being anyway.
> 
> Also to prevent unconditional warnings being printed I needed to change those to be conditional on logging being set.

src/java.desktop/macosx/classes/sun/font/CFontManager.java line 228:

> 226: 
> 227:             setupLogicalFonts("Dialog", defaultFont, defaultFallback);
> 228:             setupLogicalFonts("Serif", "Times", "Times New Roman");

Can we do it under macos >= Monterey check so that we are sure it's not affecting older releases just as we do for JTabbedPane legibility issue using JRSUIUtils.isMacOSBigSurOrAbove() check?
I see we have both Times and Times New Roman in "Font Book"...BTW, did you try "Restore Standard fonts" option in Font Book to see if "Times" font somehow comes back?

test/jdk/java/awt/FontClass/LogicalFontsTest.java line 28:

> 26:  * @bug 8273358
> 27:  * @summary Verify logical fonts are as expected.
> 28:  * @run main/othervm LogicalFontsTest

Is othervm option needed as we are not setting new paramter in command line?

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

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


From psadhukhan at openjdk.java.net  Thu Sep  9 17:00:02 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 9 Sep 2021 17:00:02 GMT
Subject: RFR: 8273358: macOS Monterey does not have the font Times needed
 by Serif
In-Reply-To: <HzjrJTgUruL4jFoCHZORiRxn1clG6OMSJJd7K55gf_E=.a0d7d1d3-7470-446c-ad35-1b01d4cad5e5@github.com>
References: <aAHjceTUeA1BFRU7WVvTO-UrfDLtFUn7c5W-pnycVfs=.47947ed1-82ba-4dc0-9820-2b7280426bf8@github.com>
 <HzjrJTgUruL4jFoCHZORiRxn1clG6OMSJJd7K55gf_E=.a0d7d1d3-7470-446c-ad35-1b01d4cad5e5@github.com>
Message-ID: <0YEpt-hUUnDFIyeU3ALC9icEIFko1Th6Dy2dL_vesb8=.3f0e7425-ef07-48d5-9c6e-f73fd8efaba6@github.com>

On Thu, 9 Sep 2021 16:50:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Times has been the hard coded name for Serif in the JDK sources for macOS since the port was contributed by Apple.
>> But it seems that macOS Monterey doesn't have this font.
>> And the hard-coded fallback is also Times ! So we end up returning Dialog which is very bad.
>> 
>> The safest fix here is to make Times New Roman the fall back, so that on older macOS versions there
>> is absolutely no change. Only on Monterey and presumably later, will it use Times New Roman which,
>> I suspect, is what Times actually ends up being anyway.
>> 
>> Also to prevent unconditional warnings being printed I needed to change those to be conditional on logging being set.
>
> src/java.desktop/macosx/classes/sun/font/CFontManager.java line 228:
> 
>> 226: 
>> 227:             setupLogicalFonts("Dialog", defaultFont, defaultFallback);
>> 228:             setupLogicalFonts("Serif", "Times", "Times New Roman");
> 
> Can we do it under macos >= Monterey check so that we are sure it's not affecting older releases just as we do for JTabbedPane legibility issue using JRSUIUtils.isMacOSBigSurOrAbove() check?
> I see we have both Times and Times New Roman in "Font Book"...BTW, did you try "Restore Standard fonts" option in Font Book to see if "Times" font somehow comes back?

Just to clarify, I see those 2 fonts in BigSur and Catalina..

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

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


From serb at openjdk.java.net  Thu Sep  9 18:13:00 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 9 Sep 2021 18:13:00 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <kRp_z1I71Yk9DqojqvpOotsYTLpq6d5XH11VajMPqb8=.c6b222a3-36a1-4ea5-a43d-9b74b33c05a4@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

Marked as reviewed by serb (Reviewer).

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

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


From prr at openjdk.java.net  Thu Sep  9 19:06:10 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 9 Sep 2021 19:06:10 GMT
Subject: RFR: 8273358: macOS Monterey does not have the font Times needed
 by Serif
In-Reply-To: <0YEpt-hUUnDFIyeU3ALC9icEIFko1Th6Dy2dL_vesb8=.3f0e7425-ef07-48d5-9c6e-f73fd8efaba6@github.com>
References: <aAHjceTUeA1BFRU7WVvTO-UrfDLtFUn7c5W-pnycVfs=.47947ed1-82ba-4dc0-9820-2b7280426bf8@github.com>
 <HzjrJTgUruL4jFoCHZORiRxn1clG6OMSJJd7K55gf_E=.a0d7d1d3-7470-446c-ad35-1b01d4cad5e5@github.com>
 <0YEpt-hUUnDFIyeU3ALC9icEIFko1Th6Dy2dL_vesb8=.3f0e7425-ef07-48d5-9c6e-f73fd8efaba6@github.com>
Message-ID: <gLeGVGezNaDwguUFfQ5h4MyV1b_9OC3Ljfe8VmgblhE=.7c80d93d-e8c9-4d64-bc56-bce59d3307b4@github.com>

On Thu, 9 Sep 2021 16:56:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/font/CFontManager.java line 228:
>> 
>>> 226: 
>>> 227:             setupLogicalFonts("Dialog", defaultFont, defaultFallback);
>>> 228:             setupLogicalFonts("Serif", "Times", "Times New Roman");
>> 
>> Can we do it under macos >= Monterey check so that we are sure it's not affecting older releases just as we do for JTabbedPane legibility issue using JRSUIUtils.isMacOSBigSurOrAbove() check?
>> I see we have both Times and Times New Roman in "Font Book"...BTW, did you try "Restore Standard fonts" option in Font Book to see if "Times" font somehow comes back?
>
> Just to clarify, I see those 2 fonts in BigSur and Catalina..

i see no reason to do that. 
it was dumb to make Times the fall back for Times on any release.

The restore option doesn't do that - it removes non-standard fonts.

And even if there were the answer we can't expect users to seek it out in order that Java work properly.

This is how the clean macOS 12 installs come.

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

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


From prr at openjdk.java.net  Thu Sep  9 19:06:11 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 9 Sep 2021 19:06:11 GMT
Subject: RFR: 8273358: macOS Monterey does not have the font Times needed
 by Serif
In-Reply-To: <HzjrJTgUruL4jFoCHZORiRxn1clG6OMSJJd7K55gf_E=.a0d7d1d3-7470-446c-ad35-1b01d4cad5e5@github.com>
References: <aAHjceTUeA1BFRU7WVvTO-UrfDLtFUn7c5W-pnycVfs=.47947ed1-82ba-4dc0-9820-2b7280426bf8@github.com>
 <HzjrJTgUruL4jFoCHZORiRxn1clG6OMSJJd7K55gf_E=.a0d7d1d3-7470-446c-ad35-1b01d4cad5e5@github.com>
Message-ID: <Az8mMM2huSHSmQiVo4BZ6kjs1r2ajD64QWGMRoTFPyg=.1924b31a-7583-491c-9cc6-fc05df6a9e54@github.com>

On Thu, 9 Sep 2021 16:50:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Times has been the hard coded name for Serif in the JDK sources for macOS since the port was contributed by Apple.
>> But it seems that macOS Monterey doesn't have this font.
>> And the hard-coded fallback is also Times ! So we end up returning Dialog which is very bad.
>> 
>> The safest fix here is to make Times New Roman the fall back, so that on older macOS versions there
>> is absolutely no change. Only on Monterey and presumably later, will it use Times New Roman which,
>> I suspect, is what Times actually ends up being anyway.
>> 
>> Also to prevent unconditional warnings being printed I needed to change those to be conditional on logging being set.
>
> test/jdk/java/awt/FontClass/LogicalFontsTest.java line 28:
> 
>> 26:  * @bug 8273358
>> 27:  * @summary Verify logical fonts are as expected.
>> 28:  * @run main/othervm LogicalFontsTest
> 
> Is othervm option needed as we are not setting new paramter in command line?

Not strictly since we configure the top level test directory to use othervm but
I did it consciously since it is best that such tests run in a brand new VM

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

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


From github.com+10835776+stsypanov at openjdk.java.net  Thu Sep  9 19:25:01 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 9 Sep 2021 19:25:01 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <KFGjrHoKqNLo9a0ncy2o8c35uCZqxSROXF0Sv1gN6dw=.77bb2735-f8f9-430c-98c8-95ef143230fe@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

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

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

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


From aivanov at openjdk.java.net  Thu Sep  9 19:52:05 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Sep 2021 19:52:05 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2
In-Reply-To: <5wxrXjnQvpCWFWsE92_LbQph-4FWGo8Hx-gLr2YhKTk=.cf1d8b1b-58d1-4bc5-8203-a4790923ec9f@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <PjT-YC4WSKOqoH_LZ7yA_Nvz9kOBPoilBJYsqD-XY_k=.ff3c4dd9-2f55-4dd6-9426-609c65dfbb8d@github.com>
 <PIwTD66jO2PuF41ohV0Nh7sQp7vNisT-S_RNZSmqlJE=.0d9d4926-1643-4766-ba78-bdf8d8e873eb@github.com>
 <5wxrXjnQvpCWFWsE92_LbQph-4FWGo8Hx-gLr2YhKTk=.cf1d8b1b-58d1-4bc5-8203-a4790923ec9f@github.com>
Message-ID: <Lr7lYUzb7M7wYUPk-AzVmsQoBH6mxxCpwG8EvfZKtLA=.89418fca-2b17-483e-8b0c-0ed6cd86f21c@github.com>

On Thu, 9 Sep 2021 03:46:00 GMT, Phil Race <prr at openjdk.org> wrote:

> > > The files that have JUST a (c) date update should all be reverted. You haven't touched them so there is nothing to (c).
> > 
> > 
> > I just removed the java.applet.* import for all of them. Should I revert the date if there's no other content change?
> 
> Hmm .. I missed the delete.
> Well .. what were those imports for ? Nothing used them.

It looks each file has the same wildcard import statements.

> Now, although arguably a separate issue, we have precedent for cleaning up imports at such a time.
> There are LOTS of wild card imports.

Many of the imports are unused. For example, `TreeDemo.java` doesn't use any of these: javax.swing.event.*, javax.accessibility.*, java.util.*.

It makes sense to clean it up along with removing java.applet.* imports.

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

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


From aivanov at openjdk.java.net  Thu Sep  9 20:06:06 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Sep 2021 20:06:06 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2
In-Reply-To: <k_RySD8RuLWx_WRXv8lL8EzMOVn7AqR1BP8I7allV_E=.eb42d34f-10d8-435e-9545-146d1057ad43@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <k_RySD8RuLWx_WRXv8lL8EzMOVn7AqR1BP8I7allV_E=.eb42d34f-10d8-435e-9545-146d1057ad43@github.com>
Message-ID: <zgr5BgdGx0Ir_CviyLfF5jddBRvN4hat4KAByP-PJcQ=.7bae5bfb-2dff-4a4d-b330-e1495335476f@github.com>

On Wed, 8 Sep 2021 22:32:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Probably the README in the "jdk/src/demo/share/" should be updated as well?

SwingSet2/README should also be updated.

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

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


From aivanov at openjdk.java.net  Thu Sep  9 20:08:57 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Sep 2021 20:08:57 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <PVMPETQF6OJIx5OK4o3iXMgLBUNksBofdSDBO0P8OGw=.04eee4ba-db8a-41ab-962c-4eefe4af0315@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.java.net  Thu Sep  9 20:12:01 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Sep 2021 20:12:01 GMT
Subject: RFR: 8273366: [testbug]
 javax/swing/UIDefaults/6302464/bug6302464.java fails on macOS12
In-Reply-To: <2EyNRUQjV3JMN_iuN7-Ls09BmrKhSHxZ-7OTHkOTBrY=.2f7ea803-8ead-4fdb-b27a-bbcbf1900ef2@github.com>
References: <2EyNRUQjV3JMN_iuN7-Ls09BmrKhSHxZ-7OTHkOTBrY=.2f7ea803-8ead-4fdb-b27a-bbcbf1900ef2@github.com>
Message-ID: <7EutdJGU-H5373DFyhWptT7ZP9e8D9BxASNb3AdWgqc=.226e5b32-34ae-4c7e-bce4-7b4d587e8197@github.com>

On Thu, 9 Sep 2021 07:19:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails on macOS12 since the check was only upto macOS11..Extended the check for BigSurOrAbove.

Marked as reviewed by aivanov (Reviewer).

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

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


From kizune at openjdk.java.net  Thu Sep  9 20:12:00 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 9 Sep 2021 20:12:00 GMT
Subject: RFR: 8273478: [macos11] JTabbedPane selected and pressed tab is
 not legible
In-Reply-To: <e-ugeGbJPsC79Gzj1JnU8rVlYjIsQlP0_d-8FXyJYLA=.771ab22e-029b-44b1-b953-305933c3c8f1@github.com>
References: <e-ugeGbJPsC79Gzj1JnU8rVlYjIsQlP0_d-8FXyJYLA=.771ab22e-029b-44b1-b953-305933c3c8f1@github.com>
Message-ID: <jK_uRCbrl-YbVW1DpiP9lm07RMxQ1EyijOgYRcpGrx0=.daa44d15-d5e5-400a-a7b2-6268f2ee603a@github.com>

On Wed, 8 Sep 2021 09:00:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> On macOS 11 (bigsur), using the Swing Aqua Look and Feel,
> the text of the selected and "pressed" JTabbedPane tab title text is just a light gray outline of white text on a white background which is not readable. 
> Fix is to use selectedControlTextColor for TabbedPane.selectedTabTitlePressedColor same as what we use for TabbedPane.selectedTabTitleNormalColor. Result is black over white text same as what is seen for native app pressed tabbedpane.

Marked as reviewed by kizune (Reviewer).

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

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


From aivanov at openjdk.java.net  Thu Sep  9 20:18:07 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Sep 2021 20:18:07 GMT
Subject: RFR: 8273358: macOS Monterey does not have the font Times needed
 by Serif
In-Reply-To: <aAHjceTUeA1BFRU7WVvTO-UrfDLtFUn7c5W-pnycVfs=.47947ed1-82ba-4dc0-9820-2b7280426bf8@github.com>
References: <aAHjceTUeA1BFRU7WVvTO-UrfDLtFUn7c5W-pnycVfs=.47947ed1-82ba-4dc0-9820-2b7280426bf8@github.com>
Message-ID: <J8GAZHREZ_BsDqoxitVnXpMS9DupkrB1ElkjhxZF4ww=.b9026894-24b1-416f-96e7-03882a64013a@github.com>

On Wed, 8 Sep 2021 16:49:26 GMT, Phil Race <prr at openjdk.org> wrote:

> Times has been the hard coded name for Serif in the JDK sources for macOS since the port was contributed by Apple.
> But it seems that macOS Monterey doesn't have this font.
> And the hard-coded fallback is also Times ! So we end up returning Dialog which is very bad.
> 
> The safest fix here is to make Times New Roman the fall back, so that on older macOS versions there
> is absolutely no change. Only on Monterey and presumably later, will it use Times New Roman which,
> I suspect, is what Times actually ends up being anyway.
> 
> Also to prevent unconditional warnings being printed I needed to change those to be conditional on logging being set.

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.java.net  Thu Sep  9 20:20:09 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Sep 2021 20:20:09 GMT
Subject: RFR: 8273478: [macos11] JTabbedPane selected and pressed tab is
 not legible
In-Reply-To: <e-ugeGbJPsC79Gzj1JnU8rVlYjIsQlP0_d-8FXyJYLA=.771ab22e-029b-44b1-b953-305933c3c8f1@github.com>
References: <e-ugeGbJPsC79Gzj1JnU8rVlYjIsQlP0_d-8FXyJYLA=.771ab22e-029b-44b1-b953-305933c3c8f1@github.com>
Message-ID: <CHB56PHRu5pA6WO4mNUu1BJUkZQVaM1Jis8jEbHuUFE=.f68464cd-d4ea-4d76-8280-a15434ca02c9@github.com>

On Wed, 8 Sep 2021 09:00:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> On macOS 11 (bigsur), using the Swing Aqua Look and Feel,
> the text of the selected and "pressed" JTabbedPane tab title text is just a light gray outline of white text on a white background which is not readable. 
> Fix is to use selectedControlTextColor for TabbedPane.selectedTabTitlePressedColor same as what we use for TabbedPane.selectedTabTitleNormalColor. Result is black over white text same as what is seen for native app pressed tabbedpane.

Marked as reviewed by aivanov (Reviewer).

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

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


From github.com+741251+turbanoff at openjdk.java.net  Thu Sep  9 21:51:08 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 9 Sep 2021 21:51:08 GMT
Subject: Integrated: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <De3deQdQDx14DwD8XwMElCVVTbmTvApVJpRl_BnCnEw=.8d47ea85-6b3a-49cd-b2cf-18fabe195e7e@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

This pull request has now been integrated.

Changeset: 2e321dc7
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2e321dc782e0de9995b1772e4cee9c0304bc183d
Stats:     6 lines in 4 files changed: 0 ins; 1 del; 5 mod

8273528: Avoid ByteArrayOutputStream.toByteArray when converting stream to String

Reviewed-by: bpb, xuelei, serb, aivanov

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

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


From serb at openjdk.java.net  Thu Sep  9 22:41:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 9 Sep 2021 22:41:09 GMT
Subject: RFR: 8273528: Avoid ByteArrayOutputStream.toByteArray when
 converting stream to String
In-Reply-To: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
References: <D1TTOgc2W9SNu5h9nsxN3nO7UKLriEusnVMLzHVpl1k=.50a8520c-68b5-4773-b5db-099a63e03510@github.com>
Message-ID: <iaAVNXN05o0iZliPGyJUwEkF1_wPi4sUij5bQgB7FvU=.6a21f75b-32b1-4a56-8b8d-18d6103ac420@github.com>

On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Using `ByteArrayOutputStream.toString` to convert it's content to a String is cleaner than `new String(out.toByteArray())`. Also it's a bit faster because of one less array copy.

BTW If it is not urgent I suggest to wait 24 hours from the approval before the /integrate, people have different timezones and may not be able to add a comment if any in time.

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

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


From mchung at openjdk.java.net  Thu Sep  9 22:53:01 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 9 Sep 2021 22:53:01 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in
 the java.util.logging
In-Reply-To: <KzUYT6FrcOeX_6gV61pZeAL3jdG77C7cFBv1DcCljOU=.66607f81-96be-4299-b4fa-a231be0bf249@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
 <KzUYT6FrcOeX_6gV61pZeAL3jdG77C7cFBv1DcCljOU=.66607f81-96be-4299-b4fa-a231be0bf249@github.com>
Message-ID: <3YsvWiK0yxQFHzt8Y6zKU3ucGZbQ3FqFWJfs_PnITBY=.7442a7bf-6c49-4a58-a0eb-0f2015dc98f9@github.com>

On Fri, 3 Sep 2021 17:19:05 GMT, Phil Race <prr at openjdk.org> wrote:

> Hmm I was under the impression this was removing AppContext itself but it is just removing the backdoor needed by logging
> Perhaps this isn't the change that requires the CSR but it then leaves an inconsistent state where desktop supports AppContext still but other modules don't ...

What is the plan to remove AppContext completely from java.desktop?   It's okay to have a separate PR to remove the logging dependency on AppContext but I'd prefer to see AppContext be removed about the same time with this PR.

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

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


From javalists at cbfiddle.com  Thu Sep  9 22:57:25 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 9 Sep 2021 15:57:25 -0700
Subject: [+AWTFont nsFontForJavaFont:env:]
In-Reply-To: <153CFA27-41D7-41CF-B7A8-5DF7A58E615F@gmail.com>
References: <DFB8AB8E-9430-497A-B8EE-3BC1759A4B3D@cbfiddle.com>
 <153CFA27-41D7-41CF-B7A8-5DF7A58E615F@gmail.com>
Message-ID: <32C9F782-CD60-46B6-9990-9BC79C2AB6DD@cbfiddle.com>

As no one is claiming ownership, should it be removed?
Or is it expected to have some use in the future?



> On Sep 8, 2021, at 3:50 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Sep 8, 2021, at 11:23 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
>> 
>> Is this method obsolete?
>> 
>> I?m not finding any uses. (Actually, IDEA is not finding any uses. Perhaps the index is broken?)
>> 
>> Alan
>> 
> 
> BBEdit search of recent JDK GitHub clone only shows
> 
> ~/jdk/src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.h:41: + (NSFont *) nsFontForJavaFont:(jobject)javaFont env:(JNIEnv *)env;
> ~/jdk/src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.m:116: + (NSFont *) nsFontForJavaFont:(jobject)javaFont env:(JNIEnv *)env {
> 
> No references in src directory.



From serb at openjdk.java.net  Thu Sep  9 23:01:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 9 Sep 2021 23:01:10 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in
 the java.util.logging
In-Reply-To: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
Message-ID: <NLG8-_-la_YVBW-hDAXeNWzaR6m_wsEueoNQXzsrmv4=.f8dcd406-87ee-4e1a-9a27-56c34f8cfa7f@github.com>

On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11.
> 
> This is the request to delete the usage of AppContext in the LogManager and related tests.
> 
> Tested by tier1/tier2/tier3 and jdk_desktop tests.

I'll remove its used one by one from the external usage like in "java.base" here, then in Swing, then in 2D like fonts, then last in AWT.

That change should not break something other than the tests which intentionally create different appcontexts. And it's easy to review.

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

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


From serb at openjdk.java.net  Fri Sep 10 02:10:59 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 10 Sep 2021 02:10:59 GMT
Subject: RFR: 8273478: [macos11] JTabbedPane selected and pressed tab is
 not legible
In-Reply-To: <e-ugeGbJPsC79Gzj1JnU8rVlYjIsQlP0_d-8FXyJYLA=.771ab22e-029b-44b1-b953-305933c3c8f1@github.com>
References: <e-ugeGbJPsC79Gzj1JnU8rVlYjIsQlP0_d-8FXyJYLA=.771ab22e-029b-44b1-b953-305933c3c8f1@github.com>
Message-ID: <k72IqjmD9CJnArbVl4HQsdalbsI9XfAd5AuTMv4ddKU=.eb46336a-c251-4ec5-b65a-d5df068047f6@github.com>

On Wed, 8 Sep 2021 09:00:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> On macOS 11 (bigsur), using the Swing Aqua Look and Feel,
> the text of the selected and "pressed" JTabbedPane tab title text is just a light gray outline of white text on a white background which is not readable. 
> Fix is to use selectedControlTextColor for TabbedPane.selectedTabTitlePressedColor same as what we use for TabbedPane.selectedTabTitleNormalColor. Result is black over white text same as what is seen for native app pressed tabbedpane.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Fri Sep 10 04:12:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 10 Sep 2021 04:12:06 GMT
Subject: RFR: 8268084: [macos] Disabled JMenuItem arrow is not disabled
 [v5]
In-Reply-To: <7MNd_St4Kb02QqAk0592fMLT6xJiHWaQgLdOYtmhfpQ=.19cccd4a-0b29-460b-9ea8-bbfcd4b2fa65@github.com>
References: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>
 <i1xlwr387bfisRrBrNagDgNuFFIyIV2T4seRwDzOA3s=.239c555b-fbf4-4639-ad89-cfef3909f0c2@github.com>
 <aCddUqnZVsQt14GqHM0nbISBwfQ1uR6SqFRr3THAffE=.799b11c7-9c56-4c70-af81-3a8e9360df11@github.com>
 <7MNd_St4Kb02QqAk0592fMLT6xJiHWaQgLdOYtmhfpQ=.19cccd4a-0b29-460b-9ea8-bbfcd4b2fa65@github.com>
Message-ID: <76GzxbI_Dq_gbH9Oi-rz99IomaxS7RDo4PDiRU0XVJs=.6725140a-f81d-41b9-870a-186eb23bf8ea@github.com>

On Thu, 9 Sep 2021 07:41:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java line 254:
>> 
>>> 252: 
>>> 253:         @Override
>>> 254:         public Icon getInvertedIcon() {
>> 
>> When we draw result of this method? Is it possible that we use the getInvertedIcon for disabled menus as well?
>
> It is called from AquaMenuPainter#405 and 378
> if (c instanceof JMenu && (model.isArmed() || model.isSelected()) && arrowIcon instanceof InvertableIcon) {
>             ((InvertableIcon)arrowIcon).getInvertedIcon().paintIcon(c, g, arrowIconRect.x, arrowIconRect.y);
>         }
> I could not find at what point arrowIcon or checkIcon would be instance of InvertableIcon...
> I guess we can take one fix at a time since this normal icon disable issue itself is there from macox port origin 
> and fix it later if any issue comes for InvertableIcon...

> I could not find at what point arrowIcon or checkIcon would be an instance of InvertableIcon...

All InvertableImageIcon objects are InvertableIcon since it implements that interface, so that part is always true, and if it possible to make "(c instanceof JMenu && (model.isArmed() || model.isSelected()"== true for the disabled components then "getInvertedIcon" should return disabled icon.

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

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


From serb at openjdk.java.net  Fri Sep 10 04:34:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 10 Sep 2021 04:34:06 GMT
Subject: RFR: 8271923: [macos] the text color on the selected disabled
 tabbed pane button remains white making text unreadable [v2]
In-Reply-To: <7yhGJyiMRwZl8rMEbzZ_yya34m2Ds-LWqldj96YZzBM=.892bea30-f297-4ce6-be8c-51a1ff7a5e93@github.com>
References: <CfPWU8kqPqInYwtW5Ddzdj_C1yWCBrEIFDf9buMJixo=.d526022a-431d-4b53-93d2-e827a91bff44@github.com>
 <mOq3GsnoeK9UpYOKlnwR40aWO9TtWAv54nlMJyqMZrU=.1eb29f34-bce2-431b-ab5c-38a78d9a5022@github.com>
 <7yhGJyiMRwZl8rMEbzZ_yya34m2Ds-LWqldj96YZzBM=.892bea30-f297-4ce6-be8c-51a1ff7a5e93@github.com>
Message-ID: <0UytHyM0tvBEqqOIT-5a1Zh2h_ACct8RYWerJg8cpGk=.9c7019d4-073b-499a-ab83-db691efe20eb@github.com>

On Thu, 9 Sep 2021 05:10:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I raised https://git.openjdk.java.net/jdk/pull/5409 for the "pressed" issue on BigSur.

Thank you!

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

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


From pbansal at openjdk.java.net  Fri Sep 10 06:17:04 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 10 Sep 2021 06:17:04 GMT
Subject: Integrated: 8272148: JDesktopPane:getComponentCount() returns one
 extra than expected with GTKLookAndFeel
In-Reply-To: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
References: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
Message-ID: <_xldcfA3O_lKL98vZVdS7BwwlpMuqhM_Nhl7HPhx95M=.e9ce5320-255f-47e4-a0fa-0644b3b3a898@github.com>

On Mon, 16 Aug 2021 08:22:35 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> A container may include few default components as children, which are added to it during creation. Due to this, calling function getChildrenCount on a new created instance may return non zero value. This behaviour may vary according to L&F also, as some L&F may add some default components to a container, but other L&F may choose not to do so.
> 
> The current bugs reports that this behaviour looks suspicious as it is expected that a newly created container will have zero  children.
> 
> Current specification is not clear on this whether it is allowed for a container to contain default components or not. The fix make changes to the specification to clarify the same.
> 
> Note: I think this will need a CSR, I will file one after the review is completed

This pull request has now been integrated.

Changeset: 70c9e026
Author:    Pankaj Bansal <pbansal at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/70c9e026b63aadf9a2bfcbda45c2b9ea866afafa
Stats:     10 lines in 1 file changed: 10 ins; 0 del; 0 mod

8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel

Reviewed-by: prr, serb

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

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


From github.com+36081106+savoptik at openjdk.java.net  Fri Sep 10 15:19:08 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Fri, 10 Sep 2021 15:19:08 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell navigation
Message-ID: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>

We've extended the current implementation of TableAccessibility to make sure that individual cells are voiced when navigating with the keyboard.

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

Commit messages:
 - 8271071 accessibility of a table on macOS lacks cell navigation

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

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


From vdyakov at openjdk.java.net  Fri Sep 10 15:59:46 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Fri, 10 Sep 2021 15:59:46 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation
In-Reply-To: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
Message-ID: <VrFpa5utC-iHr_31WQ9XalsKWfNJeO3Wlh0gT8ektXE=.561a5482-c813-431c-8967-bbf94ba0b592@github.com>

On Fri, 10 Sep 2021 15:11:20 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> We've extended the current implementation of TableAccessibility to make sure that individual cells are voiced when navigating with the keyboard.

@pankaj-bansal @azuev-java please review

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

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


From prr at openjdk.java.net  Fri Sep 10 16:40:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 10 Sep 2021 16:40:01 GMT
Subject: Integrated: 8273358: macOS Monterey does not have the font Times
 needed by Serif
In-Reply-To: <aAHjceTUeA1BFRU7WVvTO-UrfDLtFUn7c5W-pnycVfs=.47947ed1-82ba-4dc0-9820-2b7280426bf8@github.com>
References: <aAHjceTUeA1BFRU7WVvTO-UrfDLtFUn7c5W-pnycVfs=.47947ed1-82ba-4dc0-9820-2b7280426bf8@github.com>
Message-ID: <7VsrqYxBNSFbZnNtZbA5HLjA9ThTIh20u28n-Z61wPI=.e56a5f47-4b22-4451-901d-24f8f5dd26ee@github.com>

On Wed, 8 Sep 2021 16:49:26 GMT, Phil Race <prr at openjdk.org> wrote:

> Times has been the hard coded name for Serif in the JDK sources for macOS since the port was contributed by Apple.
> But it seems that macOS Monterey doesn't have this font.
> And the hard-coded fallback is also Times ! So we end up returning Dialog which is very bad.
> 
> The safest fix here is to make Times New Roman the fall back, so that on older macOS versions there
> is absolutely no change. Only on Monterey and presumably later, will it use Times New Roman which,
> I suspect, is what Times actually ends up being anyway.
> 
> Also to prevent unconditional warnings being printed I needed to change those to be conditional on logging being set.

This pull request has now been integrated.

Changeset: efe3ed1e
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/efe3ed1e705a6f3785761e64f7187de809daa731
Stats:     65 lines in 2 files changed: 62 ins; 0 del; 3 mod

8273358: macOS Monterey does not have the font Times needed by Serif

Reviewed-by: kizune, aivanov

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

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


From avu at openjdk.java.net  Fri Sep 10 18:54:47 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 10 Sep 2021 18:54:47 GMT
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1
In-Reply-To: <0D8uAWG2YiPNYP7erm_toYu2GfeIZS284OF3Rzq5v08=.0e7030f0-21ad-4f48-8070-475ede8baacb@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
 <SNyuR1X22y8s5fgY2SxbBC4YnTsbwRVGaDueDJUafGA=.b712f798-b360-4894-8efb-164f16010c9e@github.com>
 <gPtzMfGUoBCDlQnVy17AZgjRzcs32op73LIk64YQuhc=.bce7ff9c-cc45-453d-bac7-1c93e4c38033@github.com>
 <9bL2RnessX94pH3VPEC3uDrofP1pI5zZDVdMk3fKNLA=.9fc8cb35-1dcf-4a18-bce7-185d06318fca@github.com>
 <0D8uAWG2YiPNYP7erm_toYu2GfeIZS284OF3Rzq5v08=.0e7030f0-21ad-4f48-8070-475ede8baacb@github.com>
Message-ID: <8tSmo2KjJAJ0rrII9X-tdMFlfKlee2dE1TEMQQyGRjg=.6515a3f2-7361-408f-af29-fc386491d776@github.com>

On Thu, 9 Sep 2021 05:35:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> There is no caching in the LWWindowPeer.setOpaque() it just do not call the updateOpaque() if the opaque property did not change.

Yes, I meant just that - cached state.

> I think that the root cause is in the performance, because the first thing we draw is the surface data which is initialized/filled by the background color. Probably in OGL it works fine because we draw mostly immediately, and in case of metal we are waiting for DisplayLink callback?

Yes, to blit the content we just start DisplayLink. So, definitely there is some lag between window appearance and the drawing of the layer.  

> What you are want to do is to call the `CWrapper.NSWindow.setBackgroundColor` from the LWWindowPeer.setBackground().

Yes, it was the purpose of use setOpaque() method. But, more verbose way with a separate method (setBackground) is better. I've prepared a new version with such a change.

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

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


From serb at openjdk.java.net  Fri Sep 10 19:06:58 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 10 Sep 2021 19:06:58 GMT
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1
In-Reply-To: <8tSmo2KjJAJ0rrII9X-tdMFlfKlee2dE1TEMQQyGRjg=.6515a3f2-7361-408f-af29-fc386491d776@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
 <SNyuR1X22y8s5fgY2SxbBC4YnTsbwRVGaDueDJUafGA=.b712f798-b360-4894-8efb-164f16010c9e@github.com>
 <gPtzMfGUoBCDlQnVy17AZgjRzcs32op73LIk64YQuhc=.bce7ff9c-cc45-453d-bac7-1c93e4c38033@github.com>
 <9bL2RnessX94pH3VPEC3uDrofP1pI5zZDVdMk3fKNLA=.9fc8cb35-1dcf-4a18-bce7-185d06318fca@github.com>
 <0D8uAWG2YiPNYP7erm_toYu2GfeIZS284OF3Rzq5v08=.0e7030f0-21ad-4f48-8070-475ede8baacb@github.com>
 <8tSmo2KjJAJ0rrII9X-tdMFlfKlee2dE1TEMQQyGRjg=.6515a3f2-7361-408f-af29-fc386491d776@github.com>
Message-ID: <WxFE4j8lqh3_thQpDMvkoeN3mjN71SG78f-dzTL9zq4=.c6e69721-8165-4f98-a6bb-554b846360e6@github.com>

On Fri, 10 Sep 2021 18:50:31 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Yes, to blit the content we just start DisplayLink. So, definitely there is some lag between window appearance and the drawing of the layer.

If that lag is visible by the human, and so different from the OGL, means that we should enhance our performance testing for Lanai. As far as I remember that tests report better performance than OGL, is it possible that for Metal the perf tests just skip the rendering phase and did not wait for a DisplayLink callback? 

Probably we can force metal to draw some initial surfaces w/o using DisplayLink?

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

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


From avu at openjdk.java.net  Fri Sep 10 19:25:50 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 10 Sep 2021 19:25:50 GMT
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1
In-Reply-To: <WxFE4j8lqh3_thQpDMvkoeN3mjN71SG78f-dzTL9zq4=.c6e69721-8165-4f98-a6bb-554b846360e6@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
 <SNyuR1X22y8s5fgY2SxbBC4YnTsbwRVGaDueDJUafGA=.b712f798-b360-4894-8efb-164f16010c9e@github.com>
 <gPtzMfGUoBCDlQnVy17AZgjRzcs32op73LIk64YQuhc=.bce7ff9c-cc45-453d-bac7-1c93e4c38033@github.com>
 <9bL2RnessX94pH3VPEC3uDrofP1pI5zZDVdMk3fKNLA=.9fc8cb35-1dcf-4a18-bce7-185d06318fca@github.com>
 <0D8uAWG2YiPNYP7erm_toYu2GfeIZS284OF3Rzq5v08=.0e7030f0-21ad-4f48-8070-475ede8baacb@github.com>
 <8tSmo2KjJAJ0rrII9X-tdMFlfKlee2dE1TEMQQyGRjg=.6515a3f2-7361-408f-af29-fc386491d776@github.com>
 <WxFE4j8lqh3_thQpDMvkoeN3mjN71SG78f-dzTL9zq4=.c6e69721-8165-4f98-a6bb-554b846360e6@github.com>
Message-ID: <arCYURxgge3090MLrRstAb6SsXmsYjA4qJotV-eiNTk=.feb77f41-c510-4494-a0c8-170dc1eed05c@github.com>

On Fri, 10 Sep 2021 19:03:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As far as I remember that tests report better performance than OGL, is it possible that for Metal the perf tests just skip the rendering phase and did not wait for a DisplayLink callback?

I'm not sure about Swingmark but RenderPerf tracks the real content rendering (there are color marks for each frame that are rendered after the bunch of primitives and the java robot detects the change of the color marks). So, we can trust the numbers in the RenderPerf. 

> Probably we can force metal to draw some initial surfaces w/o using DisplayLink?

It could work but complicates things a bit. I'll see what we can do here. Meanwhile, I'll provide the solution that we discussed earlier.

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

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


From avu at openjdk.java.net  Fri Sep 10 19:30:20 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 10 Sep 2021 19:30:20 GMT
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1 [v2]
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: <a7-dWuKWJQYCwCoFEYUqOz7ZKqQh2gY7UKGG0I9dVjo=.df6a4816-9cc6-40ca-bc20-8ebba8d31b03@github.com>

> Used setOpaque() method to set correct background of platform window

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

  8273355: Lanai: Flickering on tooltip appearance IntelliJ IDEA 2021.2.1
  
  Extracted setting background to the particular method in PlatformWindow. Provided appropriate implementation in CPlatformWindow.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5373/files
  - new: https://git.openjdk.java.net/jdk/pull/5373/files/752c2133..5027f885

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

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Fri Sep 10 20:53:06 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Fri, 10 Sep 2021 20:53:06 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v2]
In-Reply-To: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
Message-ID: <1wUP9OW4AbC9ZFUCRW8DI5Pq91oUCYi7ahZuh5brWFM=.d306c363-fe43-4839-baf3-b4ad811c6a84@github.com>

> removed support for running demo from applet for J2Ddemo and SwingSet2
> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)

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

  8205137: Updated imports
  
  Reviewed-by: alichung

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5401/files
  - new: https://git.openjdk.java.net/jdk/pull/5401/files/7dab70e2..25f7c533

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

  Stats: 402 lines in 17 files changed: 99 ins; 49 del; 254 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5401.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5401/head:pull/5401

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


From prr at openjdk.java.net  Fri Sep 10 21:42:50 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 10 Sep 2021 21:42:50 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v2]
In-Reply-To: <1wUP9OW4AbC9ZFUCRW8DI5Pq91oUCYi7ahZuh5brWFM=.d306c363-fe43-4839-baf3-b4ad811c6a84@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <1wUP9OW4AbC9ZFUCRW8DI5Pq91oUCYi7ahZuh5brWFM=.d306c363-fe43-4839-baf3-b4ad811c6a84@github.com>
Message-ID: <I_h-DFoaXStr9QRqy3c4drY1ew16muYSUhL89nt4qmo=.c9e5fa71-484a-40ac-8f2d-6ca67f70f7c5@github.com>

On Fri, 10 Sep 2021 20:53:06 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> removed support for running demo from applet for J2Ddemo and SwingSet2
>> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8205137: Updated imports
>   
>   Reviewed-by: alichung

Marked as reviewed by prr (Reviewer).

src/demo/share/jfc/SwingSet2/HtmlDemo.java line 45:

> 43: import java.awt.*;
> 44: import java.awt.event.*;
> 45: import java.beans.*;

So this is good clean up to have .. wildcard imports of so many packages that aren't even used !

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

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


From aivanov at openjdk.java.net  Fri Sep 10 22:04:48 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Sep 2021 22:04:48 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v2]
In-Reply-To: <1wUP9OW4AbC9ZFUCRW8DI5Pq91oUCYi7ahZuh5brWFM=.d306c363-fe43-4839-baf3-b4ad811c6a84@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <1wUP9OW4AbC9ZFUCRW8DI5Pq91oUCYi7ahZuh5brWFM=.d306c363-fe43-4839-baf3-b4ad811c6a84@github.com>
Message-ID: <li7SpjgkcEebrMKVZfRc_YjlKQtZeRmhG6WxzlIvMEs=.869c502c-c714-42bd-9f96-91093099a057@github.com>

On Fri, 10 Sep 2021 20:53:06 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> removed support for running demo from applet for J2Ddemo and SwingSet2
>> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8205137: Updated imports
>   
>   Reviewed-by: alichung

In all the files except for `ButtonDemo.java`, you modify the imports only; in case of `ButtonDemo.java`, you also reformat the code. Is it intentional?

The imports in the files were in this order: `javax.*` followed by `java.*`. This order is preserved. However, in the JDK source files, imports from `java.*` usually come before `javax.*`.

What is the preferred order of imports?

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Fri Sep 10 22:04:48 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Fri, 10 Sep 2021 22:04:48 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v2]
In-Reply-To: <li7SpjgkcEebrMKVZfRc_YjlKQtZeRmhG6WxzlIvMEs=.869c502c-c714-42bd-9f96-91093099a057@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <1wUP9OW4AbC9ZFUCRW8DI5Pq91oUCYi7ahZuh5brWFM=.d306c363-fe43-4839-baf3-b4ad811c6a84@github.com>
 <li7SpjgkcEebrMKVZfRc_YjlKQtZeRmhG6WxzlIvMEs=.869c502c-c714-42bd-9f96-91093099a057@github.com>
Message-ID: <kM4IBt0pQb2QvJQ5MqPXeLjSmdE5VxzEVKTafqjCXqM=.45ade63a-6825-415a-9682-4bcdaac5fcd2@github.com>

On Fri, 10 Sep 2021 21:58:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> In all the files except for `ButtonDemo.java`, you modify the imports only; in case of `ButtonDemo.java`, you also reformat the code. Is it intentional?

Oh the reformat was unintentional, let me revert that...

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Fri Sep 10 23:34:19 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Fri, 10 Sep 2021 23:34:19 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v3]
In-Reply-To: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
Message-ID: <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>

> removed support for running demo from applet for J2Ddemo and SwingSet2
> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)

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

  8205137: Reverted accidental code reformat
  
  Reviewed-by: alichung

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5401/files
  - new: https://git.openjdk.java.net/jdk/pull/5401/files/25f7c533..fe3bde46

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

  Stats: 106 lines in 1 file changed: 16 ins; 16 del; 74 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5401.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5401/head:pull/5401

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


From kizune at openjdk.java.net  Fri Sep 10 23:39:47 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 10 Sep 2021 23:39:47 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v3]
In-Reply-To: <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
Message-ID: <Nkg_5u9YLW0elbzxzzkQHib6f9A72cL87aGXoB9x35s=.07417b81-64ba-495a-9036-c907fe1f0829@github.com>

On Fri, 10 Sep 2021 23:34:19 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> removed support for running demo from applet for J2Ddemo and SwingSet2
>> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8205137: Reverted accidental code reformat
>   
>   Reviewed-by: alichung

Marked as reviewed by kizune (Reviewer).

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

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


From prr at openjdk.java.net  Fri Sep 10 23:39:48 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 10 Sep 2021 23:39:48 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v3]
In-Reply-To: <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
Message-ID: <VS5Wig2lbGxwGsVUcVF0E3bthcbE0A9RR9G6eRZCki8=.8f2bf8f2-9d60-4682-a4dd-87c8590965b5@github.com>

On Fri, 10 Sep 2021 23:34:19 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> removed support for running demo from applet for J2Ddemo and SwingSet2
>> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8205137: Reverted accidental code reformat
>   
>   Reviewed-by: alichung

Marked as reviewed by prr (Reviewer).

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

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


From serb at openjdk.java.net  Sat Sep 11 00:42:50 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 11 Sep 2021 00:42:50 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v2]
In-Reply-To: <li7SpjgkcEebrMKVZfRc_YjlKQtZeRmhG6WxzlIvMEs=.869c502c-c714-42bd-9f96-91093099a057@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <1wUP9OW4AbC9ZFUCRW8DI5Pq91oUCYi7ahZuh5brWFM=.d306c363-fe43-4839-baf3-b4ad811c6a84@github.com>
 <li7SpjgkcEebrMKVZfRc_YjlKQtZeRmhG6WxzlIvMEs=.869c502c-c714-42bd-9f96-91093099a057@github.com>
Message-ID: <3vJigM3I7GQbaFuAq7ZoLHzqcvmtO401Y-EPlfO_iQc=.24b3172b-85cc-4e5c-90aa-915c244a7092@github.com>

On Fri, 10 Sep 2021 21:58:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> What is the preferred order of imports?

Usually it is
java.*
empty line
javax.*
empty line
others.*
empty line 
static java.*
empty line
static javax.*
empty line
others.*

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

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


From serb at openjdk.java.net  Sat Sep 11 00:44:49 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 11 Sep 2021 00:44:49 GMT
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1
In-Reply-To: <arCYURxgge3090MLrRstAb6SsXmsYjA4qJotV-eiNTk=.feb77f41-c510-4494-a0c8-170dc1eed05c@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
 <SNyuR1X22y8s5fgY2SxbBC4YnTsbwRVGaDueDJUafGA=.b712f798-b360-4894-8efb-164f16010c9e@github.com>
 <gPtzMfGUoBCDlQnVy17AZgjRzcs32op73LIk64YQuhc=.bce7ff9c-cc45-453d-bac7-1c93e4c38033@github.com>
 <9bL2RnessX94pH3VPEC3uDrofP1pI5zZDVdMk3fKNLA=.9fc8cb35-1dcf-4a18-bce7-185d06318fca@github.com>
 <0D8uAWG2YiPNYP7erm_toYu2GfeIZS284OF3Rzq5v08=.0e7030f0-21ad-4f48-8070-475ede8baacb@github.com>
 <8tSmo2KjJAJ0rrII9X-tdMFlfKlee2dE1TEMQQyGRjg=.6515a3f2-7361-408f-af29-fc386491d776@github.com>
 <WxFE4j8lqh3_thQpDMvkoeN3mjN71SG78f-dzTL9zq4=.c6e69721-8165-4f98-a6bb-554b846360e6@github.com>
 <arCYURxgge3090MLrRstAb6SsXmsYjA4qJotV-eiNTk=.feb77f41-c510-4494-a0c8-170dc1eed05c@github.com>
Message-ID: <T6i4B724OBydh9ZZIrA8XCVGjbyo6g3ML42Cj8goLnk=.7e430412-5158-4110-a4ae-9d6969c7c7f7@github.com>

On Fri, 10 Sep 2021 19:23:11 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> I'm not sure about Swingmark but RenderPerf tracks the real content rendering (there are color marks for each frame that are rendered after the bunch of primitives and the java robot detects the change of the color marks). So, we can trust the numbers in the RenderPerf.

Then why it does not catch this one? If it works fast then probably we just draw some wrong texture in the beginning or draw some garbage?

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

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


From serb at openjdk.java.net  Sat Sep 11 00:49:49 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 11 Sep 2021 00:49:49 GMT
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1 [v2]
In-Reply-To: <8jbDxnVih6LRY_Nv4QPXKyu9am5xNObxRhjtg7_Iqn4=.e154ac9b-459d-4566-b0f0-99a901d803e3@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
 <L-cJxSbuMyElETwoUNfHN7dPQo9qiEzCk0he8nXtlpc=.1fa35792-493b-409d-ad71-9ab348d6d8b0@github.com>
 <mxWA-5d3U6qiYH8TAqxQiDEBnUGM6mibVtVUt6XTiBg=.8283df0c-66b3-4966-bcd6-f03656ad551c@github.com>
 <8jbDxnVih6LRY_Nv4QPXKyu9am5xNObxRhjtg7_Iqn4=.e154ac9b-459d-4566-b0f0-99a901d803e3@github.com>
Message-ID: <Ef3AnqCqVhpSPH1_c7IT5_iE9fuyQwdeYNkW0dKuc9o=.5fd357ed-125f-45d3-a32c-b7581a35fbc6@github.com>

On Thu, 9 Sep 2021 09:18:59 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Yes, it affects both pipelines, but flickering was noticed only with Metal. I've tried IDEA on both pipelines and I've run desktop tests only with Metal. I'm going to run desktop ones with OGL too.
>
> OGL desktop tests are OK.
> 
>> This looks as if it will affect OpenGL as well as Metal.
>> Do you see the flckering with both pipelines ?
>> What testing have you done with both of them ?

If the user will create a peer then change the background color, then show the window the flickering will occur. you need to override the LWWIndowPeer.setBackground and call the platformWindow.setBackground from there. The LWWIndowPeer.setBackground is also called during peer initialization so the code above will not be needed. 

But it will be good to root cause the problem if it is not related to the performance.

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

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


From aivanov at openjdk.java.net  Sat Sep 11 10:51:46 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 11 Sep 2021 10:51:46 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v3]
In-Reply-To: <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
Message-ID: <-tRS0fQVI8EnmvkkjX9wPvbD0rA7Cc5AObgUw7o5kWI=.b2292a7a-5b71-4ce7-8198-c1e26bb8efaa@github.com>

On Fri, 10 Sep 2021 23:34:19 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> removed support for running demo from applet for J2Ddemo and SwingSet2
>> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8205137: Reverted accidental code reformat
>   
>   Reviewed-by: alichung

Marked as reviewed by aivanov (Reviewer).

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

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


From serb at openjdk.java.net  Sun Sep 12 01:44:00 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 12 Sep 2021 01:44:00 GMT
Subject: RFR: 8273366: [testbug]
 javax/swing/UIDefaults/6302464/bug6302464.java fails on macOS12
In-Reply-To: <2EyNRUQjV3JMN_iuN7-Ls09BmrKhSHxZ-7OTHkOTBrY=.2f7ea803-8ead-4fdb-b27a-bbcbf1900ef2@github.com>
References: <2EyNRUQjV3JMN_iuN7-Ls09BmrKhSHxZ-7OTHkOTBrY=.2f7ea803-8ead-4fdb-b27a-bbcbf1900ef2@github.com>
Message-ID: <fm60L-ylkfqMKv-oYfmeozbauUxgjF6o04fwpYreKyA=.61a18e63-196a-4ba7-81d4-97e9ad333c99@github.com>

On Thu, 9 Sep 2021 07:19:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails on macOS12 since the check was only upto macOS11..Extended the check for BigSurOrAbove.

Since the test initially started to fail after JDK-8220150
probably it will be good to use the same logic in the test and in the jdk, see
https://hg.openjdk.java.net/jdk/jdk/rev/a57d3822c2fa#l2.16
?

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

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


From prr at openjdk.java.net  Sun Sep 12 04:42:00 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 12 Sep 2021 04:42:00 GMT
Subject: RFR: 8273102: Delete deprecated for removal the empty finalize()
 in java.desktop module
In-Reply-To: <OAhmO3Akwb17uxlk-Kn3_8ZJNy1Tkqds13JLAevCfs0=.df8f6c03-48da-4d05-8575-d304c7d97b6d@github.com>
References: <OAhmO3Akwb17uxlk-Kn3_8ZJNy1Tkqds13JLAevCfs0=.df8f6c03-48da-4d05-8575-d304c7d97b6d@github.com>
Message-ID: <NdjQfloHkOvY8oNZPKCquTK0fISmmvpUSRxtk-XuUVw=.3e9d534e-7fb2-4aa7-84c3-ef48d2d5f5e8@github.com>

On Sun, 29 Aug 2021 01:09:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "java.desktop" module has a few implementations of the finalize() which do nothing, deprecated since jdk9, and are marked "forRemoval = true" since jdk16. 
> 
> This is a request to delete such empty methods. 
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8273103

Marked as reviewed by prr (Reviewer).

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

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


From avu at openjdk.java.net  Sun Sep 12 21:15:47 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Sun, 12 Sep 2021 21:15:47 GMT
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1
In-Reply-To: <T6i4B724OBydh9ZZIrA8XCVGjbyo6g3ML42Cj8goLnk=.7e430412-5158-4110-a4ae-9d6969c7c7f7@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
 <SNyuR1X22y8s5fgY2SxbBC4YnTsbwRVGaDueDJUafGA=.b712f798-b360-4894-8efb-164f16010c9e@github.com>
 <gPtzMfGUoBCDlQnVy17AZgjRzcs32op73LIk64YQuhc=.bce7ff9c-cc45-453d-bac7-1c93e4c38033@github.com>
 <9bL2RnessX94pH3VPEC3uDrofP1pI5zZDVdMk3fKNLA=.9fc8cb35-1dcf-4a18-bce7-185d06318fca@github.com>
 <0D8uAWG2YiPNYP7erm_toYu2GfeIZS284OF3Rzq5v08=.0e7030f0-21ad-4f48-8070-475ede8baacb@github.com>
 <8tSmo2KjJAJ0rrII9X-tdMFlfKlee2dE1TEMQQyGRjg=.6515a3f2-7361-408f-af29-fc386491d776@github.com>
 <WxFE4j8lqh3_thQpDMvkoeN3mjN71SG78f-dzTL9zq4=.c6e69721-8165-4f98-a6bb-554b846360e6@github.com>
 <arCYURxgge3090MLrRstAb6SsXmsYjA4qJotV-eiNTk=.feb77f41-c510-4494-a0c8-170dc1eed05c@github.com>
 <T6i4B724OBydh9ZZIrA8XCVGjbyo6g3ML42Cj8goLnk=.7e430412-5158-4110-a4ae-9d6969c7c7f7@github.com>
Message-ID: <OImJBqq6yKEsvALPqIAxdDuO080g9ICfBf4gGkx3M-Q=.850f58b9-f064-4bc7-890e-8e224c42dad9@github.com>

On Sat, 11 Sep 2021 00:41:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I'm not sure about Swingmark but RenderPerf tracks the real content rendering (there are color marks for each frame that are rendered after the bunch of primitives and the java robot detects the change of the color marks). So, we can trust the numbers in the RenderPerf.
> 
> Then why it does not catch this one? If it works fast then probably we just draw some wrong texture in the beginning or draw some garbage?

The scenario from RenderPerf differs from this issue. In RenderPerf we create a window and then perform rendering of multiple primitives.  Whereas in this bug we create a new window each time and see the flickering.

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

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


From serb at openjdk.java.net  Sun Sep 12 21:53:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 12 Sep 2021 21:53:48 GMT
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1
In-Reply-To: <OImJBqq6yKEsvALPqIAxdDuO080g9ICfBf4gGkx3M-Q=.850f58b9-f064-4bc7-890e-8e224c42dad9@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
 <SNyuR1X22y8s5fgY2SxbBC4YnTsbwRVGaDueDJUafGA=.b712f798-b360-4894-8efb-164f16010c9e@github.com>
 <gPtzMfGUoBCDlQnVy17AZgjRzcs32op73LIk64YQuhc=.bce7ff9c-cc45-453d-bac7-1c93e4c38033@github.com>
 <9bL2RnessX94pH3VPEC3uDrofP1pI5zZDVdMk3fKNLA=.9fc8cb35-1dcf-4a18-bce7-185d06318fca@github.com>
 <0D8uAWG2YiPNYP7erm_toYu2GfeIZS284OF3Rzq5v08=.0e7030f0-21ad-4f48-8070-475ede8baacb@github.com>
 <8tSmo2KjJAJ0rrII9X-tdMFlfKlee2dE1TEMQQyGRjg=.6515a3f2-7361-408f-af29-fc386491d776@github.com>
 <WxFE4j8lqh3_thQpDMvkoeN3mjN71SG78f-dzTL9zq4=.c6e69721-8165-4f98-a6bb-554b846360e6@github.com>
 <arCYURxgge3090MLrRstAb6SsXmsYjA4qJotV-eiNTk=.feb77f41-c510-4494-a0c8-170dc1eed05c@github.com>
 <T6i4B724OBydh9ZZIrA8XCVGjbyo6g3ML42Cj8goLnk=.7e430412-5158-4110-a4ae-9d6969c7c7f7@github.com>
 <OImJBqq6yKEsvALPqIAxdDuO080g9ICfBf4gGkx3M-Q=.850f58b9-f064-4bc7-890e-8e224c42dad9@github.com>
Message-ID: <PDssR6-CgWSp3VqD09jGtWolf1TCWpLh9wX3VIS3tCE=.a3a36813-51ef-48ef-be41-55a765f70457@github.com>

On Sun, 12 Sep 2021 21:13:10 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> The scenario from RenderPerf differs from this issue. In RenderPerf we create a window and then perform rendering of multiple primitives. Whereas in this bug we create a new window each time and see the flickering.

But the code path is the same, we create a window and try to clear/fill it by the background as fast as possible. And the flickering occurs because the time between g.fillRect()->actual image on the screen is too big.

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

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


From javalists at cbfiddle.com  Sun Sep 12 22:53:01 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sun, 12 Sep 2021 15:53:01 -0700
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1
In-Reply-To: <PDssR6-CgWSp3VqD09jGtWolf1TCWpLh9wX3VIS3tCE=.a3a36813-51ef-48ef-be41-55a765f70457@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
 <SNyuR1X22y8s5fgY2SxbBC4YnTsbwRVGaDueDJUafGA=.b712f798-b360-4894-8efb-164f16010c9e@github.com>
 <gPtzMfGUoBCDlQnVy17AZgjRzcs32op73LIk64YQuhc=.bce7ff9c-cc45-453d-bac7-1c93e4c38033@github.com>
 <9bL2RnessX94pH3VPEC3uDrofP1pI5zZDVdMk3fKNLA=.9fc8cb35-1dcf-4a18-bce7-185d06318fca@github.com>
 <0D8uAWG2YiPNYP7erm_toYu2GfeIZS284OF3Rzq5v08=.0e7030f0-21ad-4f48-8070-475ede8baacb@github.com>
 <8tSmo2KjJAJ0rrII9X-tdMFlfKlee2dE1TEMQQyGRjg=.6515a3f2-7361-408f-af29-fc386491d776@github.com>
 <WxFE4j8lqh3_thQpDMvkoeN3mjN71SG78f-dzTL9zq4=.c6e69721-8165-4f98-a6bb-554b846360e6@github.com>
 <arCYURxgge3090MLrRstAb6SsXmsYjA4qJotV-eiNTk=.feb77f41-c510-4494-a0c8-170dc1eed05c@github.com>
 <T6i4B724OBydh9ZZIrA8XCVGjbyo6g3ML42Cj8goLnk=.7e430412-5158-4110-a4ae-9d6969c7c7f7@github.com>
 <OImJBqq6yKEsvALPqIAxdDuO080g9ICfBf4gGkx3M-Q=.850f58b9-f064-4bc7-890e-8e224c42dad9@github.com>
 <PDssR6-CgWSp3VqD09jGtWolf1TCWpLh9wX3VIS3tCE=.a3a36813-51ef-48ef-be41-55a765f70457@github.com>
Message-ID: <F6A8D7A7-B247-4372-A7DD-F3CA5489F178@cbfiddle.com>

I see this sort of thing way too often in Java programs, but I don?t see it in native programs. Why is that?

Is it not possible to create a window, fill its layer with pixels, and then make it visible?



> On Sep 12, 2021, at 2:53 PM, Sergey Bylokhov <serb at openjdk.java.net> wrote:
> 
> On Sun, 12 Sep 2021 21:13:10 GMT, Alexey Ushakov <avu at openjdk.org> wrote:
> 
>> The scenario from RenderPerf differs from this issue. In RenderPerf we create a window and then perform rendering of multiple primitives. Whereas in this bug we create a new window each time and see the flickering.
> 
> But the code path is the same, we create a window and try to clear/fill it by the background as fast as possible. And the flickering occurs because the time between g.fillRect()->actual image on the screen is too big.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/5373
> 



From serb at openjdk.java.net  Mon Sep 13 02:59:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 13 Sep 2021 02:59:07 GMT
Subject: RFR: 8273638: javax/swing/JTable/4235420/bug4235420.java fails in GTK
 L&F
Message-ID: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>

As discussed here https://github.com/openjdk/jdk/pull/1813 the test should skip the GTK L&F unfortunately the name of the GTK L&F is "GTK look and feel" not "GTK". The ID="GTK" can be used instead.

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

Commit messages:
 - Update bug4235420.java

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

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


From psadhukhan at openjdk.java.net  Mon Sep 13 04:44:50 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 13 Sep 2021 04:44:50 GMT
Subject: RFR: 8273366: [testbug]
 javax/swing/UIDefaults/6302464/bug6302464.java fails on macOS12
In-Reply-To: <2EyNRUQjV3JMN_iuN7-Ls09BmrKhSHxZ-7OTHkOTBrY=.2f7ea803-8ead-4fdb-b27a-bbcbf1900ef2@github.com>
References: <2EyNRUQjV3JMN_iuN7-Ls09BmrKhSHxZ-7OTHkOTBrY=.2f7ea803-8ead-4fdb-b27a-bbcbf1900ef2@github.com>
Message-ID: <vw1rH-uKhW5cj32min7E4z8jER1JLs3O911lkld3EkY=.51b5f7c7-1e45-446f-a26c-c9423b7ae02d@github.com>

On Thu, 9 Sep 2021 07:19:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails on macOS12 since the check was only upto macOS11..Extended the check for BigSurOrAbove.

I guess the test failure is initially reported in JDK-8199079 which was way before JDK-8220150 and it has passed ever since that fix. We are just extending the fix to macos12 and beyond.

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

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


From psadhukhan at openjdk.java.net  Mon Sep 13 04:47:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 13 Sep 2021 04:47:56 GMT
Subject: Integrated: 8273478: [macos11] JTabbedPane selected and pressed tab
 is not legible
In-Reply-To: <e-ugeGbJPsC79Gzj1JnU8rVlYjIsQlP0_d-8FXyJYLA=.771ab22e-029b-44b1-b953-305933c3c8f1@github.com>
References: <e-ugeGbJPsC79Gzj1JnU8rVlYjIsQlP0_d-8FXyJYLA=.771ab22e-029b-44b1-b953-305933c3c8f1@github.com>
Message-ID: <eRlXeqGeItJizkwsfHWOD-7_Gdamd72EC0q57fVzap8=.2d4f3812-8ddb-46d6-8330-d0984ed96481@github.com>

On Wed, 8 Sep 2021 09:00:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> On macOS 11 (bigsur), using the Swing Aqua Look and Feel,
> the text of the selected and "pressed" JTabbedPane tab title text is just a light gray outline of white text on a white background which is not readable. 
> Fix is to use selectedControlTextColor for TabbedPane.selectedTabTitlePressedColor same as what we use for TabbedPane.selectedTabTitleNormalColor. Result is black over white text same as what is seen for native app pressed tabbedpane.

This pull request has now been integrated.

Changeset: 4efcd200
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4efcd2006f00a6347987ecdacd6e09d59a0006f4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8273478: [macos11] JTabbedPane selected and pressed tab is not legible

Reviewed-by: kizune, aivanov, serb

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

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


From psadhukhan at openjdk.java.net  Mon Sep 13 05:32:52 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 13 Sep 2021 05:32:52 GMT
Subject: RFR: 8273638: javax/swing/JTable/4235420/bug4235420.java fails in
 GTK L&F
In-Reply-To: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
References: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
Message-ID: <7SCrJAupJa4LafLZRaH_O7w4yWh-mVFy-XKJC1KIq40=.608c1a44-8918-48e1-95d1-2c652497aea3@github.com>

On Mon, 13 Sep 2021 02:49:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As discussed here https://github.com/openjdk/jdk/pull/1813 the test should skip the GTK L&F unfortunately the name of the GTK L&F is "GTK look and feel" not "GTK". The ID="GTK" can be used instead.

The test result shows in linux-x64

----------System.out:(6/323)----------
Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
Testing L&F: javax.swing.plaf.nimbus.NimbusLookAndFeel
The test is skipped for Nimbus and GTK
Testing L&F: com.sun.java.swing.plaf.motif.MotifLookAndFeel
Unsupported L&F: com.sun.java.swing.plaf.gtk.GTKLookAndFeel
Testing L&F: com.sun.java.swing.plaf.gtk.GTKLookAndFeel
----------System.err:(1/15)----------
STATUS:Passed.

Do you know why it is shown as Unsupported for GTK even in linux?

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

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


From avu at openjdk.java.net  Mon Sep 13 06:05:53 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 13 Sep 2021 06:05:53 GMT
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1
In-Reply-To: <PDssR6-CgWSp3VqD09jGtWolf1TCWpLh9wX3VIS3tCE=.a3a36813-51ef-48ef-be41-55a765f70457@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
 <SNyuR1X22y8s5fgY2SxbBC4YnTsbwRVGaDueDJUafGA=.b712f798-b360-4894-8efb-164f16010c9e@github.com>
 <gPtzMfGUoBCDlQnVy17AZgjRzcs32op73LIk64YQuhc=.bce7ff9c-cc45-453d-bac7-1c93e4c38033@github.com>
 <9bL2RnessX94pH3VPEC3uDrofP1pI5zZDVdMk3fKNLA=.9fc8cb35-1dcf-4a18-bce7-185d06318fca@github.com>
 <0D8uAWG2YiPNYP7erm_toYu2GfeIZS284OF3Rzq5v08=.0e7030f0-21ad-4f48-8070-475ede8baacb@github.com>
 <8tSmo2KjJAJ0rrII9X-tdMFlfKlee2dE1TEMQQyGRjg=.6515a3f2-7361-408f-af29-fc386491d776@github.com>
 <WxFE4j8lqh3_thQpDMvkoeN3mjN71SG78f-dzTL9zq4=.c6e69721-8165-4f98-a6bb-554b846360e6@github.com>
 <arCYURxgge3090MLrRstAb6SsXmsYjA4qJotV-eiNTk=.feb77f41-c510-4494-a0c8-170dc1eed05c@github.com>
 <T6i4B724OBydh9ZZIrA8XCVGjbyo6g3ML42Cj8goLnk=.7e430412-5158-4110-a4ae-9d6969c7c7f7@github.com>
 <OImJBqq6yKEsvALPqIAxdDuO080g9ICfBf4gGkx3M-Q=.850f58b9-f064-4bc7-890e-8e224c42dad9@github.com>
 <PDssR6-CgWSp3VqD09jGtWolf1TCWpLh9wX
 3VIS3tCE=.a3a36813-51ef-48ef-be41-55a765f70457@github.com>
Message-ID: <Bcok1DRh4QVunmsxiNyn8oc5WqteT3a0JMXOGU2uRUU=.326ec58e-ddcb-4392-bee1-d3c683668a9f@github.com>

On Sun, 12 Sep 2021 21:50:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > The scenario from RenderPerf differs from this issue. In RenderPerf we create a window and then perform rendering of multiple primitives. Whereas in this bug we create a new window each time and see the flickering.
> 
> But the code path is the same, we create a window and try to clear/fill it by the background as fast as possible. And the flickering occurs because the time between g.fillRect()->actual image on the screen is too big.

I suppose that the problem is not because the lag is too big - in a normal state (when the window is created) we don't need to flush the layer content faster than DisplayLink provides. The problem happens in the transition state during creating the window. So, long term solution would be an immediate rendering to the window surface for the first time (as you previously suggested). In the short term, we can just provide the correct background.

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

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


From pbansal at openjdk.java.net  Mon Sep 13 06:49:49 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 13 Sep 2021 06:49:49 GMT
Subject: RFR: 8273638: javax/swing/JTable/4235420/bug4235420.java fails in
 GTK L&F
In-Reply-To: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
References: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
Message-ID: <4u73lfVU-o70dyNz41n_WVStrEa0hyGsE4FWkSjlmNg=.e54cbe0e-da71-47b3-aafe-c52fe35c8102@github.com>

On Mon, 13 Sep 2021 02:49:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As discussed here https://github.com/openjdk/jdk/pull/1813 the test should skip the GTK L&F unfortunately the name of the GTK L&F is "GTK look and feel" not "GTK". The ID="GTK" can be used instead.

Look good to me

I just ran this on my Ubuntu 20.04 and I do not see the UnsupportedL&F exception for GTKL&F. The output is as expected.

*************
Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
Testing L&F: javax.swing.plaf.nimbus.NimbusLookAndFeel
The test is skipped for Nimbus and GTK
Testing L&F: com.sun.java.swing.plaf.motif.MotifLookAndFeel
Testing L&F: com.sun.java.swing.plaf.gtk.GTKLookAndFeel
The test is skipped for Nimbus and GTK
***************

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

Marked as reviewed by pbansal (Reviewer).

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


From psadhukhan at openjdk.java.net  Mon Sep 13 06:57:59 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 13 Sep 2021 06:57:59 GMT
Subject: RFR: 8273638: javax/swing/JTable/4235420/bug4235420.java fails in
 GTK L&F
In-Reply-To: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
References: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
Message-ID: <nUQsTHuzu2ZmPf5_DCYLdqXu5jH52gge_YJd6bk127A=.ee8e94f1-1c4b-4ce2-87e9-6a4d9d07caae@github.com>

On Mon, 13 Sep 2021 02:49:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As discussed here https://github.com/openjdk/jdk/pull/1813 the test should skip the GTK L&F unfortunately the name of the GTK L&F is "GTK look and feel" not "GTK". The ID="GTK" can be used instead.

FWIW, the system where it shows the above message is Oracle_Linux_7.9 CI system and it's running headless which this test is 
whereas local ubuntu systems are headful.

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

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


From serb at openjdk.java.net  Mon Sep 13 07:08:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 13 Sep 2021 07:08:57 GMT
Subject: RFR: 8273638: javax/swing/JTable/4235420/bug4235420.java fails in
 GTK L&F
In-Reply-To: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
References: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
Message-ID: <sDgbUcfER3Jz8S95vET3nNGrPsk79eQuwwAzsa-9yXA=.455d5c1c-8796-4215-bd0b-4c42f4a5a382@github.com>

On Mon, 13 Sep 2021 02:49:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As discussed here https://github.com/openjdk/jdk/pull/1813 the test should skip the GTK L&F unfortunately the name of the GTK L&F is "GTK look and feel" not "GTK". The ID="GTK" can be used instead.

The GTK L&F is unsupported in the headless mode since it depends on the native libraries. So when this test is executed on the headless system it is passed because the GTK L&F is unsupported and that part of the code is skipped. It fails on the headful systems where the GTK is supported and the test tries to verify it. This bug was not reproduced in mach5 because the test is not marked as "@key headful" so it is never run on the headful systems.

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

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


From serb at openjdk.java.net  Mon Sep 13 07:13:50 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 13 Sep 2021 07:13:50 GMT
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1
In-Reply-To: <Bcok1DRh4QVunmsxiNyn8oc5WqteT3a0JMXOGU2uRUU=.326ec58e-ddcb-4392-bee1-d3c683668a9f@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
 <SNyuR1X22y8s5fgY2SxbBC4YnTsbwRVGaDueDJUafGA=.b712f798-b360-4894-8efb-164f16010c9e@github.com>
 <gPtzMfGUoBCDlQnVy17AZgjRzcs32op73LIk64YQuhc=.bce7ff9c-cc45-453d-bac7-1c93e4c38033@github.com>
 <9bL2RnessX94pH3VPEC3uDrofP1pI5zZDVdMk3fKNLA=.9fc8cb35-1dcf-4a18-bce7-185d06318fca@github.com>
 <0D8uAWG2YiPNYP7erm_toYu2GfeIZS284OF3Rzq5v08=.0e7030f0-21ad-4f48-8070-475ede8baacb@github.com>
 <8tSmo2KjJAJ0rrII9X-tdMFlfKlee2dE1TEMQQyGRjg=.6515a3f2-7361-408f-af29-fc386491d776@github.com>
 <WxFE4j8lqh3_thQpDMvkoeN3mjN71SG78f-dzTL9zq4=.c6e69721-8165-4f98-a6bb-554b846360e6@github.com>
 <arCYURxgge3090MLrRstAb6SsXmsYjA4qJotV-eiNTk=.feb77f41-c510-4494-a0c8-170dc1eed05c@github.com>
 <T6i4B724OBydh9ZZIrA8XCVGjbyo6g3ML42Cj8goLnk=.7e430412-5158-4110-a4ae-9d6969c7c7f7@github.com>
 <OImJBqq6yKEsvALPqIAxdDuO080g9ICfBf4gGkx3M-Q=.850f58b9-f064-4bc7-890e-8e224c42dad9@github.com>
 <PDssR6-CgWSp3VqD09jGtWolf1TCWpLh9wX
 3VIS3tCE=.a3a36813-51ef-48ef-be41-55a765f70457@github.com>
 <Bcok1DRh4QVunmsxiNyn8oc5WqteT3a0JMXOGU2uRUU=.326ec58e-ddcb-4392-bee1-d3c683668a9f@github.com>
Message-ID: <bk4AVqWHM9W36QHctxfeZcjz276NqmBPaVnXoax0og8=.238c086a-caab-460a-83b9-40aa03d7fc65@github.com>

On Mon, 13 Sep 2021 06:03:11 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> in a normal state (when the window is created) we don't need to flush the layer content faster than DisplayLink provide.

But this is exactly related to the performance, no? When the RenderPerf test is executed it should check that delay between fillRect and the actual rendering is as small as possible. Can you please just confirm that the problem is in the "performance" of DisplayLink and unrelated to some broken rendering? I guess you can create two timestamps in NSWindow creation and in Layer callback(where we actually blit the content/ drawInXXXContext). How that timing is different for metal and OGL?

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

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


From psadhukhan at openjdk.java.net  Mon Sep 13 07:30:52 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 13 Sep 2021 07:30:52 GMT
Subject: RFR: 8273638: javax/swing/JTable/4235420/bug4235420.java fails in
 GTK L&F
In-Reply-To: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
References: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
Message-ID: <cckFYFeooBLz0AZPxGCloXeXsvpWn9T_BvXGWj8T3m8=.2b71a4c7-eb46-4213-b5c9-41162ea13a31@github.com>

On Mon, 13 Sep 2021 02:49:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As discussed here https://github.com/openjdk/jdk/pull/1813 the test should skip the GTK L&F unfortunately the name of the GTK L&F is "GTK look and feel" not "GTK". The ID="GTK" can be used instead.

ok

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

Marked as reviewed by psadhukhan (Reviewer).

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


From psadhukhan at openjdk.java.net  Mon Sep 13 08:41:28 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 13 Sep 2021 08:41:28 GMT
Subject: RFR: 8268084: [macos] Disabled JMenuItem arrow is not disabled
 [v7]
In-Reply-To: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>
References: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>
Message-ID: <O0VdzC73jbrtVB5nIIcyTg3TAbaaMtbKjI6Qg8f_c4o=.6b177929-4f11-473d-abb7-2a4283956c93@github.com>

> It is seen in macos disabled JMenuItem arrow is not disabled even though JMenuItem itself is disabled.
> In native app, same menuitem arrow is disabled for disabled menuitem.
> 
> Issue is when AquaMenuPainter#paintMenuItem() is called, it tries to draw a ImageIcon image of the arrow via ImageIcon#paintIcon which tries to generate MultiResolutionCachedImage via getResolutionVariant() by calling AquaUtils#generateFilteredImage.
> It does not take into account if disabled arrow icon image needs to be drawn or not, so it is always enabled.
> 
> Proposed fix is to generate a disabled ImageIcon image of the same arrow icon and use it for disabled state.

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

  Disable invertedIcon icon too

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5310/files
  - new: https://git.openjdk.java.net/jdk/pull/5310/files/4f555095..caa4d794

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

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

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


From psadhukhan at openjdk.java.net  Mon Sep 13 08:53:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 13 Sep 2021 08:53:56 GMT
Subject: RFR: 8268084: [macos] Disabled JMenuItem arrow is not disabled
 [v5]
In-Reply-To: <76GzxbI_Dq_gbH9Oi-rz99IomaxS7RDo4PDiRU0XVJs=.6725140a-f81d-41b9-870a-186eb23bf8ea@github.com>
References: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>
 <i1xlwr387bfisRrBrNagDgNuFFIyIV2T4seRwDzOA3s=.239c555b-fbf4-4639-ad89-cfef3909f0c2@github.com>
 <aCddUqnZVsQt14GqHM0nbISBwfQ1uR6SqFRr3THAffE=.799b11c7-9c56-4c70-af81-3a8e9360df11@github.com>
 <7MNd_St4Kb02QqAk0592fMLT6xJiHWaQgLdOYtmhfpQ=.19cccd4a-0b29-460b-9ea8-bbfcd4b2fa65@github.com>
 <76GzxbI_Dq_gbH9Oi-rz99IomaxS7RDo4PDiRU0XVJs=.6725140a-f81d-41b9-870a-186eb23bf8ea@github.com>
Message-ID: <ocrfJq3YXuNfNsh-DDWttVoIfUsBwIcrMqKOrULyErs=.51752dfa-d8c4-4251-ad2a-8d22a96ea5bc@github.com>

On Fri, 10 Sep 2021 04:08:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> It is called from AquaMenuPainter#405 and 378
>> if (c instanceof JMenu && (model.isArmed() || model.isSelected()) && arrowIcon instanceof InvertableIcon) {
>>             ((InvertableIcon)arrowIcon).getInvertedIcon().paintIcon(c, g, arrowIconRect.x, arrowIconRect.y);
>>         }
>> I could not find at what point arrowIcon or checkIcon would be instance of InvertableIcon...
>> I guess we can take one fix at a time since this normal icon disable issue itself is there from macox port origin 
>> and fix it later if any issue comes for InvertableIcon...
>
>> I could not find at what point arrowIcon or checkIcon would be an instance of InvertableIcon...
> 
> All InvertableImageIcon objects are InvertableIcon since it implements that interface, so that part is always true, and if it possible to make "(c instanceof JMenu && (model.isArmed() || model.isSelected()"== true for the disabled components then "getInvertedIcon" should return disabled icon.

Arrow icon InvertedIcon is handled by testing with setSelected(true) and setEnabled(false)
but
for checkIcon, it checks for

if (item.isArmed() && checkIcon instanceof InvertableIcon) {
            ((InvertableIcon)checkIcon).getInvertedIcon().paintIcon(item, g, checkIconRect.x, checkIconRect.y);
        } 


but even if we do setArmed(true) it is set to false here
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/JMenuItem.java#L312

if (!b && !UIManager.getBoolean("MenuItem.disabledAreNavigable")) {
            setArmed(false);
        }

and MenuItem.disabledAreNavigable is not defined for Aqua so I guess it's false so InvertedIcon is not called for checkIcon

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

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


From azvegint at openjdk.java.net  Mon Sep 13 11:04:53 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 13 Sep 2021 11:04:53 GMT
Subject: RFR: 8273638: javax/swing/JTable/4235420/bug4235420.java fails in
 GTK L&F
In-Reply-To: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
References: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
Message-ID: <gxDNX3jywsYzo75R8nfFkLpWUFQT7t60MfgIYNa6iI8=.5664f895-5551-4a29-9aea-2795d12200b3@github.com>

On Mon, 13 Sep 2021 02:49:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As discussed here https://github.com/openjdk/jdk/pull/1813 the test should skip the GTK L&F unfortunately the name of the GTK L&F is "GTK look and feel" not "GTK". The ID="GTK" can be used instead.

Marked as reviewed by azvegint (Reviewer).

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

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


From mik3hall at gmail.com  Mon Sep 13 11:39:34 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 13 Sep 2021 06:39:34 -0500
Subject: [+AWTFont nsFontForJavaFont:env:]
In-Reply-To: <32C9F782-CD60-46B6-9990-9BC79C2AB6DD@cbfiddle.com>
References: <DFB8AB8E-9430-497A-B8EE-3BC1759A4B3D@cbfiddle.com>
 <153CFA27-41D7-41CF-B7A8-5DF7A58E615F@gmail.com>
 <32C9F782-CD60-46B6-9990-9BC79C2AB6DD@cbfiddle.com>
Message-ID: <5C886C51-609C-41F6-8BFC-021550F35F06@gmail.com>



> On Sep 9, 2021, at 5:57 PM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> As no one is claiming ownership, should it be removed?
> Or is it expected to have some use in the future?
> 
> 
> 
>> On Sep 8, 2021, at 3:50 PM, Michael Hall <mik3hall at gmail.com> wrote:
>> 
>> 
>> 
>>> On Sep 8, 2021, at 11:23 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
>>> 
>>> Is this method obsolete?
>>> 
>>> I?m not finding any uses. (Actually, IDEA is not finding any uses. Perhaps the index is broken?)
>>> 
>>> Alan
>>> 
>> 
>> BBEdit search of recent JDK GitHub clone only shows
>> 
>> ~/jdk/src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.h:41: + (NSFont *) nsFontForJavaFont:(jobject)javaFont env:(JNIEnv *)env;
>> ~/jdk/src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.m:116: + (NSFont *) nsFontForJavaFont:(jobject)javaFont env:(JNIEnv *)env {
>> 
>> No references in src directory.
> 

Another OS/X method that seems to currently (java.vm.version=18-ea+11-557)  be missing?

Lcom/apple/eawt/event/GestureHandler;.handleGestureFromNative(Ljava/awt/Window;IDDDD)V
java.lang.NoSuchMethodError: Lcom/apple/eawt/event/GestureHandler;.handleGestureFromNative(Ljava/awt/Window;IDDDD)V
java.lang.NoSuchMethodError: Lcom/apple/eawt/event/GestureHandler;.handleGestureFromNative(Ljava/awt/Window;IDDDD)V
java.lang.NoSuchMethodError: Lcom/apple/eawt/event/GestureHandler;.handleGestureFromNative(Ljava/awt/Window;IDDDD)V
java.lang.NoSuchMethodError: Lcom/apple/eawt/event/GestureHandler;.handleGestureFromNative(Ljava/awt/Window;IDDDD)V
java.lang.NoSuchMethodError:

Many times on message.
Two finger track pad gesture.




From aivanov at openjdk.java.net  Mon Sep 13 14:35:14 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 13 Sep 2021 14:35:14 GMT
Subject: RFR: 8273135:
 java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java crashes in
 liblcms.dylib with NULLSeek+0x7
In-Reply-To: <xSp6L73skKla4HU_yXoZExpBjJxz5x1l0PAvic41KtQ=.2cf91478-e1b1-42a9-aa60-8ebb3650efa6@github.com>
References: <xSp6L73skKla4HU_yXoZExpBjJxz5x1l0PAvic41KtQ=.2cf91478-e1b1-42a9-aa60-8ebb3650efa6@github.com>
Message-ID: <KXNsLyIeIrdXtDgMNZQLasLRXvDLea_Exz5MLTRLg1U=.fad1347c-8b1a-4ce5-b1ce-5a61539334c3@github.com>

On Thu, 9 Sep 2021 07:27:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This bug was found by the test added by the https://github.com/openjdk/jdk/pull/5042. The crash is rarely reproduced, and in the default testrun, I was not able to crash it even once. But I have found that if the 1000 tests are executed in parallel a few crashes(less than 10) usually happen.
> 
> After the code inspection, I have found and report the problem to the [LCMS upstream](https://bugs.openjdk.java.net/browse/JDK-8273135?focusedCommentId=14445750&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14445750) 
> 
> In this PR, I would like to cherry-pick the fix from the upstream and apply it to the JDK. So we prevent the crash and will have an opportunity to find some other issues if any (two crashes were found by this test already).

Marked as reviewed by aivanov (Reviewer).

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

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


From ant at openjdk.java.net  Mon Sep 13 15:45:48 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Mon, 13 Sep 2021 15:45:48 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation
In-Reply-To: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
Message-ID: <PoscVJhLP27IJH0rvOEjzclBRpFEAjIePu_CeLl-mJ0=.1a7732fb-13b9-49b0-baa4-1002c224617b@github.com>

On Fri, 10 Sep 2021 15:11:20 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> We've extended the current implementation of TableAccessibility to make sure that individual cells are voiced when navigating with the keyboard.

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ColumnAccessibility.m line 52:

> 50: }
> 51: 
> 52: - (NSArray *)accessibilityChildren

Could you please clarify why you removed this method?

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

> 221: 
> 222: - (id)accessibilityCellForColumn:(NSInteger)column row:(NSInteger)row {
> 223:     return [[(TableRowAccessibility *)[[self accessibilityRows] objectAtIndex:row] accessibilityChildren] objectAtIndex:column];

This implementation is inefficient. You're creating an instance per each row in the table (think about long tables) just for taking a single row. Same for columns.

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

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


From azvegint at openjdk.java.net  Mon Sep 13 17:41:49 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 13 Sep 2021 17:41:49 GMT
Subject: RFR: 8273135:
 java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java crashes in
 liblcms.dylib with NULLSeek+0x7
In-Reply-To: <xSp6L73skKla4HU_yXoZExpBjJxz5x1l0PAvic41KtQ=.2cf91478-e1b1-42a9-aa60-8ebb3650efa6@github.com>
References: <xSp6L73skKla4HU_yXoZExpBjJxz5x1l0PAvic41KtQ=.2cf91478-e1b1-42a9-aa60-8ebb3650efa6@github.com>
Message-ID: <Pvcl2C_i9ApcpwqrMzM3KLkw3_k-5zTkedqQ0qc5Mi0=.dd98daef-e4c4-4c86-9669-83311ea3b277@github.com>

On Thu, 9 Sep 2021 07:27:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This bug was found by the test added by the https://github.com/openjdk/jdk/pull/5042. The crash is rarely reproduced, and in the default testrun, I was not able to crash it even once. But I have found that if the 1000 tests are executed in parallel a few crashes(less than 10) usually happen.
> 
> After the code inspection, I have found and report the problem to the [LCMS upstream](https://bugs.openjdk.java.net/browse/JDK-8273135?focusedCommentId=14445750&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14445750) 
> 
> In this PR, I would like to cherry-pick the fix from the upstream and apply it to the JDK. So we prevent the crash and will have an opportunity to find some other issues if any (two crashes were found by this test already).

Marked as reviewed by azvegint (Reviewer).

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

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


From prr at openjdk.java.net  Mon Sep 13 18:22:15 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 13 Sep 2021 18:22:15 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v3]
In-Reply-To: <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
Message-ID: <MT9B-BsDgcUmSrcEVVH94JXWQpitopGoQj8W60Kgkng=.aaa60b82-ed02-4985-9a75-8edbee201011@github.com>

On Fri, 10 Sep 2021 23:34:19 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> removed support for running demo from applet for J2Ddemo and SwingSet2
>> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8205137: Reverted accidental code reformat
>   
>   Reviewed-by: alichung

https://www.oracle.com/technetwork/java/codeconventions-150003.pdf didn't say anything relevant.

The still-in-draft update to this  http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-import-statements
which is focused on OpenJDK developers says

Import statements should be sorted?
?primarily by non-static / static with non-static imports first.
?secondarily by package origin according to the following order
java packages
javax packages
external packages (e.g. org.xml)
internal packages (e.g. com.sun)
?tertiary by package and class identifier in lexicographical order

So that isn't yet "blessed" and could be written a bit more clearly but I could also imagine quibbles these days
like "group imports by module, starting with java.base" as the primary one.

And imports from named modules go first ..

And I can imagine folks wanting to place exception imports after other imports ..

So I don't think there is any agreed upon set of rules to follow although most folks
when you get down to the specific package do place them in lexical order

Here I note that the pre-existing wild card imports were of javax.swing followed  by java.awt*
and the change is preserving that so I don't have a strong opinion on that nor do I think I
would insist on lexical ordering but I also would be quite fine if the fixer is OK to make that change.

src/demo/share/jfc/SwingSet2/DemoModule.java line 45:

> 43: import java.util.*;
> 44: import java.io.*;
> 45: import java.net.*;

Oops. I missed we still have wildcards here

src/demo/share/jfc/SwingSet2/TabbedPaneDemo.java line 47:

> 45: import java.util.*;
> 46: import java.io.*;
> 47: import java.net.*;

And also stilll have them here.

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

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


From pbansal at openjdk.java.net  Mon Sep 13 18:31:57 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 13 Sep 2021 18:31:57 GMT
Subject: RFR: 8273638: javax/swing/JTable/4235420/bug4235420.java fails in
 GTK L&F
In-Reply-To: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
References: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
Message-ID: <qJlI6B5xRBK_s5wIVE2wjl0TjLIg8xgIWCaMluzoVTQ=.5ed89a5f-3e0f-4107-bfe4-30eef14c1ba9@github.com>

On Mon, 13 Sep 2021 02:49:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As discussed here https://github.com/openjdk/jdk/pull/1813 the test should skip the GTK L&F unfortunately the name of the GTK L&F is "GTK look and feel" not "GTK". The ID="GTK" can be used instead.

The test has some wildcard imports. You can remove them if possible, otherwise it is ok.

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Mon Sep 13 19:05:52 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Mon, 13 Sep 2021 19:05:52 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v3]
In-Reply-To: <MT9B-BsDgcUmSrcEVVH94JXWQpitopGoQj8W60Kgkng=.aaa60b82-ed02-4985-9a75-8edbee201011@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
 <MT9B-BsDgcUmSrcEVVH94JXWQpitopGoQj8W60Kgkng=.aaa60b82-ed02-4985-9a75-8edbee201011@github.com>
Message-ID: <Htu9zGUfnGsyrYvLhNWYCkDPAi-ODGZ767ykxgo8TvU=.5ac3668c-0676-4347-a3e3-a7b7f6539bcc@github.com>

On Mon, 13 Sep 2021 18:18:58 GMT, Phil Race <prr at openjdk.org> wrote:

> So I don't think there is any agreed upon set of rules to follow although most folks
> when you get down to the specific package do place them in lexical order
> 
> Here I note that the pre-existing wild card imports were of javax.swing followed by java.awt*
> and the change is preserving that so I don't have a strong opinion on that nor do I think I
> would insist on lexical ordering but I also would be quite fine if the fixer is OK to make that change.

I can do this and fix the other two files that I missed.

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

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


From github.com+741251+turbanoff at openjdk.java.net  Mon Sep 13 19:29:21 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 13 Sep 2021 19:29:21 GMT
Subject: RFR: 8273684: Unnecessary Stack usage
Message-ID: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>

Usage of thread-safe collection Stack is unnecessary. It's recommended to use ArrayDequeue if a thread-safe implementation is not needed.

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

Commit messages:
 - [PATCH] Stack usages can be replaced with ArrayDequeue
 - [PATCH] Stack usages can be replaced with ArrayDequeue
 - [PATCH] Stack usages can be replaced with ArrayDequeue
 - [PATCH] Stack usages can be replaced with ArrayDequeue
 - [PATCH] Stack usages can be replaced with ArrayDequeue

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

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


From serb at openjdk.java.net  Mon Sep 13 19:29:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 13 Sep 2021 19:29:25 GMT
Subject: RFR: 8273684: Unnecessary Stack usage
In-Reply-To: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
Message-ID: <2hXgqRLf-gGxpafenuNS5j3-WSiQwZ_imEELqPuinh0=.9988cf9d-8965-45dd-8ed3-1e94d4c22ded@github.com>

On Sun, 29 Aug 2021 21:14:19 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Usage of thread-safe collection Stack is unnecessary. It's recommended to use ArrayDequeue if a thread-safe implementation is not needed.

Looks fine

Or maybe not, did you check that the order of pushing and the order of iteration for the stack and ArrayDeque are the same? I am not sure about it.

src/java.desktop/share/classes/com/sun/media/sound/DLSSoundbank.java line 34:

> 32: import java.io.OutputStream;
> 33: import java.net.URL;
> 34: import java.util.ArrayDeque;

Can we remove the Stack from the list of imports?

src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java line 2719:

> 2717:             }
> 2718:             Element[] retValue = new Element[elements.size()];
> 2719:             elements.toArray(retValue);

Same comment as in some other review, the copyInto and toArray works differently, it is better to use return elements.toArray(new Element[0]);

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

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


From github.com+741251+turbanoff at openjdk.java.net  Mon Sep 13 19:29:29 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 13 Sep 2021 19:29:29 GMT
Subject: RFR: 8273684: Unnecessary Stack usage
In-Reply-To: <2hXgqRLf-gGxpafenuNS5j3-WSiQwZ_imEELqPuinh0=.9988cf9d-8965-45dd-8ed3-1e94d4c22ded@github.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
 <2hXgqRLf-gGxpafenuNS5j3-WSiQwZ_imEELqPuinh0=.9988cf9d-8965-45dd-8ed3-1e94d4c22ded@github.com>
Message-ID: <rRZka4lJba8Uyr8Bu6jCXShzh9BdcxdlVbtMnG8Ky-0=.30b10a8d-be86-42fb-a3c9-ec461664522c@github.com>

On Wed, 8 Sep 2021 21:34:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Usage of thread-safe collection Stack is unnecessary. It's recommended to use ArrayDequeue if a thread-safe implementation is not needed.
>
> src/java.desktop/share/classes/com/sun/media/sound/DLSSoundbank.java line 34:
> 
>> 32: import java.io.OutputStream;
>> 33: import java.net.URL;
>> 34: import java.util.ArrayDeque;
> 
> Can we remove the Stack from the list of imports?

Removed

> src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java line 2719:
> 
>> 2717:             }
>> 2718:             Element[] retValue = new Element[elements.size()];
>> 2719:             elements.toArray(retValue);
> 
> Same comment as in some other review, the copyInto and toArray works differently, it is better to use return elements.toArray(new Element[0]);

Updated

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

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


From github.com+741251+turbanoff at openjdk.java.net  Mon Sep 13 19:29:26 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 13 Sep 2021 19:29:26 GMT
Subject: RFR: 8273684: Unnecessary Stack usage
In-Reply-To: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
Message-ID: <XqP_l9M7VeqgW1cVrTov742s2Beh0U9BwSpj1jYzPsk=.c0df2e75-8012-4123-9eb1-a69687798985@github.com>

On Sun, 29 Aug 2021 21:14:19 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Usage of thread-safe collection Stack is unnecessary. It's recommended to use ArrayDequeue if a thread-safe implementation is not needed.

Yeah. You are right! TIL that order of iteration is different in ArrayDequeu vs Stack: Stack.push() adds to the "end of stack" (it just calls Vector.add()), while ArrayDeque.push adds "first element"
Luckily for us there was only one place which depend on this. It's small method `javax.swing.text.html.HTMLDocument.HTMLReader#getPathTo`. I've changed method to use ArrayList instead.

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

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


From aivanov at openjdk.java.net  Mon Sep 13 20:12:55 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 13 Sep 2021 20:12:55 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v3]
In-Reply-To: <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
Message-ID: <3enuweac7HVQkWJTZ1ec7dJ7U8NPauHZGUNneEGhHwU=.cb2b27b7-b4b1-4cfa-b9e9-c3691cd4c691@github.com>

On Fri, 10 Sep 2021 23:34:19 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> removed support for running demo from applet for J2Ddemo and SwingSet2
>> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8205137: Reverted accidental code reformat
>   
>   Reviewed-by: alichung

I asked about imports because I usually see `java.*` followed by `javax.*` followed by internal imports in the JDK code. I wanted to confirm my understanding.

If I remember correctly, IDEA has a different order by default: other imports, then `java.*` and `javax.*`. I can see the motivation here: for projects using Java, you care about your own classes more than `java(x)` packages. For JDK, java(x) are the important ones.

In this case, the previous order of the imports was preserved where `javax.*` imports were before `java.*`. In addition to that, SwingSet2 is a demo of Swing components, so having `javax.swing.*` above `java.awt.*` makes sense to me too.

> Here I note that the pre-existing wild card imports were of javax.swing followed by java.awt*
> and the change is preserving that so I don't have a strong opinion on that nor do I think I
> would insist on lexical ordering but I also would be quite fine if the fixer is OK to make that change.

I'm also fine with either order of the imports.

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Mon Sep 13 21:58:53 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Mon, 13 Sep 2021 21:58:53 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTexTAndGraphicsState.java
Message-ID: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>

Problem : 
1) Test case was failing with following exception
test result: Error. Parse Exception: Arguments to `manual' option not supported: yes 
2) After removing =yes/no Parser exception is not seen but test UI will show and closes immediately  where the user cannot see what is on the frame. 

Fix : 
1) Add frame to show the test instructions.
2) Added timeout for the test case.
3) Show the test UI until either test case gets timeout or user press pass or fail button.

@shurymury

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

Commit messages:
 - 8273685 : Remove jtreg tag manual=yesno for java/awt/Graphics/LCDTextAndGraphicsState.java

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

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


From serb at openjdk.java.net  Mon Sep 13 23:13:47 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 13 Sep 2021 23:13:47 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v3]
In-Reply-To: <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
Message-ID: <s22mPtOAlGHQGt4Ylc7sBmf7oqdY0jbbDz5cDf93Vy8=.e296b990-0c0a-42f8-a39c-1674cc2eb26b@github.com>

On Fri, 10 Sep 2021 23:34:19 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> removed support for running demo from applet for J2Ddemo and SwingSet2
>> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8205137: Reverted accidental code reformat
>   
>   Reviewed-by: alichung

I suggest using the same order no need to think about which order is correct in which file, but simple as this: https://github.com/openjdk/jdk/pull/5401#issuecomment-917305195

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

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


From prr at openjdk.java.net  Mon Sep 13 23:24:18 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 13 Sep 2021 23:24:18 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v3]
In-Reply-To: <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
Message-ID: <IHimdUt7CaghaKEsyBueAFofNatbP8I24OMiuVV0SJ0=.9a70e5f4-1aae-4289-99b1-debfe4a0f88b@github.com>

On Fri, 10 Sep 2021 23:34:19 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> removed support for running demo from applet for J2Ddemo and SwingSet2
>> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8205137: Reverted accidental code reformat
>   
>   Reviewed-by: alichung

> I suggest using the same order no need to think about which order is correct in which file, but simple as this: [#5401 (comment)](https://github.com/openjdk/jdk/pull/5401#issuecomment-917305195)

My point is that you can't point to any doc that says "this is the order to be used" because we've never codified it.
So as long as it is reasonable .. ie not jumping from package to package, it's all good.

FWIW the old style guideline doesn't even have anything to say about not using wildcards.  I guess they were thought to be cool but as things got bigger it became vulnerable to clashes, so there is "general" acceptance that there's a good reason for explicit imports beyond aesthetics or style.

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Tue Sep 14 00:10:26 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Tue, 14 Sep 2021 00:10:26 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTexTAndGraphicsState.java [v2]
In-Reply-To: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
Message-ID: <TdctZLjCnE9j7nwSNF58kdpa_Q9NxzmOSZSiqU3GCW4=.5cba103a-c9d9-4960-9bea-6be6824afed4@github.com>

> Problem : 
> 1) Test case was failing with following exception
> test result: Error. Parse Exception: Arguments to `manual' option not supported: yes 
> 2) After removing =yes/no Parser exception is not seen but test UI will show and closes immediately  where the user cannot see what is on the frame. 
> 
> Fix : 
> 1) Add frame to show the test instructions.
> 2) Added timeout for the test case.
> 3) Show the test UI until either test case gets timeout or user press pass or fail button.
> 
> @shurymury

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Fixed minor issue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5503/files
  - new: https://git.openjdk.java.net/jdk/pull/5503/files/5f125427..31474053

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

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

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


From github.com+741251+turbanoff at openjdk.java.net  Tue Sep 14 07:32:13 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 14 Sep 2021 07:32:13 GMT
Subject: RFR: 8273684: Unnecessary Stack usage
In-Reply-To: <AM0PR03MB4145D2F6630799B141E85B77FFDA9@AM0PR03MB4145.eurprd03.prod.outlook.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
 <AM0PR03MB4145D2F6630799B141E85B77FFDA9@AM0PR03MB4145.eurprd03.prod.outlook.com>
Message-ID: <BoXcibguYdmT67SZhc868iOJE1UvYsIFd__uTzEqe7I=.b2e5d9c4-4986-4033-b36f-cde53768df65@github.com>

On Tue, 14 Sep 2021 00:33:32 GMT, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:

>Maybe better use addFirst(), for example in CommandProcessor there is a comment that order matters (did not check it more closely), so it?s probably best to not reverse orders in any place?

In all other places (except HTMLReader), iteration order don't matter. Stack only accessed via _classic_ well known stack operations: push, pop, peek. This methods work in the same way in ArrayDeque. So I think replacing with `addFirst` isn't necessary.

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

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


From myano at openjdk.java.net  Tue Sep 14 08:00:26 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Tue, 14 Sep 2021 08:00:26 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
Message-ID: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>

Could you please review the 7001973 fixes?

On Windows, CopyAreaOOB.java fails with a blank window. The cause of this problem is that paint() works one time only. Painting area is not guaranteed when showing a window.

I think this behavior should be removed for purpose of this test (`@summary: Verifies that copyArea() works properly`). Also, this program uses a Robot, but implements waiting logic by itself. This logic should be replaced to Robot API.

This fix works fine in Windows, so this test can be removed from ProblemList.txt. I don't have a Mac environment, so can someone please confirm that this fix will work on Mac?

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

Commit messages:
 - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
 - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails

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

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


From avu at openjdk.java.net  Tue Sep 14 08:09:09 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 14 Sep 2021 08:09:09 GMT
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1
In-Reply-To: <bk4AVqWHM9W36QHctxfeZcjz276NqmBPaVnXoax0og8=.238c086a-caab-460a-83b9-40aa03d7fc65@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
 <SNyuR1X22y8s5fgY2SxbBC4YnTsbwRVGaDueDJUafGA=.b712f798-b360-4894-8efb-164f16010c9e@github.com>
 <gPtzMfGUoBCDlQnVy17AZgjRzcs32op73LIk64YQuhc=.bce7ff9c-cc45-453d-bac7-1c93e4c38033@github.com>
 <9bL2RnessX94pH3VPEC3uDrofP1pI5zZDVdMk3fKNLA=.9fc8cb35-1dcf-4a18-bce7-185d06318fca@github.com>
 <0D8uAWG2YiPNYP7erm_toYu2GfeIZS284OF3Rzq5v08=.0e7030f0-21ad-4f48-8070-475ede8baacb@github.com>
 <8tSmo2KjJAJ0rrII9X-tdMFlfKlee2dE1TEMQQyGRjg=.6515a3f2-7361-408f-af29-fc386491d776@github.com>
 <WxFE4j8lqh3_thQpDMvkoeN3mjN71SG78f-dzTL9zq4=.c6e69721-8165-4f98-a6bb-554b846360e6@github.com>
 <arCYURxgge3090MLrRstAb6SsXmsYjA4qJotV-eiNTk=.feb77f41-c510-4494-a0c8-170dc1eed05c@github.com>
 <T6i4B724OBydh9ZZIrA8XCVGjbyo6g3ML42Cj8goLnk=.7e430412-5158-4110-a4ae-9d6969c7c7f7@github.com>
 <OImJBqq6yKEsvALPqIAxdDuO080g9ICfBf4gGkx3M-Q=.850f58b9-f064-4bc7-890e-8e224c42dad9@github.com>
 <PDssR6-CgWSp3VqD09jGtWolf1TCWpLh9wX
 3VIS3tCE=.a3a36813-51ef-48ef-be41-55a765f70457@github.com>
 <Bcok1DRh4QVunmsxiNyn8oc5WqteT3a0JMXOGU2uRUU=.326ec58e-ddcb-4392-bee1-d3c683668a9f@github.com>
 <bk4AVqWHM9W36QHctxfeZcjz276NqmBPaVnXoax0og8=.238c086a-caab-460a-83b9-40aa03d7fc65@github.com>
Message-ID: <_KUJdkYal05GGNEqjvl_4-OKux_k3QDptFdDc4AtHTg=.0a1374a8-6c96-490d-a965-e44e8ce97b2c@github.com>

On Mon, 13 Sep 2021 07:11:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > in a normal state (when the window is created) we don't need to flush the layer content faster than DisplayLink provide.
> 
> But this is exactly related to the performance, no? When the RenderPerf test is executed it should check that delay between fillRect and the actual rendering is as small as possible. Can you please just confirm that the problem is in the "performance" of DisplayLink and unrelated to some broken rendering? I guess you can create two timestamps in NSWindow creation and in Layer callback(where we actually blit the content/ drawInXXXContext). How that timing is different for metal and OGL?

I did some measurements for Metal and OGL and didn't find any noticeable difference with the simple test (just showing the frame)
Metal
1631605170711 window appeared
1631605170723 rendering submitted
1631605170724 rendering complete
1631605170747 rendering submitted
1631605170747 rendering complete
OGL
1631605401836 rendering complete
1631605401838 rendering complete
1631605401843 window appeared
1631605401881 rendering complete

Metal has additional output because we can track two stages - submission and completion. Also, I saw the flickering with OGL too (if we have no match with content and window colors)

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Tue Sep 14 13:58:04 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Tue, 14 Sep 2021 13:58:04 GMT
Subject: RFR: 8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java
 does not show instruction
In-Reply-To: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
References: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
Message-ID: <rrJ5_X5jxSJT3EuxtBxozwMo_LGsS0go-onSatO5XBM=.9c61e665-d5df-495d-8efb-b25ff6d05252@github.com>

On Tue, 20 Jul 2021 23:54:20 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

> 1) When the test is executed via jtreg user can see only print dialog with no instruction to the user. User has to see the test case to see the instruction and perform the test . 
> 2) With this fix User is instructed what he/she has to do with the print dialog.
> 3) I have added both success instruction as well as failure instruction.
> 
> @shurymury

Commenting to keep the PR open

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

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


From github.com+36081106+savoptik at openjdk.java.net  Tue Sep 14 14:35:37 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 14 Sep 2021 14:35:37 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation [v2]
In-Reply-To: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
Message-ID: <6KGQ30cA0qY34jfTQTw4nMdehZjRl87Fu0A0QyMw6-M=.a9ee8a6b-7eb3-401a-9a10-4b10ed299c60@github.com>

> We've extended the current implementation of TableAccessibility to make sure that individual cells are voiced when navigating with the keyboard.

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

  8271071 accessibility of a table on macOS lacks cell navigation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5466/files
  - new: https://git.openjdk.java.net/jdk/pull/5466/files/61d947d1..6460deb3

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

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

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


From github.com+36081106+savoptik at openjdk.java.net  Tue Sep 14 14:35:43 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 14 Sep 2021 14:35:43 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation [v2]
In-Reply-To: <PoscVJhLP27IJH0rvOEjzclBRpFEAjIePu_CeLl-mJ0=.1a7732fb-13b9-49b0-baa4-1002c224617b@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
 <PoscVJhLP27IJH0rvOEjzclBRpFEAjIePu_CeLl-mJ0=.1a7732fb-13b9-49b0-baa4-1002c224617b@github.com>
Message-ID: <HX8wre9PXg8MNRVegV1GoDnXMyV2MmelanVAL4TWiI8=.e6027d39-9ce5-4694-9f8c-05a894c70e9f@github.com>

On Mon, 13 Sep 2021 14:47:30 GMT, Anton Tarasov <ant at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8271071 accessibility of a table on macOS lacks cell navigation
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ColumnAccessibility.m line 52:
> 
>> 50: }
>> 51: 
>> 52: - (NSArray *)accessibilityChildren
> 
> Could you please clarify why you removed this method?

As the analysis of the a11y table hierarchy in numbers showed, this object has no children. From which I conclude that the columns should not have children.

> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m line 223:
> 
>> 221: 
>> 222: - (id)accessibilityCellForColumn:(NSInteger)column row:(NSInteger)row {
>> 223:     return [[(TableRowAccessibility *)[[self accessibilityRows] objectAtIndex:row] accessibilityChildren] objectAtIndex:column];
> 
> This implementation is inefficient. You're creating an instance per each row in the table (think about long tables) just for taking a single row. Same for columns.

done

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

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


From ant at openjdk.java.net  Tue Sep 14 15:22:04 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Tue, 14 Sep 2021 15:22:04 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation [v2]
In-Reply-To: <HX8wre9PXg8MNRVegV1GoDnXMyV2MmelanVAL4TWiI8=.e6027d39-9ce5-4694-9f8c-05a894c70e9f@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
 <PoscVJhLP27IJH0rvOEjzclBRpFEAjIePu_CeLl-mJ0=.1a7732fb-13b9-49b0-baa4-1002c224617b@github.com>
 <HX8wre9PXg8MNRVegV1GoDnXMyV2MmelanVAL4TWiI8=.e6027d39-9ce5-4694-9f8c-05a894c70e9f@github.com>
Message-ID: <qVxiKT6fKmCSCTOshfbVZ81_ySsVUy7Dfuho7mmztlY=.20869ba1-45f1-436d-9d70-e3ab1cd1b5a8@github.com>

On Tue, 14 Sep 2021 14:30:40 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ColumnAccessibility.m line 52:
>> 
>>> 50: }
>>> 51: 
>>> 52: - (NSArray *)accessibilityChildren
>> 
>> Could you please clarify why you removed this method?
>
> As the analysis of the a11y table hierarchy in numbers showed, this object has no children. From which I conclude that the columns should not have children.

It is not clear why we should manage columns without children. Would it be better if you investigate it separately, and here you do not remove this method?

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

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


From github.com+36081106+savoptik at openjdk.java.net  Tue Sep 14 15:50:34 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 14 Sep 2021 15:50:34 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation [v3]
In-Reply-To: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
Message-ID: <OYD5nXxsk7Rb6orDwB2ulOOxfuMu93OjB-O998fFF3M=.9f8b878e-988e-4a19-b06b-5d45214565e8@github.com>

> We've extended the current implementation of TableAccessibility to make sure that individual cells are voiced when navigating with the keyboard.

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

  It is not clear why we should manage columns without children. Would it be better if you investigate it separately, and here you do not remove this method?

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5466/files
  - new: https://git.openjdk.java.net/jdk/pull/5466/files/6460deb3..c462fefa

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

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

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


From github.com+36081106+savoptik at openjdk.java.net  Tue Sep 14 15:50:36 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 14 Sep 2021 15:50:36 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation [v3]
In-Reply-To: <qVxiKT6fKmCSCTOshfbVZ81_ySsVUy7Dfuho7mmztlY=.20869ba1-45f1-436d-9d70-e3ab1cd1b5a8@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
 <PoscVJhLP27IJH0rvOEjzclBRpFEAjIePu_CeLl-mJ0=.1a7732fb-13b9-49b0-baa4-1002c224617b@github.com>
 <HX8wre9PXg8MNRVegV1GoDnXMyV2MmelanVAL4TWiI8=.e6027d39-9ce5-4694-9f8c-05a894c70e9f@github.com>
 <qVxiKT6fKmCSCTOshfbVZ81_ySsVUy7Dfuho7mmztlY=.20869ba1-45f1-436d-9d70-e3ab1cd1b5a8@github.com>
Message-ID: <FaeoHUsICUwL2d0fr1ONwZMQp-51g5Dui6HLMcxiYms=.48a5c31f-a7f8-40a9-865c-8aabd2660c53@github.com>

On Tue, 14 Sep 2021 15:18:57 GMT, Anton Tarasov <ant at openjdk.org> wrote:

>> As the analysis of the a11y table hierarchy in numbers showed, this object has no children. From which I conclude that the columns should not have children.
>
> It is not clear why we should manage columns without children. Would it be better if you investigate it separately, and here you do not remove this method?

done

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

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


From ant at openjdk.java.net  Tue Sep 14 16:01:10 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Tue, 14 Sep 2021 16:01:10 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation [v3]
In-Reply-To: <OYD5nXxsk7Rb6orDwB2ulOOxfuMu93OjB-O998fFF3M=.9f8b878e-988e-4a19-b06b-5d45214565e8@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
 <OYD5nXxsk7Rb6orDwB2ulOOxfuMu93OjB-O998fFF3M=.9f8b878e-988e-4a19-b06b-5d45214565e8@github.com>
Message-ID: <Z7E66M57cD9MmEr2X9ONBl05KS79ZP7RUzA0xjqwp-o=.056f7639-13e7-4e83-9774-f8a6b9f86083@github.com>

On Tue, 14 Sep 2021 15:50:34 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> We've extended the current implementation of TableAccessibility to make sure that individual cells are voiced when navigating with the keyboard.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   It is not clear why we should manage columns without children. Would it be better if you investigate it separately, and here you do not remove this method?

Marked as reviewed by ant (Reviewer).

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

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


From pbansal at openjdk.java.net  Tue Sep 14 16:42:02 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 14 Sep 2021 16:42:02 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTexTAndGraphicsState.java [v2]
In-Reply-To: <TdctZLjCnE9j7nwSNF58kdpa_Q9NxzmOSZSiqU3GCW4=.5cba103a-c9d9-4960-9bea-6be6824afed4@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
 <TdctZLjCnE9j7nwSNF58kdpa_Q9NxzmOSZSiqU3GCW4=.5cba103a-c9d9-4960-9bea-6be6824afed4@github.com>
Message-ID: <Tfr0txtCK5ZdRebvLCfwBmFpjK3c-HJBndl6qJ_ORIA=.48f6c687-f1c4-46e8-93f1-40bbd0cafb6c@github.com>

On Tue, 14 Sep 2021 00:10:26 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

>> Problem : 
>> 1) Test case was failing with following exception
>> test result: Error. Parse Exception: Arguments to `manual' option not supported: yes 
>> 2) After removing =yes/no Parser exception is not seen but test UI will show and closes immediately  where the user cannot see what is on the frame. 
>> 
>> Fix : 
>> 1) Add frame to show the test instructions.
>> 2) Added timeout for the test case.
>> 3) Show the test UI until either test case gets timeout or user press pass or fail button.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed minor issue

test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 126:

> 124:         instructionTextArea.setText(INSTRUCTIONS);
> 125:         instructionTextArea.setEditable(false);
> 126:         instructionTextArea.setBackground(Color.white);

Is there a particular reason to set the background as white? It is better if the background and foreground colors are set by the L&F itself.  I have fixed couple of bugs for GTKL&F, where the panel background color was set manually and then the L&F chosen color for foreground/Text was also same, so the text was not visible at all.

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Tue Sep 14 17:02:13 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Tue, 14 Sep 2021 17:02:13 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTexTAndGraphicsState.java [v2]
In-Reply-To: <Tfr0txtCK5ZdRebvLCfwBmFpjK3c-HJBndl6qJ_ORIA=.48f6c687-f1c4-46e8-93f1-40bbd0cafb6c@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
 <TdctZLjCnE9j7nwSNF58kdpa_Q9NxzmOSZSiqU3GCW4=.5cba103a-c9d9-4960-9bea-6be6824afed4@github.com>
 <Tfr0txtCK5ZdRebvLCfwBmFpjK3c-HJBndl6qJ_ORIA=.48f6c687-f1c4-46e8-93f1-40bbd0cafb6c@github.com>
Message-ID: <ZY-o3jdIqm-Rk3Gbz6Y8JI1U3S-_y3Blrav1gY_KlpI=.b861cdaa-3dc5-4f50-b2e7-70c4146d7e89@github.com>

On Tue, 14 Sep 2021 16:38:34 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed minor issue
>
> test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 126:
> 
>> 124:         instructionTextArea.setText(INSTRUCTIONS);
>> 125:         instructionTextArea.setEditable(false);
>> 126:         instructionTextArea.setBackground(Color.white);
> 
> Is there a particular reason to set the background as white? It is better if the background and foreground colors are set by the L&F itself.  I have fixed couple of bugs for GTKL&F, where the panel background color was set manually and then the L&F chosen color for foreground/Text was also same, so the text was not visible at all.

Nice point about look and feel. Sure, let me remove the background color.

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

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


From cjplummer at openjdk.java.net  Tue Sep 14 17:55:08 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 14 Sep 2021 17:55:08 GMT
Subject: RFR: 8273684: Unnecessary Stack usage
In-Reply-To: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
Message-ID: <9vilIHa165Q92J0ud-xeeaPbH1zQnRA-42mG_czCPUg=.0ddaacd4-36cf-4a59-bfee-a88a39232bd3@github.com>

On Sun, 29 Aug 2021 21:14:19 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Usage of thread-safe collection Stack is unnecessary. It's recommended to use ArrayDequeue if a thread-safe implementation is not needed.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java line 988:

> 986:                 // Make sure the types are emitted in an order than can be read back in
> 987:                 HashSet<String> emitted = new HashSet<>();
> 988:                 ArrayDeque<Type> pending = new ArrayDeque<>();

Have you run the clhsdb vmstructsdump command to make sure the ordering hasn't changed?

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Tue Sep 14 18:32:36 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Tue, 14 Sep 2021 18:32:36 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v4]
In-Reply-To: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
Message-ID: <xvsbwlSW6IqxhtVpKmIihIdfcBKmsF2HxzFWw_U93wE=.14af81f0-4675-4852-92c4-ad5bb2893d7f@github.com>

> removed support for running demo from applet for J2Ddemo and SwingSet2
> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)

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

  alphabetized imports

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5401/files
  - new: https://git.openjdk.java.net/jdk/pull/5401/files/fe3bde46..e03d6d54

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

  Stats: 194 lines in 17 files changed: 72 ins; 83 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5401.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5401/head:pull/5401

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


From aivanov at openjdk.java.net  Tue Sep 14 18:42:11 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 14 Sep 2021 18:42:11 GMT
Subject: RFR: 8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java
 does not show instruction
In-Reply-To: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
References: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
Message-ID: <Hkt7teFERu0--geMSLbOQchV2WAhukLbTNm9l3oEw64=.70f6bb1d-6121-4fc1-ab1f-462d74e9aa68@github.com>

On Tue, 20 Jul 2021 23:54:20 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

> 1) When the test is executed via jtreg user can see only print dialog with no instruction to the user. User has to see the test case to see the instruction and perform the test . 
> 2) With this fix User is instructed what he/she has to do with the print dialog.
> 3) I have added both success instruction as well as failure instruction.
> 
> @shurymury

The test is semi-automatic: it is able to determine whether it passes or fails depending on whether the number of copies in the print dialog is modified or not.

Is it possible to complete the test as soon as either OK or Cancel button is clicked on the Print dialog?

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Tue Sep 14 21:05:49 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Tue, 14 Sep 2021 21:05:49 GMT
Subject: RFR: 8254841: Enter or Exit events are shouldn't be displayed while
 resizing
Message-ID: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>

Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.

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

Commit messages:
 - moved exceptions into test functions
 - accessing swing components on EDT thread, removed SpuriousExitEnter.java from ProblemList
 - 8254841: Added copyright header
 - 8254841: Enter or Exit events are shouldn't be displayed while resizing

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

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


From pbansal at openjdk.java.net  Tue Sep 14 21:05:49 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 14 Sep 2021 21:05:49 GMT
Subject: RFR: 8254841: Enter or Exit events are shouldn't be displayed
 while resizing
In-Reply-To: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
Message-ID: <QWW3pzo0GOFy8b8k1WBomWn8LNQeTv-nckvNpSkuoik=.5f6cb44d-e6a2-465a-8bd9-4951e78df711@github.com>

On Mon, 13 Sep 2021 18:03:39 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.

I have some suggestion for test
1. Access the swing components only on EDT thread.
2. The test java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter.java is added against the current bug in ProblemList. Please have a look at this test also. It is a manual test and it should also pass after your fix. If it does pass,  remove it from the ProblemList and if does not, please look into it.
3. Looks like the bug is a confidential bug, it should be made public for github review.

test/jdk/java/awt/event/MouseEvent/SpuriousExitEnter/ResizeMouseExitEnterMisfire.java line 36:

> 34:  * @bug 8254841
> 35:  * @summary Tests spurious firing of mouseEntered and mouseExit on resize
> 36:  * @author Alisen Chung: area=MouseEvent

The author tag is not added to the newly added tests. Infact, this is generally removed as part of cleanup while fixing something else in an old test

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

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


From kizune at openjdk.java.net  Tue Sep 14 21:05:50 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 14 Sep 2021 21:05:50 GMT
Subject: RFR: 8254841: Enter or Exit events are shouldn't be displayed
 while resizing
In-Reply-To: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
Message-ID: <U2XE1PY07XTSBDIwZ8JEDe4UpB7B7kVhR1ZsUnQmW64=.df46a8b9-eb0b-4cf0-862e-ec0416f55294@github.com>

On Mon, 13 Sep 2021 18:03:39 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.

test/jdk/java/awt/event/MouseEvent/SpuriousExitEnter/ResizeMouseExitEnterMisfire.java line 1:

> 1: import java.awt.Rectangle;

Any code we submit to the openjdk workspace should have a proper copyright header - test included. You can borrow it from any recently submitted or edited test.

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

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


From kcr at openjdk.java.net  Tue Sep 14 21:36:08 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 14 Sep 2021 21:36:08 GMT
Subject: RFR: 8254841: Enter or Exit events are shouldn't be displayed
 while resizing
In-Reply-To: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
Message-ID: <JKSpSxQU__p7OUSP1Ti_csnviJgJQkZUPL5p2DaWAZM=.14e12623-0e32-4ab9-bd43-4c8ff7ec187a@github.com>

On Mon, 13 Sep 2021 18:03:39 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.

>  @alisenchung alisenchung force-pushed the alisenchung:8254841 branch from dd8d591 to e299142 22 hours ago 

Absent a compelling reason, please do not force push to a branch once you have create a PR from that branch.

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

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


From prr at openjdk.java.net  Tue Sep 14 21:36:08 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 14 Sep 2021 21:36:08 GMT
Subject: RFR: 8254841: Enter or Exit events are shouldn't be displayed
 while resizing
In-Reply-To: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
Message-ID: <3Fz9af68eSG0T7Abz5uqlq5FquSJX2fbjFI9pQHl8m0=.cf699cbb-6ec9-4706-a70f-e2d339fd3d0d@github.com>

On Mon, 13 Sep 2021 18:03:39 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.

test/jdk/ProblemList.txt line 872:

> 870: java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter.java 8254841 macosx-all
> 871: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java 8256289 windows-x64
> 872: java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java 8258103 linux-all

When a jtreg test finds a failure and you fix the bug  it is customary to also update this test to add THIS bug ID to the list of tested bugs in the header of the test itself.

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Tue Sep 14 22:05:56 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Tue, 14 Sep 2021 22:05:56 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v2]
In-Reply-To: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
Message-ID: <ML-6qoWxRsMUttXmsTygOb_iMz3MrHsFAxrjaoHJGp8=.0ab16e40-05ef-442d-8c0b-3976e6db8867@github.com>

> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.

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

  added bug ID to test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5497/files
  - new: https://git.openjdk.java.net/jdk/pull/5497/files/f7f910bb..f455df82

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

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

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


From serb at openjdk.java.net  Wed Sep 15 04:15:45 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Sep 2021 04:15:45 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v2]
In-Reply-To: <ML-6qoWxRsMUttXmsTygOb_iMz3MrHsFAxrjaoHJGp8=.0ab16e40-05ef-442d-8c0b-3976e6db8867@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <ML-6qoWxRsMUttXmsTygOb_iMz3MrHsFAxrjaoHJGp8=.0ab16e40-05ef-442d-8c0b-3976e6db8867@github.com>
Message-ID: <TE3fZKmBT_1yGjNlbQLlaB3VLgar4E0NftRw3xa1KLk=.5b33137f-740b-4dd8-9296-86f6c3318ba8@github.com>

On Tue, 14 Sep 2021 22:05:56 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added bug ID to test

src/java.desktop/macosx/classes/sun/java2d/opengl/CGLLayer.java line 116:

> 114:             // 8254841: We need to tell the peer we have finished resizing
> 115:             // to resume posting mouseEntered and mouseExit events.
> 116:             peer.finishResizing();

Not sure that this call should be added to the render callback.

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

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


From serb at openjdk.java.net  Wed Sep 15 04:20:47 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Sep 2021 04:20:47 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v2]
In-Reply-To: <ML-6qoWxRsMUttXmsTygOb_iMz3MrHsFAxrjaoHJGp8=.0ab16e40-05ef-442d-8c0b-3976e6db8867@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <ML-6qoWxRsMUttXmsTygOb_iMz3MrHsFAxrjaoHJGp8=.0ab16e40-05ef-442d-8c0b-3976e6db8867@github.com>
Message-ID: <dI6yKxvCy5qLDu1gxGqBAMrF3CvPrG63EuoMTz-IOkQ=.eac5d915-1012-4601-a7a3-1d6d02faba32@github.com>

On Tue, 14 Sep 2021 22:05:56 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added bug ID to test

I have a general question about this bug, initially the test was added for https://bugs.openjdk.java.net/browse/JDK-6479820 and that bug was fixed because of this:

When resizing the window by dragging a corner with the mouse,
the panel receives entry/exit mouse events randomly.
These events should not occur because the mouse is not entering
or exiting the window, it is dragging a corner of its border.


And in the current bug description:

`The window resizing is a bit slower than mouse movement. So before the window resize can catch up to the mouse, the mouse exits the window, then re-enters when the window catches up to it. This can be verified if you resize the window at the edge without entering the window: there will be no mouseEntered or mouseExit events. `

So situation is different, if the mouse is moved faster than window is moving, then I do not see why we should not post an events. Especially if the native system did that.

But the question is it really a problem of slow window, or may be we have some bug in the nativeSynthesizeMouseEnteredExitedEvents where we synthesize such events when we should not.

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

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


From serb at openjdk.java.net  Wed Sep 15 04:24:50 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Sep 2021 04:24:50 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTexTAndGraphicsState.java [v2]
In-Reply-To: <TdctZLjCnE9j7nwSNF58kdpa_Q9NxzmOSZSiqU3GCW4=.5cba103a-c9d9-4960-9bea-6be6824afed4@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
 <TdctZLjCnE9j7nwSNF58kdpa_Q9NxzmOSZSiqU3GCW4=.5cba103a-c9d9-4960-9bea-6be6824afed4@github.com>
Message-ID: <-eaVMRGnmIeox1tRv08g0AmyHNy_lZvp9YlVhUIG2JI=.000aeb96-25ef-4407-bdc4-be9e14b2d5d0@github.com>

On Tue, 14 Sep 2021 00:10:26 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

>> Problem : 
>> 1) Test case was failing with following exception
>> test result: Error. Parse Exception: Arguments to `manual' option not supported: yes 
>> 2) After removing =yes/no Parser exception is not seen but test UI will show and closes immediately  where the user cannot see what is on the frame. 
>> 
>> Fix : 
>> 1) Add frame to show the test instructions.
>> 2) Added timeout for the test case.
>> 3) Show the test UI until either test case gets timeout or user press pass or fail button.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed minor issue

A few suggestions:
 - It will be good to remove horizontal scroll in  the instructions.
 - The frames should be closed when the pass/fail buttons are pressed

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

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


From serb at openjdk.java.net  Wed Sep 15 04:29:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Sep 2021 04:29:48 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
Message-ID: <zEMcuEDeUF8FS-1ZiJE06KkbtPhyqxw_noyOT7gJuvk=.bdb90fe8-0087-45bf-8d5c-0c8012bbaea1@github.com>

On Mon, 13 Sep 2021 11:32:37 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 7001973 fixes?
> 
> On Windows, CopyAreaOOB.java fails with a blank window. The cause of this problem is that paint() works one time only. Painting area is not guaranteed when showing a window.
> 
> I think this behavior should be removed for purpose of this test (`@summary: Verifies that copyArea() works properly`). Also, this program uses a Robot, but implements waiting logic by itself. This logic should be replaced to Robot API.
> 
> This fix works fine in Windows, so this test can be removed from ProblemList.txt. I don't have a Mac environment, so can someone please confirm that this fix will work on Mac?

This test is quite strict and its purpose exactly check that the first paint() will properly render the windows content.
So if the window will paint some garbage and then repaint correct content this test wil catch that.

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

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


From serb at openjdk.java.net  Wed Sep 15 04:47:50 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Sep 2021 04:47:50 GMT
Subject: RFR: 8273366: [testbug]
 javax/swing/UIDefaults/6302464/bug6302464.java fails on macOS12
In-Reply-To: <2EyNRUQjV3JMN_iuN7-Ls09BmrKhSHxZ-7OTHkOTBrY=.2f7ea803-8ead-4fdb-b27a-bbcbf1900ef2@github.com>
References: <2EyNRUQjV3JMN_iuN7-Ls09BmrKhSHxZ-7OTHkOTBrY=.2f7ea803-8ead-4fdb-b27a-bbcbf1900ef2@github.com>
Message-ID: <RhN7rcRN52fILvZZm__xiRs5ASKUkxUZDS3I1-xZ0Zw=.5b7ff378-5636-401c-98d2-5efe60c756eb@github.com>

On Thu, 9 Sep 2021 07:19:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails on macOS12 since the check was only upto macOS11..Extended the check for BigSurOrAbove.

ok

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

Marked as reviewed by serb (Reviewer).

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


From serb at openjdk.java.net  Wed Sep 15 04:57:50 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Sep 2021 04:57:50 GMT
Subject: RFR: 8205137: Remove Applet support from SwingSet2 [v3]
In-Reply-To: <IHimdUt7CaghaKEsyBueAFofNatbP8I24OMiuVV0SJ0=.9a70e5f4-1aae-4289-99b1-debfe4a0f88b@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
 <lga-gUA2LE1KUAFy_ndfrnlKWWyFYkZCqMn3WHHp-dY=.9d6caa06-60a8-4a10-afc8-243e24c64186@github.com>
 <IHimdUt7CaghaKEsyBueAFofNatbP8I24OMiuVV0SJ0=.9a70e5f4-1aae-4289-99b1-debfe4a0f88b@github.com>
Message-ID: <gIWWnXiWjCxkA6KFmH6Eoi0OZeJtmXL1kEp8YITVdr0=.22f99e11-ee38-4910-aa0a-754f2546263e@github.com>

On Mon, 13 Sep 2021 23:20:52 GMT, Phil Race <prr at openjdk.org> wrote:

> > I suggest using the same order no need to think about which order is correct in which file, but simple as this: [#5401 (comment)](https://github.com/openjdk/jdk/pull/5401#issuecomment-917305195)

> My point is that you can't point to any doc that says "this is the order to be used" because we've never codified it.

We did that, we discussed it someday long ago and I followed it for most of my code cleanups in java desktop module. It also was summarised here http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-import-statements
But yes we did not strictly follow it, not a big issue.

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

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


From serb at openjdk.java.net  Wed Sep 15 04:59:46 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Sep 2021 04:59:46 GMT
Subject: RFR: 8273355: Lanai: Flickering on tooltip appearance IntelliJ
 IDEA 2021.2.1 [v2]
In-Reply-To: <a7-dWuKWJQYCwCoFEYUqOz7ZKqQh2gY7UKGG0I9dVjo=.df6a4816-9cc6-40ca-bc20-8ebba8d31b03@github.com>
References: <B4s96NF8HWPTv-8IlmW87WqG-GaBd1kRqw6-bG5i1IU=.ffd5443f-506a-4065-a999-df5dbccea90c@github.com>
 <a7-dWuKWJQYCwCoFEYUqOz7ZKqQh2gY7UKGG0I9dVjo=.df6a4816-9cc6-40ca-bc20-8ebba8d31b03@github.com>
Message-ID: <1ec9F5cjdyM41ejVgA8rViwL6jpTE5nv_MX8R57LIKs=.175e7b5c-32c3-46bb-af82-d3d8edff8451@github.com>

On Fri, 10 Sep 2021 19:30:20 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Used setOpaque() method to set correct background of platform window
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273355: Lanai: Flickering on tooltip appearance IntelliJ IDEA 2021.2.1
>   
>   Extracted setting background to the particular method in PlatformWindow. Provided appropriate implementation in CPlatformWindow.

Then why you clearly see that missmatch in case of metal? probably we initialise the metal layer or its texture to some wrong color? or it is transparent and background of the nswindow is visible?

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

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


From serb at openjdk.java.net  Wed Sep 15 05:18:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Sep 2021 05:18:48 GMT
Subject: Integrated: 8273638: javax/swing/JTable/4235420/bug4235420.java fails
 in GTK L&F
In-Reply-To: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
References: <xrie6RIwR6aLmrWZ2w_Ayek_LN2m0-sv5-mjxLUzl_E=.cb6feaf5-290c-4422-950d-4f73b692fea8@github.com>
Message-ID: <ltWN790tKeT6wk_5XB8Gh_CoFnLyVHi0mEsMCTWoWYU=.44bb6111-7609-4d16-9cf1-f47641d8686c@github.com>

On Mon, 13 Sep 2021 02:49:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As discussed here https://github.com/openjdk/jdk/pull/1813 the test should skip the GTK L&F unfortunately the name of the GTK L&F is "GTK look and feel" not "GTK". The ID="GTK" can be used instead.

This pull request has now been integrated.

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

8273638: javax/swing/JTable/4235420/bug4235420.java fails in GTK L&F

Reviewed-by: pbansal, psadhukhan, azvegint

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

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


From serb at openjdk.java.net  Wed Sep 15 05:21:51 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Sep 2021 05:21:51 GMT
Subject: Integrated: 8273135:
 java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java crashes in
 liblcms.dylib with NULLSeek+0x7
In-Reply-To: <xSp6L73skKla4HU_yXoZExpBjJxz5x1l0PAvic41KtQ=.2cf91478-e1b1-42a9-aa60-8ebb3650efa6@github.com>
References: <xSp6L73skKla4HU_yXoZExpBjJxz5x1l0PAvic41KtQ=.2cf91478-e1b1-42a9-aa60-8ebb3650efa6@github.com>
Message-ID: <OrF87kHCJijhmbg9ECuShXaNj2RgU5kC-vPDIuc1Mi0=.9acd3b29-73ae-417a-a451-da6c511a8ce6@github.com>

On Thu, 9 Sep 2021 07:27:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This bug was found by the test added by the https://github.com/openjdk/jdk/pull/5042. The crash is rarely reproduced, and in the default testrun, I was not able to crash it even once. But I have found that if the 1000 tests are executed in parallel a few crashes(less than 10) usually happen.
> 
> After the code inspection, I have found and report the problem to the [LCMS upstream](https://bugs.openjdk.java.net/browse/JDK-8273135?focusedCommentId=14445750&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14445750) 
> 
> In this PR, I would like to cherry-pick the fix from the upstream and apply it to the JDK. So we prevent the crash and will have an opportunity to find some other issues if any (two crashes were found by this test already).

This pull request has now been integrated.

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

8273135: java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java crashes in liblcms.dylib with NULLSeek+0x7

Reviewed-by: aivanov, azvegint

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

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


From psadhukhan at openjdk.java.net  Wed Sep 15 05:45:55 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 15 Sep 2021 05:45:55 GMT
Subject: Integrated: 8273366: [testbug]
 javax/swing/UIDefaults/6302464/bug6302464.java fails on macOS12
In-Reply-To: <2EyNRUQjV3JMN_iuN7-Ls09BmrKhSHxZ-7OTHkOTBrY=.2f7ea803-8ead-4fdb-b27a-bbcbf1900ef2@github.com>
References: <2EyNRUQjV3JMN_iuN7-Ls09BmrKhSHxZ-7OTHkOTBrY=.2f7ea803-8ead-4fdb-b27a-bbcbf1900ef2@github.com>
Message-ID: <yh1i2_rFBQQkWfEtPrQmAlrz6R9WGNX_Dx5LuKB5m4s=.a6498602-4dbb-49a0-bf58-c27fd25c9af4@github.com>

On Thu, 9 Sep 2021 07:19:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails on macOS12 since the check was only upto macOS11..Extended the check for BigSurOrAbove.

This pull request has now been integrated.

Changeset: febcc72a
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/febcc72a549e973de4649503fc686fc520e3b3cd
Stats:     10 lines in 1 file changed: 6 ins; 0 del; 4 mod

8273366: [testbug] javax/swing/UIDefaults/6302464/bug6302464.java fails on macOS12

Reviewed-by: aivanov, serb

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

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


From alexsch at openjdk.java.net  Wed Sep 15 06:01:36 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Wed, 15 Sep 2021 06:01:36 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class
Message-ID: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>

FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.

Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).

FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.

The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.

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

Commit messages:
 - 8273581: Change the mechanism by which JDK loads the platform-specific FontManager class

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

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


From psadhukhan at openjdk.java.net  Wed Sep 15 06:15:45 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 15 Sep 2021 06:15:45 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class
In-Reply-To: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
Message-ID: <Ht9Gm3WsppjbVjRYmskifu75N6j0rAb_7zHj8y1F6wg=.b5bafc23-9f64-4cfd-a1d6-9e7bed8c48e8@github.com>

On Wed, 15 Sep 2021 05:52:54 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
> 
> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
> 
> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
> 
> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.

test/jdk/sun/awt/font/CheckFontManagerSystemProperty.java line 33:

> 31: 
> 32:     public static void main(String[] args) {
> 33:         String tkProp = System.getProperty("sun.font.fontmanage");

Should it not be sun.font.fontmanager?

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

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


From alexsch at openjdk.java.net  Wed Sep 15 07:00:27 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Wed, 15 Sep 2021 07:00:27 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v2]
In-Reply-To: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
Message-ID: <ukfit-uRznmsuu89ydT2ez8_YpUaat9WY7qwDnmfTjY=.a45948f8-c67e-4422-9dfe-676153505ef9@github.com>

> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
> 
> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
> 
> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
> 
> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.

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

  Fix typo in sun.font.fontmanager property name. Load AWT lib in test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5517/files
  - new: https://git.openjdk.java.net/jdk/pull/5517/files/ea68ebc5..8791b57d

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

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

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


From alexsch at openjdk.java.net  Wed Sep 15 07:00:30 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Wed, 15 Sep 2021 07:00:30 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v2]
In-Reply-To: <Ht9Gm3WsppjbVjRYmskifu75N6j0rAb_7zHj8y1F6wg=.b5bafc23-9f64-4cfd-a1d6-9e7bed8c48e8@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <Ht9Gm3WsppjbVjRYmskifu75N6j0rAb_7zHj8y1F6wg=.b5bafc23-9f64-4cfd-a1d6-9e7bed8c48e8@github.com>
Message-ID: <yDDju4HErn4FvPqzhRmconzkN1xjNAT35kj65AcShBo=.a741bbd1-f4d9-4db6-95a0-972a26df2a7b@github.com>

On Wed, 15 Sep 2021 06:12:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in sun.font.fontmanager property name. Load AWT lib in test
>
> test/jdk/sun/awt/font/CheckFontManagerSystemProperty.java line 33:
> 
>> 31: 
>> 32:     public static void main(String[] args) {
>> 33:         String tkProp = System.getProperty("sun.font.fontmanage");
> 
> Should it not be sun.font.fontmanager?

Yes, thank you. I updated the the `sun.font.fontmanager` property name in the test and added code that gets Toolkit to force AWT library loading.

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

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


From psadhukhan at openjdk.java.net  Wed Sep 15 07:20:52 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 15 Sep 2021 07:20:52 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v2]
In-Reply-To: <ukfit-uRznmsuu89ydT2ez8_YpUaat9WY7qwDnmfTjY=.a45948f8-c67e-4422-9dfe-676153505ef9@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <ukfit-uRznmsuu89ydT2ez8_YpUaat9WY7qwDnmfTjY=.a45948f8-c67e-4422-9dfe-676153505ef9@github.com>
Message-ID: <Lo0TgJ-0fnYT2b5xmeilUooCrJESWjpl3RQJdD-Z6Pc=.5c86e9ae-5727-43ee-a907-c19b3dd717f6@github.com>

On Wed, 15 Sep 2021 07:00:27 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in sun.font.fontmanager property name. Load AWT lib in test

I guess since "sun.font.fontmanager" property is removed, it will need csr just as the other 2 issues.

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

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


From pbansal at openjdk.java.net  Wed Sep 15 07:45:56 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 15 Sep 2021 07:45:56 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v2]
In-Reply-To: <ML-6qoWxRsMUttXmsTygOb_iMz3MrHsFAxrjaoHJGp8=.0ab16e40-05ef-442d-8c0b-3976e6db8867@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <ML-6qoWxRsMUttXmsTygOb_iMz3MrHsFAxrjaoHJGp8=.0ab16e40-05ef-442d-8c0b-3976e6db8867@github.com>
Message-ID: <CuK41rhNvK3zkYmV-6BDAKCVcs1UedtxYSkE3eSEON0=.4a43288c-6d00-441e-a4c3-748a23fb8501@github.com>

On Tue, 14 Sep 2021 22:05:56 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added bug ID to test

test/jdk/java/awt/event/MouseEvent/ResizeMouseExitEnterMisfire/ResizeMouseExitEnterMisfire.java line 61:

> 59:             public void run() {
> 60:                 frame = new JFrame();
> 61:                 frame.setSize(200, 200);

It is preferred to move the frame to centre of screen by calling frame.setLocationRelativeTo(null)

test/jdk/java/awt/event/MouseEvent/ResizeMouseExitEnterMisfire/ResizeMouseExitEnterMisfire.java line 175:

> 173:         test.resizeFromOutsideWindowTest();
> 174:     }
> 175: }

Please dispose the frame after the test is completed. Add a new line at EOF.

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Wed Sep 15 08:04:47 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Wed, 15 Sep 2021 08:04:47 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v2]
In-Reply-To: <dI6yKxvCy5qLDu1gxGqBAMrF3CvPrG63EuoMTz-IOkQ=.eac5d915-1012-4601-a7a3-1d6d02faba32@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <ML-6qoWxRsMUttXmsTygOb_iMz3MrHsFAxrjaoHJGp8=.0ab16e40-05ef-442d-8c0b-3976e6db8867@github.com>
 <dI6yKxvCy5qLDu1gxGqBAMrF3CvPrG63EuoMTz-IOkQ=.eac5d915-1012-4601-a7a3-1d6d02faba32@github.com>
Message-ID: <4kOBKoobSUazyJTehwnMVpCDjOc91VtYHAP_Thx4n6w=.ef2b8349-2cae-4f01-9a5a-90ed8b73edf2@github.com>

On Wed, 15 Sep 2021 04:18:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> But the question is it really a problem of slow window, or may be we have some bug in the nativeSynthesizeMouseEnteredExitedEvents where we synthesize such events when we should not.

I think we don't synthesize these events, they come from native.

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Wed Sep 15 08:18:55 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Wed, 15 Sep 2021 08:18:55 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v2]
In-Reply-To: <dI6yKxvCy5qLDu1gxGqBAMrF3CvPrG63EuoMTz-IOkQ=.eac5d915-1012-4601-a7a3-1d6d02faba32@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <ML-6qoWxRsMUttXmsTygOb_iMz3MrHsFAxrjaoHJGp8=.0ab16e40-05ef-442d-8c0b-3976e6db8867@github.com>
 <dI6yKxvCy5qLDu1gxGqBAMrF3CvPrG63EuoMTz-IOkQ=.eac5d915-1012-4601-a7a3-1d6d02faba32@github.com>
Message-ID: <Lgle9DenSaP8ZUHmgasNPuyJeXbzSwJhQVfMthod5ro=.3fa96680-3bff-4df3-9d3e-2963fbed5b3e@github.com>

On Wed, 15 Sep 2021 04:18:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I have a general question about this bug, initially the test was added for https://bugs.openjdk.java.net/browse/JDK-6479820 and that bug was fixed because of this:
> 
> ```
> When resizing the window by dragging a corner with the mouse,
> the panel receives entry/exit mouse events randomly.
> These events should not occur because the mouse is not entering
> or exiting the window, it is dragging a corner of its border.
> ```
> 
> And in the current bug description:
> 
> `The window resizing is a bit slower than mouse movement. So before the window resize can catch up to the mouse, the mouse exits the window, then re-enters when the window catches up to it. This can be verified if you resize the window at the edge without entering the window: there will be no mouseEntered or mouseExit events. `
> 
> So situation is different, if the mouse is moved faster than window is moving, then I do not see why we should not post an events. Especially if the native system did that.

In the original bug report, I believe the root cause of the bug is the same based on the comment in JBS:
`So far this happens when system is not fast enough to resize native component in a short period of time while message is on its way.`

And I tried to keep the same idea for the fix in windows:
`The idea of the fix would be to pick up AwtWindow.m_resizing value and not consider any messages in PreProcessMouseMsg until m_resizing is true.`

So I guess the question is whether or not we should be posting these events in the first place during resizing? I still see the original bug fix in the windows files so I believe there currently is a mismatch in behavior across platforms.

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

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


From alexander.scherbatiy at bell-sw.com  Wed Sep 15 08:21:39 2021
From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy)
Date: Wed, 15 Sep 2021 11:21:39 +0300
Subject: Reflection usage in LazyPainter class
Message-ID: <952be87d-3398-c7e1-5619-4bea14a8b386@bell-sw.com>

Hello,

LazyPainter class from Defaults.template uses reflection to create a 
Painter classes [1].

There are some fixes which replace LazyValue with lambdas [2], [3]:
 ? 8039750: KSS: Replace MetalLazyValue with lambda
 ? 8035313: Change SwingLazyValue usage to lambda

Would it be useful to get rid of reflection in LazyPainter as well?

It looks like LazyPainter can't be directly converted to Lambda.
It stores PaintContext during createValue(...) calls.
And it can use a custom class loader which it gets from UIDefaults by 
"ClassLoader" key.

May be LazyPainter can check if a class loader from UIDefaults is null 
and create a Painter class directly
in this case just mapping a class string to corresponding object 
creation code like:

 ??? private static AbstractRegionPainter createPainter(
 ??????????? String className, AbstractRegionPainter.PaintContext ctx, 
int which) {
 ??????? switch (className) {
 ??????????? case "javax.swing.plaf.nimbus.ScrollPanePainter":
 ??????????????? return new 
javax.swing.plaf.nimbus.ScrollPanePainter(ctx, which);
 ??????????? case "javax.swing.plaf.nimbus.InternalFramePainter":
 ??????????????? return new 
javax.swing.plaf.nimbus.InternalFramePainter(ctx, which);
 ??????????? ...
 ??????? }
 ??? }

[1] 
https://github.com/openjdk/jdk/blob/febcc72a549e973de4649503fc686fc520e3b3cd/src/java.desktop/share/classes/javax/swing/plaf/nimbus/Defaults.template#L414
[2] 
https://github.com/openjdk/jdk/commit/717bcde5f3596b695100de468c352617625c17cc
[3] 
https://github.com/openjdk/jdk/commit/c8ad756ad83c7af296ce2b621be12ed7a9d23f6e

Thanks,
Alexander.



From github.com+90066231+alisenchung at openjdk.java.net  Wed Sep 15 08:24:52 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Wed, 15 Sep 2021 08:24:52 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v2]
In-Reply-To: <CuK41rhNvK3zkYmV-6BDAKCVcs1UedtxYSkE3eSEON0=.4a43288c-6d00-441e-a4c3-748a23fb8501@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <ML-6qoWxRsMUttXmsTygOb_iMz3MrHsFAxrjaoHJGp8=.0ab16e40-05ef-442d-8c0b-3976e6db8867@github.com>
 <CuK41rhNvK3zkYmV-6BDAKCVcs1UedtxYSkE3eSEON0=.4a43288c-6d00-441e-a4c3-748a23fb8501@github.com>
Message-ID: <UJxt9hV1vj20vdhvr1UfU4SNafbVXNVr5a7SuXwH0as=.998fc44d-e26f-49d1-9a8a-4c2f60092756@github.com>

On Wed, 15 Sep 2021 07:42:40 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added bug ID to test
>
> test/jdk/java/awt/event/MouseEvent/ResizeMouseExitEnterMisfire/ResizeMouseExitEnterMisfire.java line 61:
> 
>> 59:             public void run() {
>> 60:                 frame = new JFrame();
>> 61:                 frame.setSize(200, 200);
> 
> It is preferred to move the frame to centre of screen by calling frame.setLocationRelativeTo(null)

I use the frame size to find the correct location of the mouse for robot, so moving the frame to the center of the screen would make calculating mouse locations more complicated...
And I need some space to expand the window, which could be limited if the frame were to be in the center, so in this case it's probably better to keep the window in the top left corner? Unless there's a reasoning I missed for moving it to the center?

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

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


From github.com+741251+turbanoff at openjdk.java.net  Wed Sep 15 10:56:43 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 15 Sep 2021 10:56:43 GMT
Subject: RFR: 8273684: Unnecessary Stack usage
In-Reply-To: <9vilIHa165Q92J0ud-xeeaPbH1zQnRA-42mG_czCPUg=.0ddaacd4-36cf-4a59-bfee-a88a39232bd3@github.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
 <9vilIHa165Q92J0ud-xeeaPbH1zQnRA-42mG_czCPUg=.0ddaacd4-36cf-4a59-bfee-a88a39232bd3@github.com>
Message-ID: <54QW-51jdadjUSBgt-feDIrjaIXbLD020sJALCxgF2w=.80699bae-36ac-453a-b576-db85e13b1ce7@github.com>

On Tue, 14 Sep 2021 17:52:03 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Usage of thread-safe collection Stack is unnecessary. It's recommended to use ArrayDequeue if a thread-safe implementation is not needed.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java line 988:
> 
>> 986:                 // Make sure the types are emitted in an order than can be read back in
>> 987:                 HashSet<String> emitted = new HashSet<>();
>> 988:                 ArrayDeque<Type> pending = new ArrayDeque<>();
> 
> Have you run the clhsdb vmstructsdump command to make sure the ordering hasn't changed?

Checked.
Ordering is the same.
![???????????](https://user-images.githubusercontent.com/741251/133420954-67404798-b56d-4d6f-98ee-c457622d58f4.png)

[with_fixes_java_vmstructsdump.txt](https://github.com/openjdk/jdk/files/7169440/with_fixes_java_vmstructsdump.txt)
[without_fixes_java_vmstructsdump.txt](https://github.com/openjdk/jdk/files/7169441/without_fixes_java_vmstructsdump.txt)

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

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


From mbaesken at openjdk.java.net  Wed Sep 15 11:55:59 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 15 Sep 2021 11:55:59 GMT
Subject: RFR: JDK-8273808: Cleanup AddFontsToX11FontPath
Message-ID: <0Mp0CwAIoz3Vn7nDKZqAtcK4WIRJejKZSXNtGc_rJz8=.c8cdbb21-351e-4f9a-a2d3-7d90ff7ee6f0@github.com>

Hello please review this small cleanup change.  Seems AddFontsToX11FontPath from fontpath.c is unused/unreferenced and can be removed.

Thanks, Matthias

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

Commit messages:
 - JDK-8273808

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

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


From prr at openjdk.java.net  Wed Sep 15 14:04:51 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 15 Sep 2021 14:04:51 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v2]
In-Reply-To: <ukfit-uRznmsuu89ydT2ez8_YpUaat9WY7qwDnmfTjY=.a45948f8-c67e-4422-9dfe-676153505ef9@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <ukfit-uRznmsuu89ydT2ez8_YpUaat9WY7qwDnmfTjY=.a45948f8-c67e-4422-9dfe-676153505ef9@github.com>
Message-ID: <TGfbXGF7ugMQaD7PFzZmSk4w9T6XuFghlCXwY9EQR_M=.71780a08-4954-4282-b237-9d5e46458f7b@github.com>

On Wed, 15 Sep 2021 07:00:27 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in sun.font.fontmanager property name. Load AWT lib in test

So it is supposed to be a singleton and that was more strongly enforced in the old code.
Now you have a public per-platform method createFontManager() which always returns a new one.
At the very least I think you shuld make that package protected (it is only accessed from sun.awt, isn't it ?)
and add comments that the method is only to be called via the factory method.

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

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


From shade at openjdk.java.net  Wed Sep 15 14:25:09 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 15 Sep 2021 14:25:09 GMT
Subject: RFR: 8273821: Limit parallelism for sanity/client/SwingSet tests
Message-ID: <m5LUIlpQozmWLFepnVYRhcAXy0aEaJkmlupF3p5sC1A=.d91299d5-d870-4499-9c3b-0388bf1b2d9b@github.com>

If you run them today on a parallel machine with the usual invocation:

$ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/client/SwingSet/

...then a whole lot of these tests would fail. It seems to be caused by the overlapping GUI windows that robots fail to reach properly then. It seems these tests need to be run exclusively. 

@mrserb, maybe I am missing something? How do you run these tests? 

Additional testing:
 - [x] `sanity/client/SwingSet/` tests now pass on TR 3970X

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

Commit messages:
 - Fix

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Wed Sep 15 14:42:19 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Wed, 15 Sep 2021 14:42:19 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v3]
In-Reply-To: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
Message-ID: <YnkE51JvQLUQ5pcBJn3sJJJTUoFQ1w82-nx9Xpz382Y=.815d763c-baf9-4b9c-abd6-e15fe22efa00@github.com>

> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.

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

  updated test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5497/files
  - new: https://git.openjdk.java.net/jdk/pull/5497/files/f455df82..acbf7984

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

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

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


From aivanov at openjdk.java.net  Wed Sep 15 15:32:47 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 15 Sep 2021 15:32:47 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTexTAndGraphicsState.java [v2]
In-Reply-To: <TdctZLjCnE9j7nwSNF58kdpa_Q9NxzmOSZSiqU3GCW4=.5cba103a-c9d9-4960-9bea-6be6824afed4@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
 <TdctZLjCnE9j7nwSNF58kdpa_Q9NxzmOSZSiqU3GCW4=.5cba103a-c9d9-4960-9bea-6be6824afed4@github.com>
Message-ID: <s_84IuP3_Qd9oDHWeWMuKP7FA3_ZdjvwqViEvSt9BVo=.f500d4d6-5b4d-4f4e-a692-4e29388c672c@github.com>

On Tue, 14 Sep 2021 00:10:26 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

>> Problem : 
>> 1) Test case was failing with following exception
>> test result: Error. Parse Exception: Arguments to `manual' option not supported: yes 
>> 2) After removing =yes/no Parser exception is not seen but test UI will show and closes immediately  where the user cannot see what is on the frame. 
>> 
>> Fix : 
>> 1) Add frame to show the test instructions.
>> 2) Added timeout for the test case.
>> 3) Show the test UI until either test case gets timeout or user press pass or fail button.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed minor issue

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 59:

> 57: 
> 58:     private static final Frame instructionFrame = new Frame();
> 59:     private static volatile boolean testResult = false;

Assigning the default value is redundant.

test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 60:

> 58:     private static final Frame instructionFrame = new Frame();
> 59:     private static volatile boolean testResult = false;
> 60:     private static volatile CountDownLatch countDownLatch;

It could be `final` and could be initialised here rather than in main.

test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 61:

> 59:     private static volatile boolean testResult = false;
> 60:     private static volatile CountDownLatch countDownLatch;
> 61:     private static String text = "This test passes only if this text appears SIX TIMES";

Could be declared `final`.

test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 79:

> 77:         Graphics2D g2d = (Graphics2D) g;
> 78:         g2d.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
> 79:                 RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB);

I'd rather keep them aligned as they were. I'm fine with reformatting, though. Both variants are acceptable and there's no strong preference to either in JDK code as far as I'm aware.

test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 114:

> 112: 
> 113:     private static void createInstructionUI() {
> 114:         GridBagLayout layout = new GridBagLayout();

I believe the UI layout could be simplified by using `BorderLayout`, the default for `Frame`, where textArea is placed as `BorderLayout.CENTER` and button panel (with BoxLayout or FlowLayout) is placed as `BorderLayout.SOUTH`.

It's just a tip. The layout works; don't fix it if it's not broken.

test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 137:

> 135: 
> 136:         Button failButton = new Button("Fail");
> 137:         failButton.setActionCommand("Fail");

You don't use action command, so it's somewhat redundant.

test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 162:

> 160:             }
> 161:         });
> 162:         instructionFrame.pack();

`pack()` is called twice.

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

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


From aivanov at openjdk.java.net  Wed Sep 15 15:59:57 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 15 Sep 2021 15:59:57 GMT
Subject: RFR: 8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java
 does not show instruction
In-Reply-To: <Hkt7teFERu0--geMSLbOQchV2WAhukLbTNm9l3oEw64=.70f6bb1d-6121-4fc1-ab1f-462d74e9aa68@github.com>
References: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
 <Hkt7teFERu0--geMSLbOQchV2WAhukLbTNm9l3oEw64=.70f6bb1d-6121-4fc1-ab1f-462d74e9aa68@github.com>
Message-ID: <8VTYONkzL7EbEk4b0MucpPZw7YrmD3aa3sr8jXXGrlE=.e9896a8d-98be-4ff4-bcdb-e0e5ee9c9bb7@github.com>

On Tue, 14 Sep 2021 18:37:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Is it possible to complete the test as soon as either OK or Cancel button is clicked on the Print dialog?

The `init()` method is run on main thread. It's the thread which creates the Print Dialog. If the user clicks Cancel, the `job.printDialog()` returns `false` and the test should fail.

Then if the `job.getCopies() == 1`, the test also fails with the message that the number of copies wasn't increased.

If `job.getCopies() > 1`, the test passes automatically.


There's one thing though? I don't have a real printer installed but I have a PDF printer which doesn't allow increasing the number of copies. What should the test do in this case? If I click OK without modifying the number of copies, the test will fail; if I click Cancel, the test will also fail. However, this particular case falls into a category where the prerequisites aren't met.

Probably, the standard machinery with `Sysout` is an overkill for this simple scenario. You could show the instruction frame with only the text area which contains the instruction text.

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

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


From cjplummer at openjdk.java.net  Wed Sep 15 16:31:54 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 15 Sep 2021 16:31:54 GMT
Subject: RFR: 8273684: Unnecessary Stack usage
In-Reply-To: <54QW-51jdadjUSBgt-feDIrjaIXbLD020sJALCxgF2w=.80699bae-36ac-453a-b576-db85e13b1ce7@github.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
 <9vilIHa165Q92J0ud-xeeaPbH1zQnRA-42mG_czCPUg=.0ddaacd4-36cf-4a59-bfee-a88a39232bd3@github.com>
 <54QW-51jdadjUSBgt-feDIrjaIXbLD020sJALCxgF2w=.80699bae-36ac-453a-b576-db85e13b1ce7@github.com>
Message-ID: <mBL-vzzPLXhNQ59XzP4CtAA_8Wm_u_NtiQPqdLQsY9A=.608f9935-d9a3-46cb-aecc-2aaa34d50571@github.com>

On Wed, 15 Sep 2021 10:53:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java line 988:
>> 
>>> 986:                 // Make sure the types are emitted in an order than can be read back in
>>> 987:                 HashSet<String> emitted = new HashSet<>();
>>> 988:                 ArrayDeque<Type> pending = new ArrayDeque<>();
>> 
>> Have you run the clhsdb vmstructsdump command to make sure the ordering hasn't changed?
>
> Checked.
> Ordering is the same.
> ![???????????](https://user-images.githubusercontent.com/741251/133420954-67404798-b56d-4d6f-98ee-c457622d58f4.png)
> 
> [with_fixes_java_vmstructsdump.txt](https://github.com/openjdk/jdk/files/7169440/with_fixes_java_vmstructsdump.txt)
> [without_fixes_java_vmstructsdump.txt](https://github.com/openjdk/jdk/files/7169441/without_fixes_java_vmstructsdump.txt)

There is something wrong with the version of jhsdb you are running. It appears to be an old version, not the latest. You should not be seeing the following warning. The code that produces it is not even present in the latest jdk.
`Warning: Nashorn engine is planned to be removed from a future JDK release`

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

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


From github.com+741251+turbanoff at openjdk.java.net  Wed Sep 15 16:37:44 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 15 Sep 2021 16:37:44 GMT
Subject: RFR: 8273684: Unnecessary Stack usage
In-Reply-To: <mBL-vzzPLXhNQ59XzP4CtAA_8Wm_u_NtiQPqdLQsY9A=.608f9935-d9a3-46cb-aecc-2aaa34d50571@github.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
 <9vilIHa165Q92J0ud-xeeaPbH1zQnRA-42mG_czCPUg=.0ddaacd4-36cf-4a59-bfee-a88a39232bd3@github.com>
 <54QW-51jdadjUSBgt-feDIrjaIXbLD020sJALCxgF2w=.80699bae-36ac-453a-b576-db85e13b1ce7@github.com>
 <mBL-vzzPLXhNQ59XzP4CtAA_8Wm_u_NtiQPqdLQsY9A=.608f9935-d9a3-46cb-aecc-2aaa34d50571@github.com>
Message-ID: <sHVbhZaH754OdVPTsFAZrn7Mrq_lNZrEnAWwOYw2T14=.5757856f-390c-438a-a058-305dc8d50c2f@github.com>

On Wed, 15 Sep 2021 16:28:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Checked.
>> Ordering is the same.
>> ![???????????](https://user-images.githubusercontent.com/741251/133420954-67404798-b56d-4d6f-98ee-c457622d58f4.png)
>> 
>> [with_fixes_java_vmstructsdump.txt](https://github.com/openjdk/jdk/files/7169440/with_fixes_java_vmstructsdump.txt)
>> [without_fixes_java_vmstructsdump.txt](https://github.com/openjdk/jdk/files/7169441/without_fixes_java_vmstructsdump.txt)
>
> There is something wrong with the version of jhsdb you are running. It appears to be an old version, not the latest. You should not be seeing the following warning. The code that produces it is not even present in the latest jdk.
> `Warning: Nashorn engine is planned to be removed from a future JDK release`

I wondered about this too. Perhaps this messages coming from the _target JDK_ which I'm attached too?
I attached to my IntelliJ IDEA process. It uses JDK 11.

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

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


From cjplummer at openjdk.java.net  Wed Sep 15 16:45:47 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 15 Sep 2021 16:45:47 GMT
Subject: RFR: 8273684: Unnecessary Stack usage
In-Reply-To: <sHVbhZaH754OdVPTsFAZrn7Mrq_lNZrEnAWwOYw2T14=.5757856f-390c-438a-a058-305dc8d50c2f@github.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
 <9vilIHa165Q92J0ud-xeeaPbH1zQnRA-42mG_czCPUg=.0ddaacd4-36cf-4a59-bfee-a88a39232bd3@github.com>
 <54QW-51jdadjUSBgt-feDIrjaIXbLD020sJALCxgF2w=.80699bae-36ac-453a-b576-db85e13b1ce7@github.com>
 <mBL-vzzPLXhNQ59XzP4CtAA_8Wm_u_NtiQPqdLQsY9A=.608f9935-d9a3-46cb-aecc-2aaa34d50571@github.com>
 <sHVbhZaH754OdVPTsFAZrn7Mrq_lNZrEnAWwOYw2T14=.5757856f-390c-438a-a058-305dc8d50c2f@github.com>
Message-ID: <zwEzS1jroOcc7A3jq3mpEaZVRjPXTjPE7pb2SXKBO8M=.8e2587db-bae5-42b0-8966-08dedfbb8c74@github.com>

On Wed, 15 Sep 2021 16:34:51 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> There is something wrong with the version of jhsdb you are running. It appears to be an old version, not the latest. You should not be seeing the following warning. The code that produces it is not even present in the latest jdk.
>> `Warning: Nashorn engine is planned to be removed from a future JDK release`
>
> I wondered about this too. Perhaps this messages coming from the _target JDK_ which I'm attached too?
> I attached to my IntelliJ IDEA process. It uses JDK 11.

SA doesn't doesn't run any code on the target.

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Wed Sep 15 16:58:50 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Wed, 15 Sep 2021 16:58:50 GMT
Subject: RFR: 8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java
 does not show instruction
In-Reply-To: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
References: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
Message-ID: <3pG4uRgsLYMqL0wrNikPJC1zj-eVY4zUInejzYX8ey8=.d3b82cda-0122-4fc5-88c0-ef571eb158b6@github.com>

On Tue, 20 Jul 2021 23:54:20 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

> 1) When the test is executed via jtreg user can see only print dialog with no instruction to the user. User has to see the test case to see the instruction and perform the test . 
> 2) With this fix User is instructed what he/she has to do with the print dialog.
> 3) I have added both success instruction as well as failure instruction.
> 
> @shurymury

I rewrote the test case to close the test ui if user click the OK or Cancel button & check for job.getCopies() value and make the testcase pass or fail. 
You are right even I have the same issue in deciding whether to make the test case pass or fail if prerequisites aren't met.  I hope all the client test machines are configured with printer.
Yes, Sysout is overkill, I am working just to show the test instruction in an frame & printDialog.

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

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


From cjplummer at openjdk.java.net  Wed Sep 15 17:06:54 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 15 Sep 2021 17:06:54 GMT
Subject: RFR: 8273684: Unnecessary Stack usage
In-Reply-To: <zwEzS1jroOcc7A3jq3mpEaZVRjPXTjPE7pb2SXKBO8M=.8e2587db-bae5-42b0-8966-08dedfbb8c74@github.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
 <9vilIHa165Q92J0ud-xeeaPbH1zQnRA-42mG_czCPUg=.0ddaacd4-36cf-4a59-bfee-a88a39232bd3@github.com>
 <54QW-51jdadjUSBgt-feDIrjaIXbLD020sJALCxgF2w=.80699bae-36ac-453a-b576-db85e13b1ce7@github.com>
 <mBL-vzzPLXhNQ59XzP4CtAA_8Wm_u_NtiQPqdLQsY9A=.608f9935-d9a3-46cb-aecc-2aaa34d50571@github.com>
 <sHVbhZaH754OdVPTsFAZrn7Mrq_lNZrEnAWwOYw2T14=.5757856f-390c-438a-a058-305dc8d50c2f@github.com>
 <zwEzS1jroOcc7A3jq3mpEaZVRjPXTjPE7pb2SXKBO8M=.8e2587db-bae5-42b0-8966-08dedfbb8c74@github.com>
Message-ID: <2g1w7ZQfAb9OW9k8GE02y10Pzf7bhNjv3B4Nc2yeMvs=.b1a3f246-e634-433c-8545-25763c10d916@github.com>

On Wed, 15 Sep 2021 16:42:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I wondered about this too. Perhaps this messages coming from the _target JDK_ which I'm attached too?
>> I attached to my IntelliJ IDEA process. It uses JDK 11.
>
> SA doesn't doesn't run any code on the target.

I wonder if you are exporting CLASSPATH and that is causing `jhsdb` to pick up the wrong SA implementation.

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

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


From philip.race at oracle.com  Wed Sep 15 18:05:09 2021
From: philip.race at oracle.com (Philip Race)
Date: Wed, 15 Sep 2021 11:05:09 -0700
Subject: Retiring 2d, awt, beans, sound and swing mailing lists on 30th
 September 2021
Message-ID: <a7877f2d-1498-575b-dc70-827996025650@oracle.com>

Since :
1) The old client groups mailing lists were consolidated into 
client-libs-dev at openjdk dot java dot net [1],
including subscribing all subscribers to the old invividual lists to the 
new consolidated list, and
2) The skara github tooling has also migrated to that new list and
3) Folks are already using the new list for questions etc

Then :
I think it is time to plan the retirement of all the old lists :
2d-dev [2], awt-dev [3], beans-dev [4], sound-dev [5], and swing-dev [6]

Accordingly I propose that these five old lists become archived and 
read-only as of 12pm PDT 30th September 2021
and will ask the mail server adminstrators to plan to implement this at 
that time.

I will also forward this information to each of those individual lists.

-Phil Race
Client Libs Group Lead.

[1] https://mail.openjdk.java.net/mailman/listinfo/client-libs-dev
[2] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
[3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
[4] https://mail.openjdk.java.net/mailman/listinfo/beans-dev
[5] https://mail.openjdk.java.net/mailman/listinfo/sound-dev
[6] https://mail.openjdk.java.net/mailman/listinfo/swing-dev





From github.com+741251+turbanoff at openjdk.java.net  Wed Sep 15 18:29:49 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 15 Sep 2021 18:29:49 GMT
Subject: RFR: 8273684: Unnecessary Stack usage
In-Reply-To: <2g1w7ZQfAb9OW9k8GE02y10Pzf7bhNjv3B4Nc2yeMvs=.b1a3f246-e634-433c-8545-25763c10d916@github.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
 <9vilIHa165Q92J0ud-xeeaPbH1zQnRA-42mG_czCPUg=.0ddaacd4-36cf-4a59-bfee-a88a39232bd3@github.com>
 <54QW-51jdadjUSBgt-feDIrjaIXbLD020sJALCxgF2w=.80699bae-36ac-453a-b576-db85e13b1ce7@github.com>
 <mBL-vzzPLXhNQ59XzP4CtAA_8Wm_u_NtiQPqdLQsY9A=.608f9935-d9a3-46cb-aecc-2aaa34d50571@github.com>
 <sHVbhZaH754OdVPTsFAZrn7Mrq_lNZrEnAWwOYw2T14=.5757856f-390c-438a-a058-305dc8d50c2f@github.com>
 <zwEzS1jroOcc7A3jq3mpEaZVRjPXTjPE7pb2SXKBO8M=.8e2587db-bae5-42b0-8966-08dedfbb8c74@github.com>
 <2g1w7ZQfAb9OW9k8GE02y10Pzf7bhNjv3B4Nc2yeMvs=.b1a3f246-e634-433c-8545-25763c10d916@github.com>
Message-ID: <GnS-DcJ_K79_vAhn5l5dvc8aA_if3dLtPkR4TBdVEKk=.421182e0-4cc8-4e46-804a-7f9bbe4933d4@github.com>

On Wed, 15 Sep 2021 17:03:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SA doesn't doesn't run any code on the target.
>
> I wonder if you are exporting CLASSPATH and that is causing `jhsdb` to pick up the wrong SA implementation.

Rechecked again.
Now without involving IDEA. Just started small java program and then attached.
Then checkouted revision before my commits (a9188f237ec) and rebuild and repeated.
![???????????](https://user-images.githubusercontent.com/741251/133488878-fa93b973-5dba-4aa6-95bc-07edb177b3fc.png)

[with_fixes_java_vmstructsdump.txt](https://github.com/openjdk/jdk/files/7172443/with_fixes_java_vmstructsdump.txt)
[without_fixes_java_vmstructsdump.txt](https://github.com/openjdk/jdk/files/7172444/without_fixes_java_vmstructsdump.txt)

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

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


From cjplummer at openjdk.java.net  Wed Sep 15 18:39:52 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 15 Sep 2021 18:39:52 GMT
Subject: RFR: 8273684: Unnecessary Stack usage
In-Reply-To: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
Message-ID: <ImbV0RniKvfCjCZCYiPTASjTyW1txbM-hp1VYOxDQ-k=.3ac14030-fdcb-4ff1-b5bb-822ef2f6306a@github.com>

On Sun, 29 Aug 2021 21:14:19 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Usage of thread-safe collection Stack is unnecessary. It's recommended to use ArrayDequeue if a thread-safe implementation is not needed.

Marked as reviewed by cjplummer (Reviewer).

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

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


From cjplummer at openjdk.java.net  Wed Sep 15 18:39:52 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 15 Sep 2021 18:39:52 GMT
Subject: RFR: 8273684: Unnecessary Stack usage
In-Reply-To: <GnS-DcJ_K79_vAhn5l5dvc8aA_if3dLtPkR4TBdVEKk=.421182e0-4cc8-4e46-804a-7f9bbe4933d4@github.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
 <9vilIHa165Q92J0ud-xeeaPbH1zQnRA-42mG_czCPUg=.0ddaacd4-36cf-4a59-bfee-a88a39232bd3@github.com>
 <54QW-51jdadjUSBgt-feDIrjaIXbLD020sJALCxgF2w=.80699bae-36ac-453a-b576-db85e13b1ce7@github.com>
 <mBL-vzzPLXhNQ59XzP4CtAA_8Wm_u_NtiQPqdLQsY9A=.608f9935-d9a3-46cb-aecc-2aaa34d50571@github.com>
 <sHVbhZaH754OdVPTsFAZrn7Mrq_lNZrEnAWwOYw2T14=.5757856f-390c-438a-a058-305dc8d50c2f@github.com>
 <zwEzS1jroOcc7A3jq3mpEaZVRjPXTjPE7pb2SXKBO8M=.8e2587db-bae5-42b0-8966-08dedfbb8c74@github.com>
 <2g1w7ZQfAb9OW9k8GE02y10Pzf7bhNjv3B4Nc2yeMvs=.b1a3f246-e634-433c-8545-25763c10d916@github.com>
 <GnS-DcJ_K79_vAhn5l5dvc8aA_if3dLtPkR4TBdVEKk=.421182e0-4cc8-4e46-804a-7f9bbe4933d4@github.com>
Message-ID: <zwFhl3Jcs5YXIPI-_ZhNIA4ajCsBJKsIQ5XI5IQRar8=.18684fca-5719-4ab0-8e8e-48b5f4035c42@github.com>

On Wed, 15 Sep 2021 18:27:05 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> I wonder if you are exporting CLASSPATH and that is causing `jhsdb` to pick up the wrong SA implementation.
>
> Rechecked again.
> Now without involving IDEA. Just started small java program and then attached.
> Then checkouted revision before my commits (a9188f237ec) and rebuild and repeated.
> ![???????????](https://user-images.githubusercontent.com/741251/133488878-fa93b973-5dba-4aa6-95bc-07edb177b3fc.png)
> 
> [with_fixes_java_vmstructsdump.txt](https://github.com/openjdk/jdk/files/7172443/with_fixes_java_vmstructsdump.txt)
> [without_fixes_java_vmstructsdump.txt](https://github.com/openjdk/jdk/files/7172444/without_fixes_java_vmstructsdump.txt)

Ok, looks good. You can consider the SA changes reviewed.

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

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


From serb at openjdk.java.net  Wed Sep 15 18:43:53 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Sep 2021 18:43:53 GMT
Subject: RFR: 8273821: Limit parallelism for sanity/client/SwingSet tests
In-Reply-To: <m5LUIlpQozmWLFepnVYRhcAXy0aEaJkmlupF3p5sC1A=.d91299d5-d870-4499-9c3b-0388bf1b2d9b@github.com>
References: <m5LUIlpQozmWLFepnVYRhcAXy0aEaJkmlupF3p5sC1A=.d91299d5-d870-4499-9c3b-0388bf1b2d9b@github.com>
Message-ID: <FVpO-xhTgQzXi_YK0iktGciJCp8uR3edkucJiynP4LM=.a8a1f0ad-7c48-4e99-81c4-902148538023@github.com>

On Wed, 15 Sep 2021 14:18:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> If you run them today on a parallel machine with the usual invocation:
> 
> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/client/SwingSet/
> 
> ...then a whole lot of these tests would fail. It seems to be caused by the overlapping GUI windows that robots fail to reach properly then. It seems these tests need to be run exclusively. 
> 
> @mrserb, maybe I am missing something? How do you run these tests? 
> 
> Additional testing:
>  - [x] `sanity/client/SwingSet/` tests now pass on TR 3970X

This is applicable to all headful tests, at least most of them. You should filter them out when default concurrency is used. And then run only headful test using TEST_JOBS=1

I think there is a bug somewhere to enhance the "exclusiveAccess" option to support the tags, so the real fix should be:
exclusiveAccess.key=headful

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

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


From serb at openjdk.java.net  Wed Sep 15 18:46:50 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Sep 2021 18:46:50 GMT
Subject: RFR: 8273821: Limit parallelism for sanity/client/SwingSet tests
In-Reply-To: <m5LUIlpQozmWLFepnVYRhcAXy0aEaJkmlupF3p5sC1A=.d91299d5-d870-4499-9c3b-0388bf1b2d9b@github.com>
References: <m5LUIlpQozmWLFepnVYRhcAXy0aEaJkmlupF3p5sC1A=.d91299d5-d870-4499-9c3b-0388bf1b2d9b@github.com>
Message-ID: <YH8Su-SJrZ8i3P3TmksEEasMRUeJ6jrjmZYH17FkY2E=.b4d7da37-5764-492c-9d80-8878510ef60f@github.com>

On Wed, 15 Sep 2021 14:18:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> If you run them today on a parallel machine with the usual invocation:
> 
> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/client/SwingSet/
> 
> ...then a whole lot of these tests would fail. It seems to be caused by the overlapping GUI windows that robots fail to reach properly then. It seems these tests need to be run exclusively. 
> 
> @mrserb, maybe I am missing something? How do you run these tests? 
> 
> Additional testing:
>  - [x] `sanity/client/SwingSet/` tests now pass on TR 3970X

Common command line for UI tests is something like this:
make test TEST_JOBS=1 TEST="jtreg:jdk_desktop" JTREG='VERBOSE=summary;KEYWORDS=headful&!printer;RETRY_COUNT=2'

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

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


From andrew at openjdk.java.net  Wed Sep 15 19:47:03 2021
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 15 Sep 2021 19:47:03 GMT
Subject: RFR: 8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on
 Manjaro Linux [v3]
In-Reply-To: <Dd1tpX41xYE43y7GoNxSiApEHoniYEx3YcpbQGCwOmE=.d9146b76-b2e9-4f37-aa4b-b4d7a96c6ba2@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
 <Dd1tpX41xYE43y7GoNxSiApEHoniYEx3YcpbQGCwOmE=.d9146b76-b2e9-4f37-aa4b-b4d7a96c6ba2@github.com>
Message-ID: <Vo5CWeyG6_cBHQXdh2AUv8a2WDJw7ehqITEMW8zW32c=.6476f2ea-c5dc-4d49-b04f-80cbc3177b17@github.com>

On Tue, 16 Mar 2021 16:56:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
>> the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.
>> 
>> I ended up having to go this way because its is the least unsatisfactory solution.
>> I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
>> because too many systems have to old a version of harfbuzz.
>> 
>> This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10
>> 
>> There are couple of incidental fixes in here too
>> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
>> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
>> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

You mention that "too many systems have to old a version of harfbuzz".
Is the required version defined somewhere? There's no check in configure for either a version or a required symbol:
https://github.com/openjdk/jdk/blob/cbffecc61e4a9ac1172926ef4f20d918d73adde9/make/autoconf/lib-bundled.m4#L291

With undefined symbols also being left to runtime (hence why JDK-8272332 doesn't show up during build), it seems this could lead to sporadic runtime failures if OpenJDK is unknowingly built against a harfbuzz that is too old.

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

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


From philip.race at oracle.com  Wed Sep 15 20:12:50 2021
From: philip.race at oracle.com (Philip Race)
Date: Wed, 15 Sep 2021 13:12:50 -0700
Subject: RFR: 8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on
 Manjaro Linux [v3]
In-Reply-To: <Vo5CWeyG6_cBHQXdh2AUv8a2WDJw7ehqITEMW8zW32c=.6476f2ea-c5dc-4d49-b04f-80cbc3177b17@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
 <Dd1tpX41xYE43y7GoNxSiApEHoniYEx3YcpbQGCwOmE=.d9146b76-b2e9-4f37-aa4b-b4d7a96c6ba2@github.com>
 <Vo5CWeyG6_cBHQXdh2AUv8a2WDJw7ehqITEMW8zW32c=.6476f2ea-c5dc-4d49-b04f-80cbc3177b17@github.com>
Message-ID: <ba2bf827-6cf4-eda8-4983-4be340c9f0ec@oracle.com>

You are right there's no check. One could be added by a motivated party ..
The minimum for Linux may be as old as 1.2.3? but safer is 2.3.1 since 
we rely on that for AAT font support.
I can't (quickly) speak to any important bug fixes in later releases we 
may need, just API / functionality.

-phi.

On 9/15/21 12:47 PM, Andrew John Hughes wrote:
> On Tue, 16 Mar 2021 16:56:22 GMT, Phil Race <prr at openjdk.org> wrote:
>
>>>  From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps
>>> the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.
>>>
>>> I ended up having to go this way because its is the least unsatisfactory solution.
>>> I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
>>> because too many systems have to old a version of harfbuzz.
>>>
>>> This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10
>>>
>>> There are couple of incidental fixes in here too
>>> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
>>> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
>>> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502
>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux
> You mention that "too many systems have to old a version of harfbuzz".
> Is the required version defined somewhere? There's no check in configure for either a version or a required symbol:
> https://github.com/openjdk/jdk/blob/cbffecc61e4a9ac1172926ef4f20d918d73adde9/make/autoconf/lib-bundled.m4#L291
>
> With undefined symbols also being left to runtime (hence why JDK-8272332 doesn't show up during build), it seems this could lead to sporadic runtime failures if OpenJDK is unknowingly built against a harfbuzz that is too old.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2982



From github.com+87324768+lawrence-andrew at openjdk.java.net  Wed Sep 15 20:23:24 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Wed, 15 Sep 2021 20:23:24 GMT
Subject: RFR: 8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java
 does not show instruction [v2]
In-Reply-To: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
References: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
Message-ID: <dMEQsiVSGqRUhMomijd0Tau9vD7KmvRh3UxIeCB0pCw=.0ea5f7f4-b5d4-46fe-8528-fb9c4938f47c@github.com>

> 1) When the test is executed via jtreg user can see only print dialog with no instruction to the user. User has to see the test case to see the instruction and perform the test . 
> 2) With this fix User is instructed what he/she has to do with the print dialog.
> 3) I have added both success instruction as well as failure instruction.
> 
> @shurymury

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Close instruction frame if OK/Cancel button is pressed

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4850/files
  - new: https://git.openjdk.java.net/jdk/pull/4850/files/613ae74e..8b5510a0

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

  Stats: 274 lines in 1 file changed: 12 ins; 220 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4850.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4850/head:pull/4850

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


From serb at openjdk.java.net  Thu Sep 16 03:51:49 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 16 Sep 2021 03:51:49 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v2]
In-Reply-To: <Lgle9DenSaP8ZUHmgasNPuyJeXbzSwJhQVfMthod5ro=.3fa96680-3bff-4df3-9d3e-2963fbed5b3e@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <ML-6qoWxRsMUttXmsTygOb_iMz3MrHsFAxrjaoHJGp8=.0ab16e40-05ef-442d-8c0b-3976e6db8867@github.com>
 <dI6yKxvCy5qLDu1gxGqBAMrF3CvPrG63EuoMTz-IOkQ=.eac5d915-1012-4601-a7a3-1d6d02faba32@github.com>
 <Lgle9DenSaP8ZUHmgasNPuyJeXbzSwJhQVfMthod5ro=.3fa96680-3bff-4df3-9d3e-2963fbed5b3e@github.com>
Message-ID: <SDRh6qY6UALae7o2OuBO03NizoGkwVLxzdEacoIH7_g=.7c680916-83a0-4774-8334-85aa6e46110b@github.com>

On Wed, 15 Sep 2021 08:15:37 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> And I tried to keep the same idea for the fix in windows:
> `The idea of the fix would be to pick up AwtWindow.m_resizing value and not consider any messages in PreProcessMouseMsg until m_resizing is true.`

If the idea just align behavior to the Windows then you can just update the AWTWindow.m#_deliverMoveResizeEvent, same as on windows set your flag to true when the [self.nsWindow inLiveResize] is true, and then at the end of the method _deliverMoveResizeEvent sets the flag to false. Or just check that [self.nsWindow inLiveResize] flag before sending the mouse event.

But note that [AWTWindow synthesizeMouseEnteredExitedEventsForAllWindows] is called in the _deliverMoveResizeEvent, so it is quite possible that these "additional" events are posted by our code and not by the macos.

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

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


From pbansal at openjdk.java.net  Thu Sep 16 06:16:47 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 16 Sep 2021 06:16:47 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v2]
In-Reply-To: <UJxt9hV1vj20vdhvr1UfU4SNafbVXNVr5a7SuXwH0as=.998fc44d-e26f-49d1-9a8a-4c2f60092756@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <ML-6qoWxRsMUttXmsTygOb_iMz3MrHsFAxrjaoHJGp8=.0ab16e40-05ef-442d-8c0b-3976e6db8867@github.com>
 <CuK41rhNvK3zkYmV-6BDAKCVcs1UedtxYSkE3eSEON0=.4a43288c-6d00-441e-a4c3-748a23fb8501@github.com>
 <UJxt9hV1vj20vdhvr1UfU4SNafbVXNVr5a7SuXwH0as=.998fc44d-e26f-49d1-9a8a-4c2f60092756@github.com>
Message-ID: <pmv1aq6rUjTCjyj92jcumlPxbVSoZ46to5hwX7gGtLE=.9aefb7d4-c79f-4257-aabf-199ee323121b@github.com>

On Wed, 15 Sep 2021 08:22:03 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> test/jdk/java/awt/event/MouseEvent/ResizeMouseExitEnterMisfire/ResizeMouseExitEnterMisfire.java line 61:
>> 
>>> 59:             public void run() {
>>> 60:                 frame = new JFrame();
>>> 61:                 frame.setSize(200, 200);
>> 
>> It is preferred to move the frame to centre of screen by calling frame.setLocationRelativeTo(null)
>
> I use the frame size to find the correct location of the mouse for robot, so moving the frame to the center of the screen would make calculating mouse locations more complicated...
> And I need some space to expand the window, which could be limited if the frame were to be in the center, so in this case it's probably better to keep the window in the top left corner? Unless there's a reasoning I missed for moving it to the center?

This is done because the Robot sometime ends up clicking on Taskbar or side bar on Linux and we have had some related issue. Moving to centre helps to avoid those issues. Also, you just need to call frame.getLocationOnScreen to get the location along with the frame.bounds to get correct location. But this all is optional/preferred and it is fine you would like to keep the frame in left top.

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

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


From pbansal at openjdk.java.net  Thu Sep 16 06:16:48 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 16 Sep 2021 06:16:48 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v3]
In-Reply-To: <YnkE51JvQLUQ5pcBJn3sJJJTUoFQ1w82-nx9Xpz382Y=.815d763c-baf9-4b9c-abd6-e15fe22efa00@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <YnkE51JvQLUQ5pcBJn3sJJJTUoFQ1w82-nx9Xpz382Y=.815d763c-baf9-4b9c-abd6-e15fe22efa00@github.com>
Message-ID: <wkqHqywztFYyxMfO5Zb5gdAoDMyVxlP_nhYnHiRlnDo=.9553fd50-a24b-4b68-a5d3-37ed16788e41@github.com>

On Wed, 15 Sep 2021 14:42:19 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated test

test/jdk/java/awt/event/MouseEvent/ResizeMouseExitEnterMisfire/ResizeMouseExitEnterMisfire.java line 167:

> 165: 
> 166:     public void done() {
> 167:         frame.dispose();

This also needs to be done on EDT thread

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

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


From serb at openjdk.java.net  Thu Sep 16 06:19:51 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 16 Sep 2021 06:19:51 GMT
Subject: RFR: 8268084: [macos] Disabled JMenuItem arrow is not disabled
 [v7]
In-Reply-To: <O0VdzC73jbrtVB5nIIcyTg3TAbaaMtbKjI6Qg8f_c4o=.6b177929-4f11-473d-abb7-2a4283956c93@github.com>
References: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>
 <O0VdzC73jbrtVB5nIIcyTg3TAbaaMtbKjI6Qg8f_c4o=.6b177929-4f11-473d-abb7-2a4283956c93@github.com>
Message-ID: <V0KXMuSkCiLFtEIRokuKAHivCK56y7duReMHRGuq3P4=.e597bcc7-4a24-4e92-a104-1f70fd37596c@github.com>

On Mon, 13 Sep 2021 08:41:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It is seen in macos disabled JMenuItem arrow is not disabled even though JMenuItem itself is disabled.
>> In native app, same menuitem arrow is disabled for disabled menuitem.
>> 
>> Issue is when AquaMenuPainter#paintMenuItem() is called, it tries to draw a ImageIcon image of the arrow via ImageIcon#paintIcon which tries to generate MultiResolutionCachedImage via getResolutionVariant() by calling AquaUtils#generateFilteredImage.
>> It does not take into account if disabled arrow icon image needs to be drawn or not, so it is always enabled.
>> 
>> Proposed fix is to generate a disabled ImageIcon image of the same arrow icon and use it for disabled state.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable invertedIcon icon too

Looks fine

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

Marked as reviewed by serb (Reviewer).

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


From myano at openjdk.java.net  Thu Sep 16 08:05:50 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 16 Sep 2021 08:05:50 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
Message-ID: <CNhYAnlto7xFn0uaNI6xcTOgsuMBDkJfmYc0ss0ODlA=.6af8a4f5-0b2b-48f7-aac9-b385616a1e07@github.com>

On Mon, 13 Sep 2021 11:32:37 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 7001973 fixes?
> 
> On Windows, CopyAreaOOB.java fails with a blank window. The cause of this problem is that paint() works one time only. Painting area is not guaranteed when showing a window.
> 
> I think this behavior should be removed for purpose of this test (`@summary: Verifies that copyArea() works properly`). Also, this program uses a Robot, but implements waiting logic by itself. This logic should be replaced to Robot API.
> 
> This fix works fine in Windows, so this test can be removed from ProblemList.txt. I don't have a Mac environment, so can someone please confirm that this fix will work on Mac?

I read JDK-6430601 and JDK-8198613, described at `@bug`. JDK-6430601 is a background rendering problem in JInternalFrame with OpenGL pipeline. JDK-8198613 is a timeout problem with OpenGL pipeline, as a result, OpenGL pipeline test is removed.
So now, the purpose of this test is to confirm the usual drawing result on default settings, then I think there is no need to strict paint() at once.

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

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


From shade at openjdk.java.net  Thu Sep 16 08:49:48 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 16 Sep 2021 08:49:48 GMT
Subject: RFR: 8273821: Limit parallelism for sanity/client/SwingSet tests
In-Reply-To: <m5LUIlpQozmWLFepnVYRhcAXy0aEaJkmlupF3p5sC1A=.d91299d5-d870-4499-9c3b-0388bf1b2d9b@github.com>
References: <m5LUIlpQozmWLFepnVYRhcAXy0aEaJkmlupF3p5sC1A=.d91299d5-d870-4499-9c3b-0388bf1b2d9b@github.com>
Message-ID: <vuoXz0BYXCpjfBZAs7GDbp7yd1V3JKzf7K-jIJdU4a0=.383bc004-abc5-405e-8e10-75e522a54444@github.com>

On Wed, 15 Sep 2021 14:18:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> If you run them today on a parallel machine with the usual invocation:
> 
> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/client/SwingSet/
> 
> ...then a whole lot of these tests would fail. It seems to be caused by the overlapping GUI windows that robots fail to reach properly then. It seems these tests need to be run exclusively. 
> 
> @mrserb, maybe I am missing something? How do you run these tests? 
> 
> Additional testing:
>  - [x] `sanity/client/SwingSet/` tests now pass on TR 3970X

Thanks for the input. I cannot find and improvement for `exclusiveAccess.dirs` to accept tags, but I found [this stalled improvement](https://bugs.openjdk.java.net/browse/CODETOOLS-7902831) in jtreg that points the suggested use for `exclusiveAccess.dirs` might be construed as misuse.

The fact that GUI tests are not blocked from parallel execution by default is unfortunate, and that means the prospective `tier4` (#5357) can only reliably run with `!headful`. Which might be good enough...

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

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


From pbansal at openjdk.java.net  Thu Sep 16 09:00:11 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 16 Sep 2021 09:00:11 GMT
Subject: RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged()
 returns leftButton and rightButton as null with GTKLookAndFeel [v2]
In-Reply-To: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
Message-ID: <ZO0hpZNhoTBhndI2BBz_eTvCxVAHQcu46Jta2N-4Gzo=.1f5fe1a1-ceaf-4689-b0ad-eff1f48c88c4@github.com>

> The function documentation for oneTouchExpandableChanged states that the function does couple of things, but in reality  it only does those things if the Look and Feel supports the supportsOneTouchButtons. In case the Look and Feel does not support supportsOneTouchButtons, this functions just returns in beginning and does not do anything.
> This change clarifies the above in function documentation.

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

  Incorporate the suggestions in JBS discussion

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5263/files
  - new: https://git.openjdk.java.net/jdk/pull/5263/files/3f5cf6d8..f7b79a9d

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

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

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


From pbansal at openjdk.java.net  Thu Sep 16 09:36:58 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 16 Sep 2021 09:36:58 GMT
Subject: RFR: JDK-8273808: Cleanup AddFontsToX11FontPath
In-Reply-To: <0Mp0CwAIoz3Vn7nDKZqAtcK4WIRJejKZSXNtGc_rJz8=.c8cdbb21-351e-4f9a-a2d3-7d90ff7ee6f0@github.com>
References: <0Mp0CwAIoz3Vn7nDKZqAtcK4WIRJejKZSXNtGc_rJz8=.c8cdbb21-351e-4f9a-a2d3-7d90ff7ee6f0@github.com>
Message-ID: <rnlxuCAF0_qzjiTDPBkylS03MhWCdv3LLoIgSDYZHS8=.d95a0975-1426-4a45-a5e5-1ab9a6df81a9@github.com>

On Wed, 15 Sep 2021 11:46:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello please review this small cleanup change.  Seems AddFontsToX11FontPath from fontpath.c is unused/unreferenced and can be removed.
> 
> Thanks, Matthias

Looks good to me. I have verified that the function is not referenced anywhere. Just to be sure, I gave a mach5 job also (Link in JBS). Did not see anything wrong.

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

Marked as reviewed by pbansal (Reviewer).

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


From serb at openjdk.java.net  Thu Sep 16 09:55:46 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 16 Sep 2021 09:55:46 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <CNhYAnlto7xFn0uaNI6xcTOgsuMBDkJfmYc0ss0ODlA=.6af8a4f5-0b2b-48f7-aac9-b385616a1e07@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <CNhYAnlto7xFn0uaNI6xcTOgsuMBDkJfmYc0ss0ODlA=.6af8a4f5-0b2b-48f7-aac9-b385616a1e07@github.com>
Message-ID: <hFuB8qevUSEcbmuyNiGfv4dYx_hlwKfUMcaAr1Zybaw=.f776fa65-373a-4345-9860-91a5bc4ade03@github.com>

On Thu, 16 Sep 2021 08:03:17 GMT, Masanori Yano <myano at openjdk.org> wrote:

> So now, the purpose of this test is to confirm the usual drawing result on default settings, then I think there is no need to strict paint() at once.

The test checks that the painting is correct, why it should check that a few times? If the paint method was called and the copyArea completed then why the window can be blank?

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

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


From mbaesken at openjdk.java.net  Thu Sep 16 10:45:47 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 16 Sep 2021 10:45:47 GMT
Subject: RFR: JDK-8273808: Cleanup AddFontsToX11FontPath
In-Reply-To: <0Mp0CwAIoz3Vn7nDKZqAtcK4WIRJejKZSXNtGc_rJz8=.c8cdbb21-351e-4f9a-a2d3-7d90ff7ee6f0@github.com>
References: <0Mp0CwAIoz3Vn7nDKZqAtcK4WIRJejKZSXNtGc_rJz8=.c8cdbb21-351e-4f9a-a2d3-7d90ff7ee6f0@github.com>
Message-ID: <LPV2EDMYKhNk482ADWrh3vMUBizYoxOmi6Ul_o-Z5KE=.65660e54-f7b1-4953-8d3c-df9ac9b72e4d@github.com>

On Wed, 15 Sep 2021 11:46:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello please review this small cleanup change.  Seems AddFontsToX11FontPath from fontpath.c is unused/unreferenced and can be removed.
> 
> Thanks, Matthias

Hi Pankaj , thanks for the review and additional testing you did.  Can we count this change as trivial or  should I wait for a second review ?
Best regards, Matthias

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

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


From alexsch at openjdk.java.net  Thu Sep 16 13:38:37 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Thu, 16 Sep 2021 13:38:37 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v3]
In-Reply-To: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
Message-ID: <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>

> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
> 
> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
> 
> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
> 
> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.

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

  Move createFontManager() code to sun.font.PlatformFontInfo class

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5517/files
  - new: https://git.openjdk.java.net/jdk/pull/5517/files/8791b57d..16f7cede

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

  Stats: 134 lines in 7 files changed: 115 ins; 18 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5517.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5517/head:pull/5517

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


From alexsch at openjdk.java.net  Thu Sep 16 13:45:54 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Thu, 16 Sep 2021 13:45:54 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v3]
In-Reply-To: <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>
Message-ID: <Zvyb-NzsWv863mr4zefZMNHHZfN1e5Q55o_JFM08dWA=.f945246f-53c0-4307-8866-fcdd3d429b22@github.com>

On Thu, 16 Sep 2021 13:38:37 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move createFontManager() code to sun.font.PlatformFontInfo class

FontManagerFactory is placed in sun.font package and PlatformGraphicsInfo is in sun.awt.

The updated code moves createFontManager()  method from PlatformGraphicsInfo to new added sun.font.PlatformFontInfo class.
The PlatformFontInfo class and its method have default access modifier. The comment is added to the createFontManager() method.

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

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


From ecki at zusammenkunft.net  Tue Sep 14 00:31:27 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 14 Sep 2021 00:31:27 +0000
Subject: RFR: 8273684: Unnecessary Stack usage
In-Reply-To: <XqP_l9M7VeqgW1cVrTov742s2Beh0U9BwSpj1jYzPsk=.c0df2e75-8012-4123-9eb1-a69687798985@github.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
 <XqP_l9M7VeqgW1cVrTov742s2Beh0U9BwSpj1jYzPsk=.c0df2e75-8012-4123-9eb1-a69687798985@github.com>
Message-ID: <AM0PR03MB4145D2F6630799B141E85B77FFDA9@AM0PR03MB4145.eurprd03.prod.outlook.com>

Maybe better use addFirst(), for example in CommandProcessor there is a comment that order matters (did not check it more closely), so it?s probably best to not reverse orders in any place? The Dequeue Javadoc lists addFirst as the aproperiate stack#push replacement.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: serviceability-dev <serviceability-dev-retn at openjdk.java.net> im Auftrag von Andrey Turbanov <github.com+741251+turbanoff at openjdk.java.net>
Gesendet: Monday, September 13, 2021 9:29:26 PM
An: client-libs-dev at openjdk.java.net <client-libs-dev at openjdk.java.net>; serviceability-dev at openjdk.java.net <serviceability-dev at openjdk.java.net>
Betreff: Re: RFR: 8273684: Unnecessary Stack usage

On Sun, 29 Aug 2021 21:14:19 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Usage of thread-safe collection Stack is unnecessary. It's recommended to use ArrayDequeue if a thread-safe implementation is not needed.

Yeah. You are right! TIL that order of iteration is different in ArrayDequeu vs Stack: Stack.push() adds to the "end of stack" (it just calls Vector.add()), while ArrayDeque.push adds "first element"
Luckily for us there was only one place which depend on this. It's small method `javax.swing.text.html.HTMLDocument.HTMLReader#getPathTo`. I've changed method to use ArrayList instead.

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

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


From turbanoff at gmail.com  Thu Sep 16 08:00:57 2021
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Thu, 16 Sep 2021 11:00:57 +0300
Subject: BoxView#calculateMinorAxisRequirements meaningless Math.max
Message-ID: <CAF+DQ5f29Yejzg3crHPi8W0ZPpg=mc+49BxAayhdirBaRfdz6g@mail.gmail.com>

Hello.
I found suspicious code in the
javax.swing.text.BoxView#calculateMinorAxisRequirements method, when I
checked warnings from IntelliJ IDEA.
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/text/BoxView.java#L906
```
int min = 0;
long pref = 0;
int max = Integer.MAX_VALUE;
int n = getViewCount();
for (int i = 0; i < n; i++) {
    View v = getView(i);
    min = Math.max((int) v.getMinimumSpan(axis), min);
    pref = Math.max((int) v.getPreferredSpan(axis), pref);
    max = Math.max((int) v.getMaximumSpan(axis), max);
}
```

It calls Math.max(int, int) method with a second argument Integer.MAX_VALUE.
This call is useless, as the result will always be Integer.MAX_VALUE.
Looks like initial values for max/min variables are mixed up.

Andrey Turbanov


From chen.j.patrick at gmail.com  Thu Sep 16 09:06:21 2021
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Thu, 16 Sep 2021 11:06:21 +0200
Subject: RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged()
 returns leftButton and rightButton as null with GTKLookAndFeel [v2]
In-Reply-To: <ZO0hpZNhoTBhndI2BBz_eTvCxVAHQcu46Jta2N-4Gzo=.1f5fe1a1-ceaf-4689-b0ad-eff1f48c88c4@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
 <ZO0hpZNhoTBhndI2BBz_eTvCxVAHQcu46Jta2N-4Gzo=.1f5fe1a1-ceaf-4689-b0ad-eff1f48c88c4@github.com>
Message-ID: <CANmuJ8ty=MJW29T42QORU2gxs2_vxLWTBPL4eu+u9OpEME7tzA@mail.gmail.com>

You should review your patch I comment the last line
do not merge

Le jeu. 16 sept. 2021 ? 11:01, Pankaj Bansal <pbansal at openjdk.java.net> a
?crit :

> > The function documentation for oneTouchExpandableChanged states that the
> function does couple of things, but in reality  it only does those things
> if the Look and Feel supports the supportsOneTouchButtons. In case the Look
> and Feel does not support supportsOneTouchButtons, this functions just
> returns in beginning and does not do anything.
> > This change clarifies the above in function documentation.
>
> Pankaj Bansal has updated the pull request incrementally with one
> additional commit since the last revision:
>
>   Incorporate the suggestions in JBS discussion
>
> -------------
>
> Changes:
>   - all: https://git.openjdk.java.net/jdk/pull/5263/files
>   - new:
> https://git.openjdk.java.net/jdk/pull/5263/files/3f5cf6d8..f7b79a9d
>
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5263&range=01
>  - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5263&range=00-01
>
>   Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
>   Patch: https://git.openjdk.java.net/jdk/pull/5263.diff
>   Fetch: git fetch https://git.openjdk.java.net/jdk
> pull/5263/head:pull/5263
>
> PR: https://git.openjdk.java.net/jdk/pull/5263
>


From shade at openjdk.java.net  Thu Sep 16 15:09:42 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 16 Sep 2021 15:09:42 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTexTAndGraphicsState.java [v2]
In-Reply-To: <TdctZLjCnE9j7nwSNF58kdpa_Q9NxzmOSZSiqU3GCW4=.5cba103a-c9d9-4960-9bea-6be6824afed4@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
 <TdctZLjCnE9j7nwSNF58kdpa_Q9NxzmOSZSiqU3GCW4=.5cba103a-c9d9-4960-9bea-6be6824afed4@github.com>
Message-ID: <eTqxu7h5t7S695YmJWkudJAkKTksVUFmmpw5LeX_GFA=.484d09fe-1bcf-47fe-a816-901340bd9229@github.com>

On Tue, 14 Sep 2021 00:10:26 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

>> Problem : 
>> 1) Test case was failing with following exception
>> test result: Error. Parse Exception: Arguments to `manual' option not supported: yes 
>> 2) After removing =yes/no Parser exception is not seen but test UI will show and closes immediately  where the user cannot see what is on the frame. 
>> 
>> Fix : 
>> 1) Add frame to show the test instructions.
>> 2) Added timeout for the test case.
>> 3) Show the test UI until either test case gets timeout or user press pass or fail button.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed minor issue

This change looks far beyond "Remove jtreg tag manual=yesno for java/awt/Graphics/LCDTexTAndGraphicsState.java", please change the synopsis to reflect what is going on in the test?

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Thu Sep 16 18:00:50 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Thu, 16 Sep 2021 18:00:50 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v2]
In-Reply-To: <pmv1aq6rUjTCjyj92jcumlPxbVSoZ46to5hwX7gGtLE=.9aefb7d4-c79f-4257-aabf-199ee323121b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <ML-6qoWxRsMUttXmsTygOb_iMz3MrHsFAxrjaoHJGp8=.0ab16e40-05ef-442d-8c0b-3976e6db8867@github.com>
 <CuK41rhNvK3zkYmV-6BDAKCVcs1UedtxYSkE3eSEON0=.4a43288c-6d00-441e-a4c3-748a23fb8501@github.com>
 <UJxt9hV1vj20vdhvr1UfU4SNafbVXNVr5a7SuXwH0as=.998fc44d-e26f-49d1-9a8a-4c2f60092756@github.com>
 <pmv1aq6rUjTCjyj92jcumlPxbVSoZ46to5hwX7gGtLE=.9aefb7d4-c79f-4257-aabf-199ee323121b@github.com>
Message-ID: <MfceXVIo5XC33RKGX3n7iEi5ijukOO47aST3OVNVOaM=.956f9816-dfe5-438c-839b-47a4510d9f71@github.com>

On Thu, 16 Sep 2021 06:11:33 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> I use the frame size to find the correct location of the mouse for robot, so moving the frame to the center of the screen would make calculating mouse locations more complicated...
>> And I need some space to expand the window, which could be limited if the frame were to be in the center, so in this case it's probably better to keep the window in the top left corner? Unless there's a reasoning I missed for moving it to the center?
>
> This is done because the Robot sometime ends up clicking on Taskbar or side bar on Linux and we have had some related issue. Moving to centre helps to avoid those issues. Also, you just need to call frame.getLocationOnScreen to get the location along with the frame.bounds to get correct location. But this all is optional/preferred and it is fine you would like to keep the frame in left top.

I see, let me make that change then

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Thu Sep 16 18:14:39 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Thu, 16 Sep 2021 18:14:39 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v4]
In-Reply-To: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
Message-ID: <NQeTa7VtY1eiq4gdcIJPqVop1POTPUd2jMcN3rxu7Qc=.eac82fb3-685c-4bd1-8df0-0c2f8a5571ed@github.com>

> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.

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

  reverted changes, removed synthesizeMouseEvents from deliverMoveResizeEvent in AWTWindow.m, updated test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5497/files
  - new: https://git.openjdk.java.net/jdk/pull/5497/files/acbf7984..c50ed453

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

  Stats: 51 lines in 4 files changed: 8 ins; 26 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5497.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5497/head:pull/5497

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


From github.com+90066231+alisenchung at openjdk.java.net  Thu Sep 16 18:14:39 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Thu, 16 Sep 2021 18:14:39 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v2]
In-Reply-To: <SDRh6qY6UALae7o2OuBO03NizoGkwVLxzdEacoIH7_g=.7c680916-83a0-4774-8334-85aa6e46110b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <ML-6qoWxRsMUttXmsTygOb_iMz3MrHsFAxrjaoHJGp8=.0ab16e40-05ef-442d-8c0b-3976e6db8867@github.com>
 <dI6yKxvCy5qLDu1gxGqBAMrF3CvPrG63EuoMTz-IOkQ=.eac5d915-1012-4601-a7a3-1d6d02faba32@github.com>
 <Lgle9DenSaP8ZUHmgasNPuyJeXbzSwJhQVfMthod5ro=.3fa96680-3bff-4df3-9d3e-2963fbed5b3e@github.com>
 <SDRh6qY6UALae7o2OuBO03NizoGkwVLxzdEacoIH7_g=.7c680916-83a0-4774-8334-85aa6e46110b@github.com>
Message-ID: <l8cRec8FfdflC0Hhalh78a8cp4R1bJz8kmTpGqyZy2A=.e6a3f537-00ff-4cf4-8386-2a25e958102b@github.com>

On Thu, 16 Sep 2021 03:48:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > And I tried to keep the same idea for the fix in windows:
> > `The idea of the fix would be to pick up AwtWindow.m_resizing value and not consider any messages in PreProcessMouseMsg until m_resizing is true.`
> 
> If the idea just align behavior to the Windows then you can just update the AWTWindow.m#_deliverMoveResizeEvent, same as on windows set your flag to true when the [self.nsWindow inLiveResize] is true, and then at the end of the method _deliverMoveResizeEvent sets the flag to false. Or just check that [self.nsWindow inLiveResize] flag before sending the mouse event.
> 
> But note that [AWTWindow synthesizeMouseEnteredExitedEventsForAllWindows] is called in the _deliverMoveResizeEvent, so it is quite possible that these "additional" events are posted by our code and not by the macos.

Oh you're right, removing the line also removes the extra mouseEntered and mouseExit events. I thought it wasn't being called because a print statement I put in that function never showed up, but I must've messed something up. Was there a reason for the synthesizeMouseEnteredExitedEventsForAllWindows call?

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

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


From github.com+10835776+stsypanov at openjdk.java.net  Thu Sep 16 19:10:43 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 16 Sep 2021 19:10:43 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v4]
In-Reply-To: <eciHLB1bKgy02_eV0d-Y-RiECZshzMxHakK2ZaUhFk0=.298fe17f-0913-4f1e-8eba-4587c28b05b1@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <eciHLB1bKgy02_eV0d-Y-RiECZshzMxHakK2ZaUhFk0=.298fe17f-0913-4f1e-8eba-4587c28b05b1@github.com>
Message-ID: <XjBCYp6YkrOTmcHd90YOsdNAIyR96MOB1AFhe7nVHRA=.813f0a69-b3da-46b9-a2bf-9f2bd8b84c16@github.com>

On Thu, 1 Jul 2021 12:19:53 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8268764: Update copy-right year

Let's wait, bridgekeeper.

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

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


From github.com+741251+turbanoff at openjdk.java.net  Thu Sep 16 19:14:57 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 16 Sep 2021 19:14:57 GMT
Subject: RFR: 8273907: Cleanup redundant Math.max/min calls in
 DefaultHighlighter
Message-ID: <VJylGXYSbxLWIVFDE4vQGoRvhS7T0XqELx_eQvVYgKY=.96d1c0b9-0e90-4d19-ac99-925ba3e39185@github.com>

This calls are redundant, because order of `p0` and `p1` is checked in method pre-conditions.
Checks were added under [JDK-6771184](https://bugs.openjdk.java.net/browse/JDK-6771184) - https://github.com/openjdk/jdk/commit/79ed0e75ceeb

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

Commit messages:
 - [PATCH] Avoid redundant Math.min/Math.max calls in DefaultHighlighter

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

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


From shade at openjdk.java.net  Thu Sep 16 19:14:57 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 16 Sep 2021 19:14:57 GMT
Subject: RFR: 8273907: Cleanup redundant Math.max/min calls in
 DefaultHighlighter
In-Reply-To: <VJylGXYSbxLWIVFDE4vQGoRvhS7T0XqELx_eQvVYgKY=.96d1c0b9-0e90-4d19-ac99-925ba3e39185@github.com>
References: <VJylGXYSbxLWIVFDE4vQGoRvhS7T0XqELx_eQvVYgKY=.96d1c0b9-0e90-4d19-ac99-925ba3e39185@github.com>
Message-ID: <MibxVZP6CvPLaV9blDdGIBPY_L_sTDkDnHxJljl1Q-A=.5fc73044-9e7d-493f-8aa7-d1684cbbd475@github.com>

On Thu, 16 Sep 2021 08:08:07 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> This calls are redundant, because order of `p0` and `p1` is checked in method pre-conditions.
> Checks were added under [JDK-6771184](https://bugs.openjdk.java.net/browse/JDK-6771184) - https://github.com/openjdk/jdk/commit/79ed0e75ceeb

@turbanoff, you are already [recorded](https://openjdk.java.net/census#aturbanov) as Author, which means you have the access to JIRA? Could you please submit the bug yourself and change the title of this PR accordingly?

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

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


From aivanov at openjdk.java.net  Thu Sep 16 20:03:54 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 16 Sep 2021 20:03:54 GMT
Subject: RFR: 8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java
 does not show instruction [v2]
In-Reply-To: <dMEQsiVSGqRUhMomijd0Tau9vD7KmvRh3UxIeCB0pCw=.0ea5f7f4-b5d4-46fe-8528-fb9c4938f47c@github.com>
References: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
 <dMEQsiVSGqRUhMomijd0Tau9vD7KmvRh3UxIeCB0pCw=.0ea5f7f4-b5d4-46fe-8528-fb9c4938f47c@github.com>
Message-ID: <W72KKwQ9xDI9AinfhV4nN_sCJRucgv-iGaJWnpNQc5s=.03c1f113-2a48-44d5-b2ec-d0b49f027c33@github.com>

On Wed, 15 Sep 2021 20:23:24 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

>> 1) When the test is executed via jtreg user can see only print dialog with no instruction to the user. User has to see the test case to see the instruction and perform the test . 
>> 2) With this fix User is instructed what he/she has to do with the print dialog.
>> 3) I have added both success instruction as well as failure instruction.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Close instruction frame if OK/Cancel button is pressed

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/print/Dialog/DialogCopies.java line 58:

> 56:         instructionTextArea.setEditable(false);
> 57:         mainControlPanel.add(instructionTextArea, BorderLayout.CENTER);
> 58:         instructionFrame.add(mainControlPanel);

The panel is not needed here, there's only one component in the panel, so

instructionFrame.add(instructionTextArea, BorderLayout.CENTER);

will do just fine.

You can set the text to `TextArea` in its constructor.

test/jdk/java/awt/print/Dialog/DialogCopies.java line 80:

> 78:         } else {
> 79:             System.out.println("User has selected Cancel button on the PrintDialog");
> 80:         }

I suggest treating *Cancel* button as a pass. It will handle the case where the user does not have a real printer but has virtual printers such as *Microsoft Print to PDF* or *Microsoft XPS Document Writer*. Neither allows setting *Copies* to anything but 1. If you increase the number of copies and click OK, an error message is displayed. Yet clicking OK with number of copies set 1 will fail the test.

To avoid such a situation, clicking *Cancel* should be treated a passed test or rather a skipped one.

test/jdk/java/awt/print/Dialog/DialogCopies.java line 84:

> 82:         if (copies <= 1) {
> 83:             testResult = false;
> 84:             System.out.println("Expected the number of copies to be more than 1 but got " + copies);

At this time, your code is synchronous and is executed on main thread only, therefore you can `throw new RuntimeException` with an error message here without using the `testResult` flag.

test/jdk/java/awt/print/Dialog/DialogCopies.java line 99:

> 97:         if (!countDownLatch.await(5, TimeUnit.MINUTES)) {
> 98:             throw new RuntimeException("Timeout : No action was performed on the test UI.");
> 99:         }

`job.printDialog()`  is a blocking call. This line will be reached only after the Print dialog is dismissed, thus the test will never time out by the latch.

The original version of the test didn't support timing out, so the updated version may skip this too. You may submit a new bug to implement timeout support.

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

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


From prr at openjdk.java.net  Thu Sep 16 20:20:53 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 16 Sep 2021 20:20:53 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v3]
In-Reply-To: <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>
Message-ID: <MoOup_7SoK-rr22E_bl5SCUoGSlWwnxExMOJhgo36nA=.2c837f30-e3ab-4448-9123-5c1469f8919f@github.com>

On Thu, 16 Sep 2021 13:38:37 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move createFontManager() code to sun.font.PlatformFontInfo class

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.java.net  Thu Sep 16 21:04:59 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 16 Sep 2021 21:04:59 GMT
Subject: RFR: 8273913: Problem list some headful client jtreg tests that fail
 on macOS12
Message-ID: <IN1R_YQRdCXLs6ce0HRnt6vCE16D0z66VC8Dh_LTuFM=.30b51501-c16e-48f5-b2fc-fcf19e930405@github.com>

Simple Problem list update

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

Commit messages:
 - 8273913: Problem list some headful client jtreg tests that fail on macOS 12

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Thu Sep 16 21:35:16 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Thu, 16 Sep 2021 21:35:16 GMT
Subject: RFR: 8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java
 does not show instruction [v3]
In-Reply-To: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
References: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
Message-ID: <DwlJXlrymWF2VbaclZbV0tw3KZV4KBIzk_TR7LIv21c=.4a47a752-e054-4c80-b150-6ffeeef6f1ea@github.com>

> 1) When the test is executed via jtreg user can see only print dialog with no instruction to the user. User has to see the test case to see the instruction and perform the test . 
> 2) With this fix User is instructed what he/she has to do with the print dialog.
> 3) I have added both success instruction as well as failure instruction.
> 
> @shurymury

lawrence.andrews has updated the pull request incrementally with three additional commits since the last revision:

 - removed unwanted textarea.setText
 - minor change
 - Close instruction frame after clicking OK/Cancel button

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4850/files
  - new: https://git.openjdk.java.net/jdk/pull/4850/files/8b5510a0..2373d895

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

  Stats: 55 lines in 1 file changed: 12 ins; 26 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4850.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4850/head:pull/4850

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Thu Sep 16 21:35:24 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Thu, 16 Sep 2021 21:35:24 GMT
Subject: RFR: 8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java
 does not show instruction [v2]
In-Reply-To: <W72KKwQ9xDI9AinfhV4nN_sCJRucgv-iGaJWnpNQc5s=.03c1f113-2a48-44d5-b2ec-d0b49f027c33@github.com>
References: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
 <dMEQsiVSGqRUhMomijd0Tau9vD7KmvRh3UxIeCB0pCw=.0ea5f7f4-b5d4-46fe-8528-fb9c4938f47c@github.com>
 <W72KKwQ9xDI9AinfhV4nN_sCJRucgv-iGaJWnpNQc5s=.03c1f113-2a48-44d5-b2ec-d0b49f027c33@github.com>
Message-ID: <C6BbX5NFB6Aoiq6Ap2vywNInqks_zQGjUWMoD-BP8JE=.b5b1761a-af26-4883-b5e8-3229f8f58b3a@github.com>

On Thu, 16 Sep 2021 19:44:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Close instruction frame if OK/Cancel button is pressed
>
> test/jdk/java/awt/print/Dialog/DialogCopies.java line 58:
> 
>> 56:         instructionTextArea.setEditable(false);
>> 57:         mainControlPanel.add(instructionTextArea, BorderLayout.CENTER);
>> 58:         instructionFrame.add(mainControlPanel);
> 
> The panel is not needed here, there's only one component in the panel, so
> 
> instructionFrame.add(instructionTextArea, BorderLayout.CENTER);
> 
> will do just fine.
> 
> You can set the text to `TextArea` in its constructor.

Done

> test/jdk/java/awt/print/Dialog/DialogCopies.java line 80:
> 
>> 78:         } else {
>> 79:             System.out.println("User has selected Cancel button on the PrintDialog");
>> 80:         }
> 
> I suggest treating *Cancel* button as a pass. It will handle the case where the user does not have a real printer but has virtual printers such as *Microsoft Print to PDF* or *Microsoft XPS Document Writer*. Neither allows setting *Copies* to anything but 1. If you increase the number of copies and click OK, an error message is displayed. Yet clicking OK with number of copies set 1 will fail the test.
> 
> To avoid such a situation, clicking *Cancel* should be treated a passed test or rather a skipped one.

If user click the Cancel button the test is passed.

> test/jdk/java/awt/print/Dialog/DialogCopies.java line 84:
> 
>> 82:         if (copies <= 1) {
>> 83:             testResult = false;
>> 84:             System.out.println("Expected the number of copies to be more than 1 but got " + copies);
> 
> At this time, your code is synchronous and is executed on main thread only, therefore you can `throw new RuntimeException` with an error message here without using the `testResult` flag.

Done throwing RunTimeException if number of copies is less than <= 1

> test/jdk/java/awt/print/Dialog/DialogCopies.java line 99:
> 
>> 97:         if (!countDownLatch.await(5, TimeUnit.MINUTES)) {
>> 98:             throw new RuntimeException("Timeout : No action was performed on the test UI.");
>> 99:         }
> 
> `job.printDialog()`  is a blocking call. This line will be reached only after the Print dialog is dismissed, thus the test will never time out by the latch.
> 
> The original version of the test didn't support timing out, so the updated version may skip this too. You may submit a new bug to implement timeout support.

I will handle the timeout separately.

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

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


From serb at openjdk.java.net  Fri Sep 17 01:45:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 17 Sep 2021 01:45:48 GMT
Subject: RFR: 8273684: Replace usages of java.util.Stack with ArrayDeque
In-Reply-To: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
Message-ID: <DOk6cP_5kldI4vOPj13yNuNUbsTsLBq_N38U6Kjjq0A=.e7e5f1f2-213b-4340-8138-7fb6df9a4f1e@github.com>

On Sun, 29 Aug 2021 21:14:19 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Usage of thread-safe collection Stack is unnecessary. It's recommended to use ArrayDequeue if a thread-safe implementation is not needed.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Fri Sep 17 02:42:52 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 17 Sep 2021 02:42:52 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in
 the java.util.logging
In-Reply-To: <mt3FHJcNDMsmhP0oEmDr51j1S1d9dXUQr24vL53HDrY=.7045d35a-c3d3-4105-9301-ad9c948e6ff8@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
 <mt3FHJcNDMsmhP0oEmDr51j1S1d9dXUQr24vL53HDrY=.7045d35a-c3d3-4105-9301-ad9c948e6ff8@github.com>
Message-ID: <JXoInLqAX1Sxkykz_N97DO4QEbf6gYjV0ul6l4vsnwY=.14f44cd8-281d-4386-968c-fdc49a9604cf@github.com>

On Mon, 6 Sep 2021 09:39:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> No objection to removing this legacy/unused code but I think it would be useful to useful to have the JBS issue or the PR summary provide a bit more context. As I see it, this is just one piece of the overall cleanup and I assume there are more substantive changes to the java.desktop module coming, is that right?

I have updated the PR and JBS

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

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


From serb at openjdk.java.net  Fri Sep 17 02:47:44 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 17 Sep 2021 02:47:44 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v2]
In-Reply-To: <l8cRec8FfdflC0Hhalh78a8cp4R1bJz8kmTpGqyZy2A=.e6a3f537-00ff-4cf4-8386-2a25e958102b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <ML-6qoWxRsMUttXmsTygOb_iMz3MrHsFAxrjaoHJGp8=.0ab16e40-05ef-442d-8c0b-3976e6db8867@github.com>
 <dI6yKxvCy5qLDu1gxGqBAMrF3CvPrG63EuoMTz-IOkQ=.eac5d915-1012-4601-a7a3-1d6d02faba32@github.com>
 <Lgle9DenSaP8ZUHmgasNPuyJeXbzSwJhQVfMthod5ro=.3fa96680-3bff-4df3-9d3e-2963fbed5b3e@github.com>
 <SDRh6qY6UALae7o2OuBO03NizoGkwVLxzdEacoIH7_g=.7c680916-83a0-4774-8334-85aa6e46110b@github.com>
 <l8cRec8FfdflC0Hhalh78a8cp4R1bJz8kmTpGqyZy2A=.e6a3f537-00ff-4cf4-8386-2a25e958102b@github.com>
Message-ID: <x3_kakUFHgjssLHkM_BUvz8EKzBD4lEiwx6mVPRyQdc=.1f100f7c-a609-48b1-83ae-127fff35d4dd@github.com>

On Thu, 16 Sep 2021 18:05:05 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> Oh you're right, removing the line also removes the extra mouseEntered and mouseExit events. I thought it wasn't being called because a print statement I put in that function never showed up, but I must've messed something up. Was there a reason for the synthesizeMouseEnteredExitedEventsForAllWindows call?

That was done as a fix for JDK-8028485. We have to generate the mouse enter/exit events if the window was moved/resized under the mouse(while the mouse pointer was not moved)

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

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


From pbansal at openjdk.java.net  Fri Sep 17 03:22:46 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 17 Sep 2021 03:22:46 GMT
Subject: RFR: 8273913: Problem list some headful client jtreg tests that
 fail on macOS12
In-Reply-To: <IN1R_YQRdCXLs6ce0HRnt6vCE16D0z66VC8Dh_LTuFM=.30b51501-c16e-48f5-b2fc-fcf19e930405@github.com>
References: <IN1R_YQRdCXLs6ce0HRnt6vCE16D0z66VC8Dh_LTuFM=.30b51501-c16e-48f5-b2fc-fcf19e930405@github.com>
Message-ID: <BH6wTWbsEJDpJa_L9S-QRZnbK2yyG_-OlBEDn6ODJzs=.781fda0a-708d-4cd7-a5bb-12ff09ab8f05@github.com>

On Thu, 16 Sep 2021 20:56:55 GMT, Phil Race <prr at openjdk.org> wrote:

> Simple Problem list update

Looks good to me. BTW there is a warning for title mismatch between JBS and PR.

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

Marked as reviewed by pbansal (Reviewer).

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


From myano at openjdk.java.net  Fri Sep 17 07:35:43 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 17 Sep 2021 07:35:43 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
Message-ID: <lBmeytdgF8uvR57U3eOp-sPg0gmmQn0lu-8kzLANgo8=.4b1fb0cc-60b8-4356-a091-3c759f5bfe0a@github.com>

On Mon, 13 Sep 2021 11:32:37 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 7001973 fixes?
> 
> On Windows, CopyAreaOOB.java fails with a blank window. The cause of this problem is that paint() works one time only. Painting area is not guaranteed when showing a window.
> 
> I think this behavior should be removed for purpose of this test (`@summary: Verifies that copyArea() works properly`). Also, this program uses a Robot, but implements waiting logic by itself. This logic should be replaced to Robot API.
> 
> This fix works fine in Windows, so this test can be removed from ProblemList.txt. I don't have a Mac environment, so can someone please confirm that this fix will work on Mac?

The test checks only one time for painting "result".

I think the painting sequence depends on rendering pipeline. I collected a log the Java2D and the ComponentPeer, then multiple PaintEvent is recorded with default D3D pipeline (see below).  So, paint() should not be restrict one time.


$ /Downloads/jdk-17/bin/java -Dsun.java2d.trace=log,timestamp -Djava.util.logging.config.file=logging.properties CopyAreaOOB
Sep 17, 2021 3:30:57 PM sun.awt.windows.WComponentPeer coalescePaintEvent
FINEST: coalescePaintEvent: PAINT: add: x = 0, y = 0, width = 400, height = 400
Sep 17, 2021 3:30:57 PM sun.awt.windows.WComponentPeer coalescePaintEvent
FINEST: coalescePaintEvent: PAINT: add: x = 0, y = 0, width = 400, height = 400
Sep 17, 2021 3:30:57 PM sun.awt.windows.WComponentPeer coalescePaintEvent
FINEST: coalescePaintEvent: PAINT: add: x = 0, y = 0, width = 0, height = 0
Sep 17, 2021 3:30:57 PM sun.awt.windows.WComponentPeer coalescePaintEvent
FINEST: coalescePaintEvent: PAINT: add: x = 0, y = 0, width = 0, height = 0
Sep 17, 2021 3:30:57 PM sun.awt.windows.WComponentPeer coalescePaintEvent
FINEST: coalescePaintEvent: PAINT: add: x = 0, y = 0, width = 400, height = 400
Sep 17, 2021 3:30:57 PM sun.awt.windows.WComponentPeer coalescePaintEvent
FINEST: coalescePaintEvent: PAINT: add: x = 0, y = 0, width = 400, height = 400
1631860257699: D3DFillRect
1631860257732: D3DFillRect
Sep 17, 2021 3:30:57 PM sun.awt.windows.WComponentPeer coalescePaintEvent
FINEST: coalescePaintEvent: PAINT: add: x = 0, y = 0, width = 400, height = 400
1631860257741: D3DFillRect
1631860257743: D3DFillRect
1631860257750: D3DFillRect
1631860257751: D3DFillRect
1631860257755: D3DFillRect
1631860257757: D3DCopyArea
Sep 17, 2021 3:30:57 PM sun.awt.windows.WComponentPeer coalescePaintEvent
FINEST: coalescePaintEvent: PAINT: add: x = 0, y = 0, width = 400, height = 400
1631860257759: D3DFillRect
1631860257762: D3DFillRect
1631860257763: D3DFillRect
1631860257763: D3DFillRect
1631860257764: D3DFillRect
1631860257764: D3DCopyArea

$ /Downloads/jdk-17/bin/java -Dsun.java2d.trace=log,timestamp -Djava.util.logging.config.file=logging.properties -Duser.language=en -Dsun.java2d.noddraw CopyAreaOOB
Sep 17, 2021 3:32:10 PM sun.awt.windows.WComponentPeer coalescePaintEvent
FINEST: coalescePaintEvent: PAINT: add: x = 0, y = 0, width = 400, height = 400
1631860330225: GDIFillRect
1631860330249: GDIFillRect
1631860330254: GDIFillRect
1631860330254: GDIFillRect
1631860330255: GDICopyArea

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

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


From serb at openjdk.java.net  Fri Sep 17 08:06:44 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 17 Sep 2021 08:06:44 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v3]
In-Reply-To: <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>
Message-ID: <bL30zfna64rA2ZnE13AWOxSltCndsjTeZMEvobsKeFk=.440e635a-14f4-47fd-acdc-b663a7024fee@github.com>

On Thu, 16 Sep 2021 13:38:37 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move createFontManager() code to sun.font.PlatformFontInfo class

src/java.desktop/share/classes/sun/font/FontManagerFactory.java line 54:

> 52:      * @return a valid FontManager instance for the current platform
> 53:      */
> 54:     @SuppressWarnings("removal")

Suppress is not needed anymore?

src/java.desktop/share/classes/sun/font/FontManagerFactory.java line 55:

> 53:      */
> 54:     @SuppressWarnings("removal")
> 55:     public static synchronized FontManager getInstance() {

Just an idea, since the method became so small can we use DLC here instead of synchronised static method?

test/jdk/sun/awt/font/CheckFontManagerSystemProperty.java line 35:

> 33: 
> 34:     public static void main(String[] args) {
> 35:         // force AWT library loading

Do we need the headful or headless libraries?

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

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


From serb at openjdk.java.net  Fri Sep 17 08:18:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 17 Sep 2021 08:18:41 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
Message-ID: <ACRHmQY8PTs2zOxEKTqpI3UP2P_OdWXHccoaHC3FrwM=.6bd5a2c9-b92e-4fbb-babe-005fa463a221@github.com>

On Mon, 13 Sep 2021 11:32:37 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 7001973 fixes?
> 
> On Windows, CopyAreaOOB.java fails with a blank window. The cause of this problem is that paint() works one time only. Painting area is not guaranteed when showing a window.
> 
> I think this behavior should be removed for purpose of this test (`@summary: Verifies that copyArea() works properly`). Also, this program uses a Robot, but implements waiting logic by itself. This logic should be replaced to Robot API.
> 
> This fix works fine in Windows, so this test can be removed from ProblemList.txt. I don't have a Mac environment, so can someone please confirm that this fix will work on Mac?

Let's check the sequence in the test:
1. Frame created
2. Undecorated property is set
3. peer is created, and native configuration completed
4. frame is moved to the center of the screen
5. frame became visible

It is fine to have a few paint events posted for the code above, my question was why the first CopyArea is ignored? If the awt/java2d is not ready yet to draw/repaint the window that events should not be posted, if it is ready then CopyArea should work, no?

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

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


From lucy at openjdk.java.net  Fri Sep 17 08:19:51 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Fri, 17 Sep 2021 08:19:51 GMT
Subject: RFR: JDK-8273808: Cleanup AddFontsToX11FontPath
In-Reply-To: <0Mp0CwAIoz3Vn7nDKZqAtcK4WIRJejKZSXNtGc_rJz8=.c8cdbb21-351e-4f9a-a2d3-7d90ff7ee6f0@github.com>
References: <0Mp0CwAIoz3Vn7nDKZqAtcK4WIRJejKZSXNtGc_rJz8=.c8cdbb21-351e-4f9a-a2d3-7d90ff7ee6f0@github.com>
Message-ID: <0UWqL1tfjlFXPn9nWw6uNhGPCu1GSA5U25ZNrEIACX8=.150be320-3c7b-45af-a2a6-e47b0a13497d@github.com>

On Wed, 15 Sep 2021 11:46:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello please review this small cleanup change.  Seems AddFontsToX11FontPath from fontpath.c is unused/unreferenced and can be removed.
> 
> Thanks, Matthias

LGTM.

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

Marked as reviewed by lucy (Reviewer).

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


From mbaesken at openjdk.java.net  Fri Sep 17 08:23:44 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 17 Sep 2021 08:23:44 GMT
Subject: Integrated: JDK-8273808: Cleanup AddFontsToX11FontPath
In-Reply-To: <0Mp0CwAIoz3Vn7nDKZqAtcK4WIRJejKZSXNtGc_rJz8=.c8cdbb21-351e-4f9a-a2d3-7d90ff7ee6f0@github.com>
References: <0Mp0CwAIoz3Vn7nDKZqAtcK4WIRJejKZSXNtGc_rJz8=.c8cdbb21-351e-4f9a-a2d3-7d90ff7ee6f0@github.com>
Message-ID: <9w8eFuX2LX1MZhPUXflt44rcUSOvhJzJgMTsmkIqTuM=.89a1339f-c4f8-4f5e-a8bc-6bb51fb1dfad@github.com>

On Wed, 15 Sep 2021 11:46:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello please review this small cleanup change.  Seems AddFontsToX11FontPath from fontpath.c is unused/unreferenced and can be removed.
> 
> Thanks, Matthias

This pull request has now been integrated.

Changeset: 35f6f1d6
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/35f6f1d69f4238f16595b9b8f1d11db9e49d4cc9
Stats:     135 lines in 1 file changed: 0 ins; 134 del; 1 mod

8273808: Cleanup AddFontsToX11FontPath

Reviewed-by: pbansal, lucy

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Fri Sep 17 11:59:47 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Fri, 17 Sep 2021 11:59:47 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction [v2]
In-Reply-To: <s_84IuP3_Qd9oDHWeWMuKP7FA3_ZdjvwqViEvSt9BVo=.f500d4d6-5b4d-4f4e-a692-4e29388c672c@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
 <TdctZLjCnE9j7nwSNF58kdpa_Q9NxzmOSZSiqU3GCW4=.5cba103a-c9d9-4960-9bea-6be6824afed4@github.com>
 <s_84IuP3_Qd9oDHWeWMuKP7FA3_ZdjvwqViEvSt9BVo=.f500d4d6-5b4d-4f4e-a692-4e29388c672c@github.com>
Message-ID: <gBiUyt-l8eVdIjFusa3n9fOJJzGC3xikFx3TgEmt60E=.9f334dc3-cae6-4929-9cc9-d576f03adea2@github.com>

On Wed, 15 Sep 2021 15:14:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed minor issue
>
> test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 60:
> 
>> 58:     private static final Frame instructionFrame = new Frame();
>> 59:     private static volatile boolean testResult = false;
>> 60:     private static volatile CountDownLatch countDownLatch;
> 
> It could be `final` and could be initialised here rather than in main.

Both final & volatile can be used it gives error "Illegal combination of modifiers: volatile & final"

> test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 61:
> 
>> 59:     private static volatile boolean testResult = false;
>> 60:     private static volatile CountDownLatch countDownLatch;
>> 61:     private static String text = "This test passes only if this text appears SIX TIMES";
> 
> Could be declared `final`.

Declared text as final

> test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 114:
> 
>> 112: 
>> 113:     private static void createInstructionUI() {
>> 114:         GridBagLayout layout = new GridBagLayout();
> 
> I believe the UI layout could be simplified by using `BorderLayout`, the default for `Frame`, where textArea is placed as `BorderLayout.CENTER` and button panel (with BoxLayout or FlowLayout) is placed as `BorderLayout.SOUTH`.
> 
> It's just a tip. The layout works; don't fix it if it's not broken.

Simplified the TestUI. Right just one frame is shown with UI to verify and button to decide whether test is pass or fail.

> test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 137:
> 
>> 135: 
>> 136:         Button failButton = new Button("Fail");
>> 137:         failButton.setActionCommand("Fail");
> 
> You don't use action command, so it's somewhat redundant.

Removed actionCommand

> test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 162:
> 
>> 160:             }
>> 161:         });
>> 162:         instructionFrame.pack();
> 
> `pack()` is called twice.

Removed pack()

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Fri Sep 17 12:05:21 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Fri, 17 Sep 2021 12:05:21 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction [v3]
In-Reply-To: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
Message-ID: <GC-dXomjLJ3t7KoC0VCRYjo6Qe5znLrq9pXu0zuSjC0=.e9aa33ad-e6c0-4160-9fb7-7c772a4eb707@github.com>

> Problem : 
> 1) Test case was failing with following exception
> test result: Error. Parse Exception: Arguments to `manual' option not supported: yes 
> 2) After removing =yes/no Parser exception is not seen but test UI will show and closes immediately  where the user cannot see what is on the frame. 
> 
> Fix : 
> 1) Add frame to show the test instructions.
> 2) Added timeout for the test case.
> 3) Show the test UI until either test case gets timeout or user press pass or fail button.
> 
> @shurymury

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Simplified test UI

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5503/files
  - new: https://git.openjdk.java.net/jdk/pull/5503/files/31474053..65d34ff0

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

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

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


From psadhukhan at openjdk.java.net  Fri Sep 17 12:32:59 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 17 Sep 2021 12:32:59 GMT
Subject: RFR: 8273578: javax/swing/JMenu/4515762/bug4515762.java fails on
 macOS 12
Message-ID: <24NoEFkW488AOfiZ8_PxM1NgFK7TlU2QGC-7IHlKLZI=.4612676d-4f7e-4d24-9219-5520701ca837@github.com>

The test sometimes fail on macos12 citing "Action has not been received". Seems like some key events sometimes are not received reliably. 
Proposed fix is to apply mach5 stability fixes which is to set autodelay to 100ms, move frame to center of screen from top-left, added extra waitForIdle(), wait for 1 sec after frame is made visible.
Additionally, it is seen that it mixes Util.hitKeys and robot.keyPress/Release. Changed to make it use robot.keyPress/keyRelease all times. Also, updated test to have specific error message for specific keyevent so that we know which keyevent is not received in case it fails again.

Run on mac12 and all other platforms multiple times and test run is green. Link in JBS.

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

Commit messages:
 - 8273578: javax/swing/JMenu/4515762/bug4515762.java fails on macOS 12

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

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


From alexsch at openjdk.java.net  Fri Sep 17 12:41:31 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Fri, 17 Sep 2021 12:41:31 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v4]
In-Reply-To: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
Message-ID: <7jd6rvtyg23E8aU8I0J6L-DHcKp5Cy368t13OE3D_qQ=.f8d0db0e-8767-4c28-8044-0ebb4f1ee073@github.com>

> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
> 
> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
> 
> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
> 
> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.

Alexander Scherbatiy has updated the pull request incrementally with four additional commits since the last revision:

 - Remove obsolete imports from FontManagerFactory
 - Change synchronized to DCL in FontManagerFactory singleton
 - Run CheckFontManagerSystemProperty test in headless mode
 - Remove @SuppressWarnings(removal)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5517/files
  - new: https://git.openjdk.java.net/jdk/pull/5517/files/16f7cede..42276387

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

  Stats: 19 lines in 2 files changed: 5 ins; 11 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5517.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5517/head:pull/5517

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


From psadhukhan at openjdk.java.net  Fri Sep 17 12:41:33 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 17 Sep 2021 12:41:33 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v4]
In-Reply-To: <7jd6rvtyg23E8aU8I0J6L-DHcKp5Cy368t13OE3D_qQ=.f8d0db0e-8767-4c28-8044-0ebb4f1ee073@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <7jd6rvtyg23E8aU8I0J6L-DHcKp5Cy368t13OE3D_qQ=.f8d0db0e-8767-4c28-8044-0ebb4f1ee073@github.com>
Message-ID: <RZVR6g0ptb71yOFdBCK4byPntYMGYaOhscsLZoHhoGs=.3245ab1c-bbed-4727-b0fc-95cf3f4b0146@github.com>

On Fri, 17 Sep 2021 12:37:34 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Remove obsolete imports from FontManagerFactory
>  - Change synchronized to DCL in FontManagerFactory singleton
>  - Run CheckFontManagerSystemProperty test in headless mode
>  - Remove @SuppressWarnings(removal)

src/java.desktop/share/classes/sun/font/FontManagerFactory.java line 32:

> 30:  * platform.
> 31:  *
> 32:  * A default implementation is given for Linux, Solaris and Windows.

Should we also remove mention of Solaris from here (due to JEP381) not being supported in mainline?

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

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


From alexsch at openjdk.java.net  Fri Sep 17 12:41:38 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Fri, 17 Sep 2021 12:41:38 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v3]
In-Reply-To: <bL30zfna64rA2ZnE13AWOxSltCndsjTeZMEvobsKeFk=.440e635a-14f4-47fd-acdc-b663a7024fee@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>
 <bL30zfna64rA2ZnE13AWOxSltCndsjTeZMEvobsKeFk=.440e635a-14f4-47fd-acdc-b663a7024fee@github.com>
Message-ID: <sLt7GHBUzncWrurflV6DsnD_mV8qUoxcNs9-_30TCpM=.7f215fe6-ff7c-4cf5-be94-4794a9317877@github.com>

On Fri, 17 Sep 2021 07:57:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move createFontManager() code to sun.font.PlatformFontInfo class
>
> src/java.desktop/share/classes/sun/font/FontManagerFactory.java line 54:
> 
>> 52:      * @return a valid FontManager instance for the current platform
>> 53:      */
>> 54:     @SuppressWarnings("removal")
> 
> Suppress is not needed anymore?

I removed the SuppressWarnings annotation and obsolete imports.

> test/jdk/sun/awt/font/CheckFontManagerSystemProperty.java line 35:
> 
>> 33: 
>> 34:     public static void main(String[] args) {
>> 35:         // force AWT library loading
> 
> Do we need the headful or headless libraries?

I added `-Djava.awt.headless=true` property to run the test in the headless mode.

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

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


From alexsch at openjdk.java.net  Fri Sep 17 12:45:48 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Fri, 17 Sep 2021 12:45:48 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v3]
In-Reply-To: <bL30zfna64rA2ZnE13AWOxSltCndsjTeZMEvobsKeFk=.440e635a-14f4-47fd-acdc-b663a7024fee@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>
 <bL30zfna64rA2ZnE13AWOxSltCndsjTeZMEvobsKeFk=.440e635a-14f4-47fd-acdc-b663a7024fee@github.com>
Message-ID: <fcO7I3jva-NsKRtZ8xincfMFWddRfhAVAoYe8eyCSPk=.c624343e-16b6-46c4-a611-0ba07a078933@github.com>

On Fri, 17 Sep 2021 07:57:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move createFontManager() code to sun.font.PlatformFontInfo class
>
> src/java.desktop/share/classes/sun/font/FontManagerFactory.java line 55:
> 
>> 53:      */
>> 54:     @SuppressWarnings("removal")
>> 55:     public static synchronized FontManager getInstance() {
> 
> Just an idea, since the method became so small can we use DLC here instead of synchronised static method?

The method `FontManagerFactory.getInstance()` is updated to use DLC.

I used synchronization on FontManagerFactory.class in the first check to be consistent with the previous behavior where synchronization was on the `FontManagerFactory.getInstance()` method.

What about to use a static nested class singleton? It could look like:

public final class FontManagerFactory {

    public static FontManager getInstance() {
        return FontManagerHolder.instance;
    }

    private static class FontManagerHolder {
        private static final FontManager instance = PlatformFontInfo.createFontManager();
    }
}

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

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


From alexsch at openjdk.java.net  Fri Sep 17 12:57:18 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Fri, 17 Sep 2021 12:57:18 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v5]
In-Reply-To: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
Message-ID: <6u5jjyaiXosHkWDSFBC82pGsXusObx_IUBEgS7bZIUU=.614a0863-6beb-4e3d-856a-d80d2b3b4202@github.com>

> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
> 
> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
> 
> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
> 
> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.

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

  Change Solaris default implementation to Mac OS in FontManagerFactory comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5517/files
  - new: https://git.openjdk.java.net/jdk/pull/5517/files/42276387..91109b34

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

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

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


From alexsch at openjdk.java.net  Fri Sep 17 12:57:23 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Fri, 17 Sep 2021 12:57:23 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v4]
In-Reply-To: <RZVR6g0ptb71yOFdBCK4byPntYMGYaOhscsLZoHhoGs=.3245ab1c-bbed-4727-b0fc-95cf3f4b0146@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <7jd6rvtyg23E8aU8I0J6L-DHcKp5Cy368t13OE3D_qQ=.f8d0db0e-8767-4c28-8044-0ebb4f1ee073@github.com>
 <RZVR6g0ptb71yOFdBCK4byPntYMGYaOhscsLZoHhoGs=.3245ab1c-bbed-4727-b0fc-95cf3f4b0146@github.com>
Message-ID: <CDEE_nNMTPDwoi9YKfNj2lFwrsnuqAET4TvvM7U6TEU=.28b3498f-4021-473a-b238-b415f0e82d0d@github.com>

On Fri, 17 Sep 2021 12:37:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexander Scherbatiy has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Remove obsolete imports from FontManagerFactory
>>  - Change synchronized to DCL in FontManagerFactory singleton
>>  - Run CheckFontManagerSystemProperty test in headless mode
>>  - Remove @SuppressWarnings(removal)
>
> src/java.desktop/share/classes/sun/font/FontManagerFactory.java line 32:
> 
>> 30:  * platform.
>> 31:  *
>> 32:  * A default implementation is given for Linux, Solaris and Windows.
> 
> Should we also remove mention of Solaris from here (due to JEP381) not being supported in mainline?

I updated the comment to mention Mac OS instead of Solaris: `A default implementation is given for Linux, Mac OS and Windows.`

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

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


From aivanov at openjdk.java.net  Fri Sep 17 13:14:46 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 17 Sep 2021 13:14:46 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction [v2]
In-Reply-To: <gBiUyt-l8eVdIjFusa3n9fOJJzGC3xikFx3TgEmt60E=.9f334dc3-cae6-4929-9cc9-d576f03adea2@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
 <TdctZLjCnE9j7nwSNF58kdpa_Q9NxzmOSZSiqU3GCW4=.5cba103a-c9d9-4960-9bea-6be6824afed4@github.com>
 <s_84IuP3_Qd9oDHWeWMuKP7FA3_ZdjvwqViEvSt9BVo=.f500d4d6-5b4d-4f4e-a692-4e29388c672c@github.com>
 <gBiUyt-l8eVdIjFusa3n9fOJJzGC3xikFx3TgEmt60E=.9f334dc3-cae6-4929-9cc9-d576f03adea2@github.com>
Message-ID: <8n7HcaSEFwcWB1V5V0iSWH4wwrHxKCtzH-_yWcdxGY8=.b8e9454b-1c0d-4910-9122-f31508ca753d@github.com>

On Fri, 17 Sep 2021 11:55:46 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

> Both final & volatile can be used it gives error "Illegal combination of modifiers: volatile & final"

That's right: both final and volatile don't make sense.

What I meant was
Suggestion:

    private static final CountDownLatch countDownLatch = new CountDownLatch(1);

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

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


From psadhukhan at openjdk.java.net  Fri Sep 17 13:25:43 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 17 Sep 2021 13:25:43 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v5]
In-Reply-To: <6u5jjyaiXosHkWDSFBC82pGsXusObx_IUBEgS7bZIUU=.614a0863-6beb-4e3d-856a-d80d2b3b4202@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <6u5jjyaiXosHkWDSFBC82pGsXusObx_IUBEgS7bZIUU=.614a0863-6beb-4e3d-856a-d80d2b3b4202@github.com>
Message-ID: <H4LOwtPgo77_k-iamqSLEVjcPGLbcO7CUzoxRAeQN9g=.17ac325d-389a-4cd5-b7b8-3474e0a101c9@github.com>

On Fri, 17 Sep 2021 12:57:18 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change Solaris default implementation to Mac OS in FontManagerFactory comment

Marked as reviewed by psadhukhan (Reviewer).

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

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


From aivanov at openjdk.java.net  Fri Sep 17 14:08:53 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 17 Sep 2021 14:08:53 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction [v3]
In-Reply-To: <GC-dXomjLJ3t7KoC0VCRYjo6Qe5znLrq9pXu0zuSjC0=.e9aa33ad-e6c0-4160-9fb7-7c772a4eb707@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
 <GC-dXomjLJ3t7KoC0VCRYjo6Qe5znLrq9pXu0zuSjC0=.e9aa33ad-e6c0-4160-9fb7-7c772a4eb707@github.com>
Message-ID: <Tt_RDE9bf9MID9M4eKPImksPTkbAUpwUudwIOVdjsgA=.2f1f527f-d9bc-4ad0-a912-0f657ebe4ff9@github.com>

On Fri, 17 Sep 2021 12:05:21 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

>> Problem : 
>> 1) Test case was failing with following exception
>> test result: Error. Parse Exception: Arguments to `manual' option not supported: yes 
>> 2) After removing =yes/no Parser exception is not seen but test UI will show and closes immediately  where the user cannot see what is on the frame. 
>> 
>> Fix : 
>> 1) Add frame to show the test instructions.
>> 2) Added timeout for the test case.
>> 3) Show the test UI until either test case gets timeout or user press pass or fail button.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified test UI

May I suggest making the component with text rendering smaller?
100 pixel height for each of the tests with text rendered at 20 and 50 instead of 50 and 80;
the entire component will have the height of 300 versus 600.

Does it make sense to a text area with instructions to make it clearer what is expected?
Will attaching a screenshot with garbled text help?

test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 49:

> 47: import java.awt.geom.RoundRectangle2D;
> 48: import java.util.concurrent.CountDownLatch;
> 49: import java.util.concurrent.TimeUnit;

I'd also suggest sorting imports alphabetically. Your IDE could do this for you with its Optimize Imports command.

test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 63:

> 61:         g2d.fillRect(0,0,getSize().width, getSize().height);
> 62: 
> 63:         test1(g.create(0, 0, 500, 200));

Not an issue, however, with the additional space the width and height are aligned in all the lines. :)

test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 120:

> 118: 
> 119:         Button failButton = new Button("Fail");
> 120:         failButton.addActionListener(e -> {

For the sake of consistency, either declare the parameter type in both cases or not at all.

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

Changes requested by aivanov (Reviewer).

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


From aivanov at openjdk.java.net  Fri Sep 17 14:16:45 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 17 Sep 2021 14:16:45 GMT
Subject: RFR: 8273913: Problem list some headful client jtreg tests that
 fail on macOS12
In-Reply-To: <IN1R_YQRdCXLs6ce0HRnt6vCE16D0z66VC8Dh_LTuFM=.30b51501-c16e-48f5-b2fc-fcf19e930405@github.com>
References: <IN1R_YQRdCXLs6ce0HRnt6vCE16D0z66VC8Dh_LTuFM=.30b51501-c16e-48f5-b2fc-fcf19e930405@github.com>
Message-ID: <7QNXhEdaSDyac0QO7zLE3mc76Zl0kZVfyRhK-R3e0ik=.e4b1087a-fb25-4431-be35-b6f98fdf5403@github.com>

On Thu, 16 Sep 2021 20:56:55 GMT, Phil Race <prr at openjdk.org> wrote:

> Simple Problem list update

Marked as reviewed by aivanov (Reviewer).

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Fri Sep 17 14:47:05 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Fri, 17 Sep 2021 14:47:05 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction [v4]
In-Reply-To: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
Message-ID: <nPaQ7qfZUUSsVl848-MI133YhMZTvl4v7_An3RzwyQ4=.a2d4db73-31fa-4514-8e1a-8388d9081612@github.com>

> Problem : 
> 1) Test case was failing with following exception
> test result: Error. Parse Exception: Arguments to `manual' option not supported: yes 
> 2) After removing =yes/no Parser exception is not seen but test UI will show and closes immediately  where the user cannot see what is on the frame. 
> 
> Fix : 
> 1) Add frame to show the test instructions.
> 2) Added timeout for the test case.
> 3) Show the test UI until either test case gets timeout or user press pass or fail button.
> 
> @shurymury

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Fixed review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5503/files
  - new: https://git.openjdk.java.net/jdk/pull/5503/files/65d34ff0..1758ddfb

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

  Stats: 35 lines in 1 file changed: 17 ins; 5 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5503.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5503/head:pull/5503

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Fri Sep 17 14:47:07 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Fri, 17 Sep 2021 14:47:07 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction [v3]
In-Reply-To: <Tt_RDE9bf9MID9M4eKPImksPTkbAUpwUudwIOVdjsgA=.2f1f527f-d9bc-4ad0-a912-0f657ebe4ff9@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
 <GC-dXomjLJ3t7KoC0VCRYjo6Qe5znLrq9pXu0zuSjC0=.e9aa33ad-e6c0-4160-9fb7-7c772a4eb707@github.com>
 <Tt_RDE9bf9MID9M4eKPImksPTkbAUpwUudwIOVdjsgA=.2f1f527f-d9bc-4ad0-a912-0f657ebe4ff9@github.com>
Message-ID: <YuRh6A-AEdgI7-K7TsZ5BrjsvWheu-pAIwQ7fdRACZE=.c662cb3b-617a-4711-aca4-6501a0e627ef@github.com>

On Fri, 17 Sep 2021 14:05:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplified test UI
>
> test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 49:
> 
>> 47: import java.awt.geom.RoundRectangle2D;
>> 48: import java.util.concurrent.CountDownLatch;
>> 49: import java.util.concurrent.TimeUnit;
> 
> I'd also suggest sorting imports alphabetically. Your IDE could do this for you with its Optimize Imports command.

Done

> test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 63:
> 
>> 61:         g2d.fillRect(0,0,getSize().width, getSize().height);
>> 62: 
>> 63:         test1(g.create(0, 0, 500, 200));
> 
> Not an issue, however, with the additional space the width and height are aligned in all the lines. :)

Fixed

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Fri Sep 17 14:47:08 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Fri, 17 Sep 2021 14:47:08 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction [v2]
In-Reply-To: <s_84IuP3_Qd9oDHWeWMuKP7FA3_ZdjvwqViEvSt9BVo=.f500d4d6-5b4d-4f4e-a692-4e29388c672c@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
 <TdctZLjCnE9j7nwSNF58kdpa_Q9NxzmOSZSiqU3GCW4=.5cba103a-c9d9-4960-9bea-6be6824afed4@github.com>
 <s_84IuP3_Qd9oDHWeWMuKP7FA3_ZdjvwqViEvSt9BVo=.f500d4d6-5b4d-4f4e-a692-4e29388c672c@github.com>
Message-ID: <-1C7dBrHYqh9vdfZ3Cv2cQl-Ye3xD5v9QWOdZMpqe24=.d45050a4-885b-47f3-b8a7-3c507e6b0b23@github.com>

On Wed, 15 Sep 2021 15:15:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed minor issue
>
> test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 59:
> 
>> 57: 
>> 58:     private static final Frame instructionFrame = new Frame();
>> 59:     private static volatile boolean testResult = false;
> 
> Assigning the default value is redundant.

done

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Fri Sep 17 14:52:42 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Fri, 17 Sep 2021 14:52:42 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction [v2]
In-Reply-To: <s_84IuP3_Qd9oDHWeWMuKP7FA3_ZdjvwqViEvSt9BVo=.f500d4d6-5b4d-4f4e-a692-4e29388c672c@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
 <TdctZLjCnE9j7nwSNF58kdpa_Q9NxzmOSZSiqU3GCW4=.5cba103a-c9d9-4960-9bea-6be6824afed4@github.com>
 <s_84IuP3_Qd9oDHWeWMuKP7FA3_ZdjvwqViEvSt9BVo=.f500d4d6-5b4d-4f4e-a692-4e29388c672c@github.com>
Message-ID: <NXRQGO41oUR7Yrj3gua0ANiFBfjyLw0qypIb9VjFvLE=.054a84ab-20de-4b60-a235-5e62e9ddcc13@github.com>

On Wed, 15 Sep 2021 15:21:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed minor issue
>
> test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 79:
> 
>> 77:         Graphics2D g2d = (Graphics2D) g;
>> 78:         g2d.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
>> 79:                 RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB);
> 
> I'd rather keep them aligned as they were. I'm fine with reformatting, though. Both variants are acceptable and there's no strong preference to either in JDK code as far as I'm aware.

fixed

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Fri Sep 17 14:52:43 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Fri, 17 Sep 2021 14:52:43 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction [v3]
In-Reply-To: <Tt_RDE9bf9MID9M4eKPImksPTkbAUpwUudwIOVdjsgA=.2f1f527f-d9bc-4ad0-a912-0f657ebe4ff9@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
 <GC-dXomjLJ3t7KoC0VCRYjo6Qe5znLrq9pXu0zuSjC0=.e9aa33ad-e6c0-4160-9fb7-7c772a4eb707@github.com>
 <Tt_RDE9bf9MID9M4eKPImksPTkbAUpwUudwIOVdjsgA=.2f1f527f-d9bc-4ad0-a912-0f657ebe4ff9@github.com>
Message-ID: <h2d-kQwDvdKVj57WfGCvSflbxnM0_3NgiCJuVaOw0Mg=.f57dc1a7-5cb3-430c-930b-11517332498d@github.com>

On Fri, 17 Sep 2021 13:15:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplified test UI
>
> test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java line 120:
> 
>> 118: 
>> 119:         Button failButton = new Button("Fail");
>> 120:         failButton.addActionListener(e -> {
> 
> For the sake of consistency, either declare the parameter type in both cases or not at all.

Fixed

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

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


From prr at openjdk.java.net  Fri Sep 17 15:04:52 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 17 Sep 2021 15:04:52 GMT
Subject: RFR: 8273913: Problem list some headful client jtreg tests that
 fail on macOS 12
In-Reply-To: <BH6wTWbsEJDpJa_L9S-QRZnbK2yyG_-OlBEDn6ODJzs=.781fda0a-708d-4cd7-a5bb-12ff09ab8f05@github.com>
References: <IN1R_YQRdCXLs6ce0HRnt6vCE16D0z66VC8Dh_LTuFM=.30b51501-c16e-48f5-b2fc-fcf19e930405@github.com>
 <BH6wTWbsEJDpJa_L9S-QRZnbK2yyG_-OlBEDn6ODJzs=.781fda0a-708d-4cd7-a5bb-12ff09ab8f05@github.com>
Message-ID: <stuJa3NHWWB-z3X8Z8aeAJSC4Hb9xmuOr2mA16ujkTI=.e2a1ce33-3fcc-44f6-870c-3fb45663d9cb@github.com>

On Fri, 17 Sep 2021 03:20:04 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> Looks good to me. BTW there is a warning for title mismatch between JBS and PR.

That is because (grumble) when a summary is longer than githib likes it splits the summary ending it with ... and puts the rest in the description. Which I expect would ALSO cause a mismatch. So I have to manually join it up again and I left an extra space.

Does anyone know why that splitting happens ?

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

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


From prr at openjdk.java.net  Fri Sep 17 15:04:53 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 17 Sep 2021 15:04:53 GMT
Subject: Integrated: 8273913: Problem list some headful client jtreg tests
 that fail on macOS 12
In-Reply-To: <IN1R_YQRdCXLs6ce0HRnt6vCE16D0z66VC8Dh_LTuFM=.30b51501-c16e-48f5-b2fc-fcf19e930405@github.com>
References: <IN1R_YQRdCXLs6ce0HRnt6vCE16D0z66VC8Dh_LTuFM=.30b51501-c16e-48f5-b2fc-fcf19e930405@github.com>
Message-ID: <rUDisEUf76DWd65gwzx2oEuWZ13iu14ppEe2xt5miKA=.9307260e-b5fe-48e6-8abe-88b67e931da7@github.com>

On Thu, 16 Sep 2021 20:56:55 GMT, Phil Race <prr at openjdk.org> wrote:

> Simple Problem list update

This pull request has now been integrated.

Changeset: 17f7a45c
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/17f7a45ce40ecf0666f282e68be1844d38a5d1c7
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8273913: Problem list some headful client jtreg tests that fail on macOS 12

Reviewed-by: pbansal, aivanov

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Fri Sep 17 16:33:10 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Fri, 17 Sep 2021 16:33:10 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v5]
In-Reply-To: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
Message-ID: <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>

> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.

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

  added check for inLiveResize in AWTWindow

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5497/files
  - new: https://git.openjdk.java.net/jdk/pull/5497/files/c50ed453..27743318

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

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Fri Sep 17 18:14:47 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Fri, 17 Sep 2021 18:14:47 GMT
Subject: Integrated: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction
In-Reply-To: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
Message-ID: <8CEp11HSt61noohGyoQYWKsQFgK5526LWSjv2np8qls=.15d9d5b8-9345-4592-a6ea-a853b8ed54a9@github.com>

On Mon, 13 Sep 2021 21:22:36 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

> Problem : 
> 1) Test case was failing with following exception
> test result: Error. Parse Exception: Arguments to `manual' option not supported: yes 
> 2) After removing =yes/no Parser exception is not seen but test UI will show and closes immediately  where the user cannot see what is on the frame. 
> 
> Fix : 
> 1) Add frame to show the test instructions.
> 2) Added timeout for the test case.
> 3) Show the test UI until either test case gets timeout or user press pass or fail button.
> 
> @shurymury

This pull request has now been integrated.

Changeset: 2a2e9190
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2a2e9190d4e866ac1b712feb0e4bb61d08e112c7
Stats:     88 lines in 1 file changed: 64 ins; 2 del; 22 mod

8273685: Remove jtreg tag manual=yesno for java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction

Reviewed-by: aivanov, pbansal

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

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


From aivanov at openjdk.java.net  Fri Sep 17 17:33:44 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 17 Sep 2021 17:33:44 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction [v4]
In-Reply-To: <nPaQ7qfZUUSsVl848-MI133YhMZTvl4v7_An3RzwyQ4=.a2d4db73-31fa-4514-8e1a-8388d9081612@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
 <nPaQ7qfZUUSsVl848-MI133YhMZTvl4v7_An3RzwyQ4=.a2d4db73-31fa-4514-8e1a-8388d9081612@github.com>
Message-ID: <HjQDS8CZzsS-YGwFVWm4cTmb7RmYKOLX8wfSzBi6BdQ=.59dce590-3cae-4f46-9115-782cbd71090c@github.com>

On Fri, 17 Sep 2021 14:47:05 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

>> Problem : 
>> 1) Test case was failing with following exception
>> test result: Error. Parse Exception: Arguments to `manual' option not supported: yes 
>> 2) After removing =yes/no Parser exception is not seen but test UI will show and closes immediately  where the user cannot see what is on the frame. 
>> 
>> Fix : 
>> 1) Add frame to show the test instructions.
>> 2) Added timeout for the test case.
>> 3) Show the test UI until either test case gets timeout or user press pass or fail button.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed review comments

Marked as reviewed by aivanov (Reviewer).

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

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


From pbansal at openjdk.java.net  Fri Sep 17 17:38:50 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 17 Sep 2021 17:38:50 GMT
Subject: RFR: 8273685 : Remove jtreg tag manual=yesno for
 java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction [v4]
In-Reply-To: <nPaQ7qfZUUSsVl848-MI133YhMZTvl4v7_An3RzwyQ4=.a2d4db73-31fa-4514-8e1a-8388d9081612@github.com>
References: <p6Yzs2u83aAQov71fSLemVZsE8SK4saTH6NYoDGklQE=.a4c7169f-0fbe-4bda-825b-192b7e2f7320@github.com>
 <nPaQ7qfZUUSsVl848-MI133YhMZTvl4v7_An3RzwyQ4=.a2d4db73-31fa-4514-8e1a-8388d9081612@github.com>
Message-ID: <A0f5r8g4IXKar9BhKMnZOVzWDqg40V-ck66iTEBHBuE=.3e57bb03-b8d1-4688-8009-e6945dcaba78@github.com>

On Fri, 17 Sep 2021 14:47:05 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

>> Problem : 
>> 1) Test case was failing with following exception
>> test result: Error. Parse Exception: Arguments to `manual' option not supported: yes 
>> 2) After removing =yes/no Parser exception is not seen but test UI will show and closes immediately  where the user cannot see what is on the frame. 
>> 
>> Fix : 
>> 1) Add frame to show the test instructions.
>> 2) Added timeout for the test case.
>> 3) Show the test UI until either test case gets timeout or user press pass or fail button.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed review comments

Marked as reviewed by pbansal (Reviewer).

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

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


From aivanov at openjdk.java.net  Fri Sep 17 19:02:46 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 17 Sep 2021 19:02:46 GMT
Subject: RFR: 8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java
 does not show instruction [v4]
In-Reply-To: <f8hdLRQ0nJp5RsOL_tL0KVMjuQvuedKJKXSsHRC18-Y=.0f00b737-d7ce-4a5e-adf7-bca3cde8af45@github.com>
References: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
 <f8hdLRQ0nJp5RsOL_tL0KVMjuQvuedKJKXSsHRC18-Y=.0f00b737-d7ce-4a5e-adf7-bca3cde8af45@github.com>
Message-ID: <sh9r91Jt0yQmrg0rcSmuGSbV-b7ogCLhugxzjS40-zA=.41c7f6bb-b0e2-45ab-8600-4925f9675758@github.com>

On Fri, 17 Sep 2021 18:59:19 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

>> 1) When the test is executed via jtreg user can see only print dialog with no instruction to the user. User has to see the test case to see the instruction and perform the test . 
>> 2) With this fix User is instructed what he/she has to do with the print dialog.
>> 3) I have added both success instruction as well as failure instruction.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - minor change in instruction
>  - Fixed test instruction

Marked as reviewed by aivanov (Reviewer).

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Fri Sep 17 18:59:23 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Fri, 17 Sep 2021 18:59:23 GMT
Subject: RFR: 8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java
 does not show instruction [v3]
In-Reply-To: <3fOT-9XmSA_XgqfmTFL6nZRlDtLec6Mg2wjmzEpuwRo=.d357cde3-65cd-4422-a48c-afb9d301c663@github.com>
References: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
 <DwlJXlrymWF2VbaclZbV0tw3KZV4KBIzk_TR7LIv21c=.4a47a752-e054-4c80-b150-6ffeeef6f1ea@github.com>
 <3fOT-9XmSA_XgqfmTFL6nZRlDtLec6Mg2wjmzEpuwRo=.d357cde3-65cd-4422-a48c-afb9d301c663@github.com>
Message-ID: <e3KN-vOEzAbtAntqprq00FvWXvKXmR_O0nMTzN4nLMk=.37ec3191-d261-4d22-852d-a9802ba51f6a@github.com>

On Fri, 17 Sep 2021 18:01:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - removed unwanted textarea.setText
>>  - minor change
>>  - Close instruction frame after clicking OK/Cancel button
>
> test/jdk/java/awt/print/Dialog/DialogCopies.java line 46:
> 
>> 44:                 Document Writer does not allow setting copies to anything but 1.
>> 45:                 If printer is installed then PrintDialog is visible increase the
>> 46:                 number of copies and press OK/Cancel button.""";
> 
> Suggestion:
> 
>                 This test requires that you have a printer.
>                 
>                 Press Cancel if your system has only virtual printers such as
>                 Microsoft Print to PDF or Microsoft XPS Document Writer since
>                 neither allows setting copies to anything but 1.
>                 
>                 If a real printer is installed, select it from the drop-down
>                 list in the Print dialog and increase the number of copies,
>                 then press OK button.""";
> 
> 
> I tried to make the instructions clearer: Press Cancel if ? . Otherwise do the following.
> 
> Maybe it's better to write _??since they don't allow setting copies to anything but 1.?_
> where ?they? refers to any virtual printer.

Changed the instruction.

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Fri Sep 17 18:59:19 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Fri, 17 Sep 2021 18:59:19 GMT
Subject: RFR: 8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java
 does not show instruction [v4]
In-Reply-To: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
References: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
Message-ID: <f8hdLRQ0nJp5RsOL_tL0KVMjuQvuedKJKXSsHRC18-Y=.0f00b737-d7ce-4a5e-adf7-bca3cde8af45@github.com>

> 1) When the test is executed via jtreg user can see only print dialog with no instruction to the user. User has to see the test case to see the instruction and perform the test . 
> 2) With this fix User is instructed what he/she has to do with the print dialog.
> 3) I have added both success instruction as well as failure instruction.
> 
> @shurymury

lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision:

 - minor change in instruction
 - Fixed test instruction

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4850/files
  - new: https://git.openjdk.java.net/jdk/pull/4850/files/2373d895..8de5ebf8

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

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

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


From aivanov at openjdk.java.net  Fri Sep 17 18:04:47 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 17 Sep 2021 18:04:47 GMT
Subject: RFR: 8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java
 does not show instruction [v3]
In-Reply-To: <DwlJXlrymWF2VbaclZbV0tw3KZV4KBIzk_TR7LIv21c=.4a47a752-e054-4c80-b150-6ffeeef6f1ea@github.com>
References: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
 <DwlJXlrymWF2VbaclZbV0tw3KZV4KBIzk_TR7LIv21c=.4a47a752-e054-4c80-b150-6ffeeef6f1ea@github.com>
Message-ID: <3fOT-9XmSA_XgqfmTFL6nZRlDtLec6Mg2wjmzEpuwRo=.d357cde3-65cd-4422-a48c-afb9d301c663@github.com>

On Thu, 16 Sep 2021 21:35:16 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

>> 1) When the test is executed via jtreg user can see only print dialog with no instruction to the user. User has to see the test case to see the instruction and perform the test . 
>> 2) With this fix User is instructed what he/she has to do with the print dialog.
>> 3) I have added both success instruction as well as failure instruction.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - removed unwanted textarea.setText
>  - minor change
>  - Close instruction frame after clicking OK/Cancel button

Marked as reviewed by aivanov (Reviewer).

test/jdk/java/awt/print/Dialog/DialogCopies.java line 46:

> 44:                 Document Writer does not allow setting copies to anything but 1.
> 45:                 If printer is installed then PrintDialog is visible increase the
> 46:                 number of copies and press OK/Cancel button.""";

Suggestion:

                This test requires that you have a printer.
                
                Press Cancel if your system has only virtual printers such as
                Microsoft Print to PDF or Microsoft XPS Document Writer since
                neither allows setting copies to anything but 1.
                
                If a real printer is installed, select it from the drop-down
                list in the Print dialog and increase the number of copies,
                then press OK button.""";


I tried to make the instructions clearer: Press Cancel if ? . Otherwise do the following.

Maybe it's better to write _??since they don't allow setting copies to anything but 1.?_
where ?they? refers to any virtual printer.

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

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


From serb at openjdk.java.net  Sat Sep 18 23:11:51 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 18 Sep 2021 23:11:51 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v5]
In-Reply-To: <6u5jjyaiXosHkWDSFBC82pGsXusObx_IUBEgS7bZIUU=.614a0863-6beb-4e3d-856a-d80d2b3b4202@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <6u5jjyaiXosHkWDSFBC82pGsXusObx_IUBEgS7bZIUU=.614a0863-6beb-4e3d-856a-d80d2b3b4202@github.com>
Message-ID: <F77vNVkD8UOYxhFVvX9ENHtn3LifDTQgWg91foNlv5Q=.9adf9a7f-dd14-4cba-aece-6d1ff557ed28@github.com>

On Fri, 17 Sep 2021 12:57:18 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change Solaris default implementation to Mac OS in FontManagerFactory comment

src/java.desktop/share/classes/sun/font/FontManagerFactory.java line 37:

> 35: 
> 36:     /** Our singleton instance. */
> 37:     private static volatile FontManager instance = null;

It is not necessary to initialize it to null here, there is ongoing effort to delete such initializations:
https://github.com/openjdk/jdk/pull/5197

src/java.desktop/share/classes/sun/font/FontManagerFactory.java line 46:

> 44:     public static FontManager getInstance() {
> 45: 
> 46:         if (instance == null) {

You can improve it a little bit further and read the volatile field only once in the common path. Read to local->check-> init local and field -> return local.

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

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


From serb at openjdk.java.net  Sat Sep 18 23:11:51 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 18 Sep 2021 23:11:51 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v3]
In-Reply-To: <fcO7I3jva-NsKRtZ8xincfMFWddRfhAVAoYe8eyCSPk=.c624343e-16b6-46c4-a611-0ba07a078933@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>
 <bL30zfna64rA2ZnE13AWOxSltCndsjTeZMEvobsKeFk=.440e635a-14f4-47fd-acdc-b663a7024fee@github.com>
 <fcO7I3jva-NsKRtZ8xincfMFWddRfhAVAoYe8eyCSPk=.c624343e-16b6-46c4-a611-0ba07a078933@github.com>
Message-ID: <bvWxapV1WMSAxODiaoNa42dhWxutfsuq58HiPzVlA2Y=.8c95abbe-ca01-4cd1-bb78-b3b4edc6200c@github.com>

On Fri, 17 Sep 2021 12:42:51 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/font/FontManagerFactory.java line 55:
>> 
>>> 53:      */
>>> 54:     @SuppressWarnings("removal")
>>> 55:     public static synchronized FontManager getInstance() {
>> 
>> Just an idea, since the method became so small can we use DLC here instead of synchronised static method?
>
> The method `FontManagerFactory.getInstance()` is updated to use DLC.
> 
> I used synchronization on FontManagerFactory.class in the first check to be consistent with the previous behavior where synchronization was on the `FontManagerFactory.getInstance()` method.
> 
> What about to use a static nested class singleton? It could look like:
> 
> public final class FontManagerFactory {
> 
>     public static FontManager getInstance() {
>         return FontManagerHolder.instance;
>     }
> 
>     private static class FontManagerHolder {
>         private static final FontManager instance = PlatformFontInfo.createFontManager();
>     }
> }

The SunFontManager constructor and its subclasses seem too big, and potentially throw some exceptions and this will ruin the holder idiom since all subsequent calls to this method will fail.

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

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


From pbansal at openjdk.java.net  Mon Sep 20 06:22:48 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 20 Sep 2021 06:22:48 GMT
Subject: RFR: 8273907: Cleanup redundant Math.max/min calls in
 DefaultHighlighter
In-Reply-To: <VJylGXYSbxLWIVFDE4vQGoRvhS7T0XqELx_eQvVYgKY=.96d1c0b9-0e90-4d19-ac99-925ba3e39185@github.com>
References: <VJylGXYSbxLWIVFDE4vQGoRvhS7T0XqELx_eQvVYgKY=.96d1c0b9-0e90-4d19-ac99-925ba3e39185@github.com>
Message-ID: <VkEm4oyja-Hz-GoUwOK-L2pCC3y1dvuIQq4e9HWN5_s=.7c66a157-129a-4d73-8cd4-48a92a43d2dc@github.com>

On Thu, 16 Sep 2021 08:08:07 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> This calls are redundant, because order of `p0` and `p1` is checked in method pre-conditions.
> Checks were added under [JDK-6771184](https://bugs.openjdk.java.net/browse/JDK-6771184) - https://github.com/openjdk/jdk/commit/79ed0e75ceeb

Looks fine to me. Please wait for a second review before committing.

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

Marked as reviewed by pbansal (Reviewer).

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


From alexsch at openjdk.java.net  Mon Sep 20 11:26:13 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Mon, 20 Sep 2021 11:26:13 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v6]
In-Reply-To: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
Message-ID: <kKADnqLKuC0mHwnI55cKBATkmnbIyOigk5n24LEiyRI=.1fe20a0e-4a28-426e-97c2-424750881dd2@github.com>

> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
> 
> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
> 
> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
> 
> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.

Alexander Scherbatiy has updated the pull request incrementally with two additional commits since the last revision:

 - Use Double-check idiom for lazy initialization of instance fields with local variable
 - Remove unnecessary explicit initialization of volatile variable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5517/files
  - new: https://git.openjdk.java.net/jdk/pull/5517/files/91109b34..d965a1bc

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

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

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


From alexsch at openjdk.java.net  Mon Sep 20 11:26:19 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Mon, 20 Sep 2021 11:26:19 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v5]
In-Reply-To: <F77vNVkD8UOYxhFVvX9ENHtn3LifDTQgWg91foNlv5Q=.9adf9a7f-dd14-4cba-aece-6d1ff557ed28@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <6u5jjyaiXosHkWDSFBC82pGsXusObx_IUBEgS7bZIUU=.614a0863-6beb-4e3d-856a-d80d2b3b4202@github.com>
 <F77vNVkD8UOYxhFVvX9ENHtn3LifDTQgWg91foNlv5Q=.9adf9a7f-dd14-4cba-aece-6d1ff557ed28@github.com>
Message-ID: <YNb44ZR7z1y4I00GJ6Usn8NJxUcYAkhJUmQUTx_ta9Q=.d0c5569a-23e4-4f44-9cdf-8be4012785eb@github.com>

On Sat, 18 Sep 2021 22:51:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change Solaris default implementation to Mac OS in FontManagerFactory comment
>
> src/java.desktop/share/classes/sun/font/FontManagerFactory.java line 37:
> 
>> 35: 
>> 36:     /** Our singleton instance. */
>> 37:     private static volatile FontManager instance = null;
> 
> It is not necessary to initialize it to null here, there is ongoing effort to delete such initializations:
> https://github.com/openjdk/jdk/pull/5197

The initialization to null is removed.

> src/java.desktop/share/classes/sun/font/FontManagerFactory.java line 46:
> 
>> 44:     public static FontManager getInstance() {
>> 45: 
>> 46:         if (instance == null) {
> 
> You can improve it a little bit further and read the volatile field only once in the common path. Read to local->check-> init local and field -> return local.

The `getInstance()` method is updated to store the volatile field to local variable.

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

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


From alexsch at openjdk.java.net  Mon Sep 20 11:30:49 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Mon, 20 Sep 2021 11:30:49 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v3]
In-Reply-To: <bvWxapV1WMSAxODiaoNa42dhWxutfsuq58HiPzVlA2Y=.8c95abbe-ca01-4cd1-bb78-b3b4edc6200c@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>
 <bL30zfna64rA2ZnE13AWOxSltCndsjTeZMEvobsKeFk=.440e635a-14f4-47fd-acdc-b663a7024fee@github.com>
 <fcO7I3jva-NsKRtZ8xincfMFWddRfhAVAoYe8eyCSPk=.c624343e-16b6-46c4-a611-0ba07a078933@github.com>
 <bvWxapV1WMSAxODiaoNa42dhWxutfsuq58HiPzVlA2Y=.8c95abbe-ca01-4cd1-bb78-b3b4edc6200c@github.com>
Message-ID: <Tm_yosjTPCevWRYyy1vhdcyXvWaHGM65M4yYI6VJ8qE=.bee1acfb-9f3b-431a-94fa-f1d12257af92@github.com>

On Sat, 18 Sep 2021 23:08:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The method `FontManagerFactory.getInstance()` is updated to use DLC.
>> 
>> I used synchronization on FontManagerFactory.class in the first check to be consistent with the previous behavior where synchronization was on the `FontManagerFactory.getInstance()` method.
>> 
>> What about to use a static nested class singleton? It could look like:
>> 
>> public final class FontManagerFactory {
>> 
>>     public static FontManager getInstance() {
>>         return FontManagerHolder.instance;
>>     }
>> 
>>     private static class FontManagerHolder {
>>         private static final FontManager instance = PlatformFontInfo.createFontManager();
>>     }
>> }
>
> The SunFontManager constructor and its subclasses seem too big, and potentially throw some exceptions and this will ruin the holder idiom since all subsequent calls to this method will fail.

I wrote a simple example which uses DLC and lazy initialization holder class idioms. The FontManager is only created when it is accessed the first time via the getInstance() method in both cases and they both fail if an exception is thrown during the class initialization. Are there special restrictions on the class loading time in holder idiom?

public class FontManagerFactory {

    private static volatile FontManager instance;

    public static FontManager getInstanceDLC() {

        FontManager result = instance;
        if (result == null) {
            synchronized (FontManagerFactory.class) {
                result = instance;
                if (result == null) {
                    instance = result = new FontManager("One", "Two", "Three");
                }
            }
        }
        return result;
    }

    public static FontManager getInstanceHolder() {
        return FontManagerHolder.instance;
    }


    public static void main(String[] args) {
        String lazyInitializationIdiom = args[0];
        System.out.printf("Use lazy initialization idiom: %s%n", lazyInitializationIdiom);
        if ("DLC".equals(args[0])) {
            System.out.printf("DLC FontManager instance: %s%n", getInstanceDLC());
        } else if ("Holder".equals(args[0])) {
            System.out.printf("Lazy Initialization Holder FontManager instance: %s%n", getInstanceHolder());
        }
    }

    private static class FontManagerHolder {
        private static final FontManager instance = new FontManager("One", "Two", "Three");
    }
}

class FontManager {
    public FontManager(String... args) {
        System.out.println(args[5]);
    }
}

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

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


From github.com+741251+turbanoff at openjdk.java.net  Mon Sep 20 11:58:53 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 20 Sep 2021 11:58:53 GMT
Subject: RFR: 8272756: Remove unnecessary explicit initialization of
 volatile variables in java.desktop
In-Reply-To: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
Message-ID: <LSqf1R0_ikoaW6UNtFVzuZQcEkjaVsuz35QzPNTVMIc=.394b7c0a-c381-4b75-a85e-ed09cfda7044@github.com>

On Fri, 20 Aug 2021 09:41:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> This is a continuation of
> 
> - https://bugs.openjdk.java.net/browse/JDK-6736490
> - https://bugs.openjdk.java.net/browse/JDK-8035284
> - https://bugs.openjdk.java.net/browse/JDK-8145680
> - https://bugs.openjdk.java.net/browse/JDK-8251548
> 
> As mentioned in JDK-6736490:
> 
> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._

As I can see there are a few more zero-initializations of volatiles. Are they intentionally skipped?
1. sun.lwawt.macosx.CPlatformEmbeddedFrame#screenX
2. sun.lwawt.macosx.CPlatformEmbeddedFrame#screenY
3. sun.lwawt.macosx.CWarningWindow#currentIcon
4. com.sun.media.sound.SoftSynthesizer.WeakAudioStream#silent_samples

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

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


From github.com+2996845+bokken at openjdk.java.net  Mon Sep 20 13:28:54 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Mon, 20 Sep 2021 13:28:54 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v6]
In-Reply-To: <kKADnqLKuC0mHwnI55cKBATkmnbIyOigk5n24LEiyRI=.1fe20a0e-4a28-426e-97c2-424750881dd2@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <kKADnqLKuC0mHwnI55cKBATkmnbIyOigk5n24LEiyRI=.1fe20a0e-4a28-426e-97c2-424750881dd2@github.com>
Message-ID: <9Q4byOp7VN0zUUXE8ktmKpl-kl4eyfCQNxarxVySmGU=.27f7542c-88eb-40a6-8c5c-cf3e51e971a9@github.com>

On Mon, 20 Sep 2021 11:26:13 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use Double-check idiom for lazy initialization of instance fields with local variable
>  - Remove unnecessary explicit initialization of volatile variable

src/java.desktop/share/classes/sun/font/FontManagerFactory.java line 37:

> 35: 
> 36:     /** Our singleton instance. */
> 37:     private static volatile FontManager instance;

Consider to instead of DCL to use the holder class pattern:


private static final class DeferredLoader {
  public static final FontManager INSTANCE = PlatformFontInfo.createFontManager();
}

public static FontManager getInstance() {
  return DeferredLoader.INSTANCE;
}

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

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


From aivanov at openjdk.java.net  Mon Sep 20 13:50:02 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 20 Sep 2021 13:50:02 GMT
Subject: RFR: 8273907: Cleanup redundant Math.max/min calls in
 DefaultHighlighter
In-Reply-To: <VJylGXYSbxLWIVFDE4vQGoRvhS7T0XqELx_eQvVYgKY=.96d1c0b9-0e90-4d19-ac99-925ba3e39185@github.com>
References: <VJylGXYSbxLWIVFDE4vQGoRvhS7T0XqELx_eQvVYgKY=.96d1c0b9-0e90-4d19-ac99-925ba3e39185@github.com>
Message-ID: <Cs_b6qKDkOUwUPAEkXXo6d0NwAXek4Qn_SmfeSA592g=.29bcd15f-7538-4479-82b7-7e01c57f33cd@github.com>

On Thu, 16 Sep 2021 08:08:07 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> This calls are redundant, because order of `p0` and `p1` is checked in method pre-conditions.
> Checks were added under [JDK-6771184](https://bugs.openjdk.java.net/browse/JDK-6771184) - https://github.com/openjdk/jdk/commit/79ed0e75ceeb

Marked as reviewed by aivanov (Reviewer).

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Mon Sep 20 14:11:07 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Mon, 20 Sep 2021 14:11:07 GMT
Subject: Integrated: 8270609: [TESTBUG]
 java/awt/print/Dialog/DialogCopies.java does not show instruction
In-Reply-To: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
References: <ZhI31BjF6tqnVW1M1zITecjsTFInuURFqqLQ4qnjl-8=.5103ec99-fa27-4c79-bfe0-fc18f44fac22@github.com>
Message-ID: <uuRKi3Oprh3jot_D7axEUIrfY0LuSGOlkY6ZqP_DBZk=.d38da263-56d3-4a31-a0ed-88144ef61742@github.com>

On Tue, 20 Jul 2021 23:54:20 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

> 1) When the test is executed via jtreg user can see only print dialog with no instruction to the user. User has to see the test case to see the instruction and perform the test . 
> 2) With this fix User is instructed what he/she has to do with the print dialog.
> 3) I have added both success instruction as well as failure instruction.
> 
> @shurymury

This pull request has now been integrated.

Changeset: 4da45c43
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4da45c430139fe66fab020c2f96686dc9cf26a97
Stats:     56 lines in 1 file changed: 33 ins; 0 del; 23 mod

8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java does not show instruction

Reviewed-by: aivanov

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

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


From prr at openjdk.java.net  Mon Sep 20 16:49:51 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 20 Sep 2021 16:49:51 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v6]
In-Reply-To: <kKADnqLKuC0mHwnI55cKBATkmnbIyOigk5n24LEiyRI=.1fe20a0e-4a28-426e-97c2-424750881dd2@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <kKADnqLKuC0mHwnI55cKBATkmnbIyOigk5n24LEiyRI=.1fe20a0e-4a28-426e-97c2-424750881dd2@github.com>
Message-ID: <Cb9LRCg5rV1kHrfbXDNX5K_9BLonuIDW209mKah3GUA=.864ba89e-282e-45dd-bef7-f1c6afa4e1e4@github.com>

On Mon, 20 Sep 2021 11:26:13 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use Double-check idiom for lazy initialization of instance fields with local variable
>  - Remove unnecessary explicit initialization of volatile variable

Marked as reviewed by prr (Reviewer).

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

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


From github.com+2996845+bokken at openjdk.java.net  Mon Sep 20 17:02:13 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Mon, 20 Sep 2021 17:02:13 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v3]
In-Reply-To: <Tm_yosjTPCevWRYyy1vhdcyXvWaHGM65M4yYI6VJ8qE=.bee1acfb-9f3b-431a-94fa-f1d12257af92@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>
 <bL30zfna64rA2ZnE13AWOxSltCndsjTeZMEvobsKeFk=.440e635a-14f4-47fd-acdc-b663a7024fee@github.com>
 <fcO7I3jva-NsKRtZ8xincfMFWddRfhAVAoYe8eyCSPk=.c624343e-16b6-46c4-a611-0ba07a078933@github.com>
 <bvWxapV1WMSAxODiaoNa42dhWxutfsuq58HiPzVlA2Y=.8c95abbe-ca01-4cd1-bb78-b3b4edc6200c@github.com>
 <Tm_yosjTPCevWRYyy1vhdcyXvWaHGM65M4yYI6VJ8qE=.bee1acfb-9f3b-431a-94fa-f1d12257af92@github.com>
Message-ID: <5X3StSdc5ub4iAVb4qyKBbosK51hyOVaIEPJRbJQYAc=.edae1140-5a46-4cd9-b4e8-f60e473be27e@github.com>

On Mon, 20 Sep 2021 11:27:32 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> The SunFontManager constructor and its subclasses seem too big, and potentially throw some exceptions and this will ruin the holder idiom since all subsequent calls to this method will fail.
>
> I wrote a simple example which uses DLC and lazy initialization holder class idioms. The FontManager is only created when it is accessed the first time via the getInstance() method in both cases and they both fail if an exception is thrown during the class initialization.
> 
> Is the problem with Holder idiom that it throws `ExceptionInInitializerError` which contains the original exception as the cause whereas with DLC the original exception is directly thrown?
> 
> public class FontManagerFactory {
> 
>     private static volatile FontManager instance;
> 
>     public static FontManager getInstanceDLC() {
> 
>         FontManager result = instance;
>         if (result == null) {
>             synchronized (FontManagerFactory.class) {
>                 result = instance;
>                 if (result == null) {
>                     instance = result = new FontManager("One", "Two", "Three");
>                 }
>             }
>         }
>         return result;
>     }
> 
>     public static FontManager getInstanceHolder() {
>         return FontManagerHolder.instance;
>     }
> 
> 
>     public static void main(String[] args) {
>         String lazyInitializationIdiom = args[0];
>         System.out.printf("Use lazy initialization idiom: %s%n", lazyInitializationIdiom);
>         if ("DLC".equals(args[0])) {
>             System.out.printf("DLC FontManager instance: %s%n", getInstanceDLC());
>         } else if ("Holder".equals(args[0])) {
>             System.out.printf("Lazy Initialization Holder FontManager instance: %s%n", getInstanceHolder());
>         }
>     }
> 
>     private static class FontManagerHolder {
>         private static final FontManager instance = new FontManager("One", "Two", "Three");
>     }
> }
> 
> class FontManager {
>     public FontManager(String... args) {
>         System.out.println(args[5]);
>     }
> }
> ``` 
> DLC:
> 
> java FontManagerFactory DLC
> Use lazy initialization idiom: DLC
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 5 out of bounds for length 3
> 	at FontManager.<init>(FontManagerFactory.java:41)
> 	at FontManagerFactory.getInstanceDLC(FontManagerFactory.java:12)
> 	at FontManagerFactory.main(FontManagerFactory.java:28)
> 
> Hodler:
> 
> java FontManagerFactory Holder
> Use lazy initialization idiom: Holder
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at FontManagerFactory.getInstanceHolder(FontManagerFactory.java:20)
> 	at FontManagerFactory.main(FontManagerFactory.java:30)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 5 out of bounds for length 3
> 	at FontManager.<init>(FontManagerFactory.java:41)
> 	at FontManagerFactory$FontManagerHolder.<clinit>(FontManagerFactory.java:35)
> 	... 2 more

Does that stack trace difference really matter?
if so, you could wrap the `return FontManagerHolder.instance;` in a try/catch that throws that caused by:


try {
  return FontManagerHolder.instance;
} catch (java.lang.ExceptionInInitializerError e) {
  final Throwable cause = e.getCause();
  if (cause instanceof RuntimeException re) {
    throw re;
  }
  //could wrap in IllegalStateException or just throw the error
}


If this getInstance method is called with any frequency, getting rid of the volatile access each time is a nice bonus.

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

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


From serb at openjdk.java.net  Mon Sep 20 17:02:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 20 Sep 2021 17:02:14 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v3]
In-Reply-To: <5X3StSdc5ub4iAVb4qyKBbosK51hyOVaIEPJRbJQYAc=.edae1140-5a46-4cd9-b4e8-f60e473be27e@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>
 <bL30zfna64rA2ZnE13AWOxSltCndsjTeZMEvobsKeFk=.440e635a-14f4-47fd-acdc-b663a7024fee@github.com>
 <fcO7I3jva-NsKRtZ8xincfMFWddRfhAVAoYe8eyCSPk=.c624343e-16b6-46c4-a611-0ba07a078933@github.com>
 <bvWxapV1WMSAxODiaoNa42dhWxutfsuq58HiPzVlA2Y=.8c95abbe-ca01-4cd1-bb78-b3b4edc6200c@github.com>
 <Tm_yosjTPCevWRYyy1vhdcyXvWaHGM65M4yYI6VJ8qE=.bee1acfb-9f3b-431a-94fa-f1d12257af92@github.com>
 <5X3StSdc5ub4iAVb4qyKBbosK51hyOVaIEPJRbJQYAc=.edae1140-5a46-4cd9-b4e8-f60e473be27e@github.com>
Message-ID: <F5hXXgpNGckOEnjlPnfRv8NFloysmRy3zFd31l7EqxY=.b4d2c0ab-2779-4b70-be97-89380527dec2@github.com>

On Mon, 20 Sep 2021 16:55:49 GMT, Brett Okken <github.com+2996845+bokken at openjdk.org> wrote:

>> I wrote a simple example which uses DLC and lazy initialization holder class idioms. The FontManager is only created when it is accessed the first time via the getInstance() method in both cases and they both fail if an exception is thrown during the class initialization.
>> 
>> Is the problem with Holder idiom that it throws `ExceptionInInitializerError` which contains the original exception as the cause whereas with DLC the original exception is directly thrown?
>> 
>> public class FontManagerFactory {
>> 
>>     private static volatile FontManager instance;
>> 
>>     public static FontManager getInstanceDLC() {
>> 
>>         FontManager result = instance;
>>         if (result == null) {
>>             synchronized (FontManagerFactory.class) {
>>                 result = instance;
>>                 if (result == null) {
>>                     instance = result = new FontManager("One", "Two", "Three");
>>                 }
>>             }
>>         }
>>         return result;
>>     }
>> 
>>     public static FontManager getInstanceHolder() {
>>         return FontManagerHolder.instance;
>>     }
>> 
>> 
>>     public static void main(String[] args) {
>>         String lazyInitializationIdiom = args[0];
>>         System.out.printf("Use lazy initialization idiom: %s%n", lazyInitializationIdiom);
>>         if ("DLC".equals(args[0])) {
>>             System.out.printf("DLC FontManager instance: %s%n", getInstanceDLC());
>>         } else if ("Holder".equals(args[0])) {
>>             System.out.printf("Lazy Initialization Holder FontManager instance: %s%n", getInstanceHolder());
>>         }
>>     }
>> 
>>     private static class FontManagerHolder {
>>         private static final FontManager instance = new FontManager("One", "Two", "Three");
>>     }
>> }
>> 
>> class FontManager {
>>     public FontManager(String... args) {
>>         System.out.println(args[5]);
>>     }
>> }
>> ``` 
>> DLC:
>> 
>> java FontManagerFactory DLC
>> Use lazy initialization idiom: DLC
>> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 5 out of bounds for length 3
>> 	at FontManager.<init>(FontManagerFactory.java:41)
>> 	at FontManagerFactory.getInstanceDLC(FontManagerFactory.java:12)
>> 	at FontManagerFactory.main(FontManagerFactory.java:28)
>> 
>> Hodler:
>> 
>> java FontManagerFactory Holder
>> Use lazy initialization idiom: Holder
>> Exception in thread "main" java.lang.ExceptionInInitializerError
>> 	at FontManagerFactory.getInstanceHolder(FontManagerFactory.java:20)
>> 	at FontManagerFactory.main(FontManagerFactory.java:30)
>> Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 5 out of bounds for length 3
>> 	at FontManager.<init>(FontManagerFactory.java:41)
>> 	at FontManagerFactory$FontManagerHolder.<clinit>(FontManagerFactory.java:35)
>> 	... 2 more
>
> Does that stack trace difference really matter?
> if so, you could wrap the `return FontManagerHolder.instance;` in a try/catch that throws that caused by:
> 
> 
> try {
>   return FontManagerHolder.instance;
> } catch (java.lang.ExceptionInInitializerError e) {
>   final Throwable cause = e.getCause();
>   if (cause instanceof RuntimeException re) {
>     throw re;
>   }
>   //could wrap in IllegalStateException or just throw the error
> }
> 
> 
> If this getInstance method is called with any frequency, getting rid of the volatile access each time is a nice bonus.

The difference is that Holder will fail that way forever, while the DLC have a chance to resurrect on next call.

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

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


From azvegint at openjdk.java.net  Mon Sep 20 17:14:54 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 20 Sep 2021 17:14:54 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v6]
In-Reply-To: <kKADnqLKuC0mHwnI55cKBATkmnbIyOigk5n24LEiyRI=.1fe20a0e-4a28-426e-97c2-424750881dd2@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <kKADnqLKuC0mHwnI55cKBATkmnbIyOigk5n24LEiyRI=.1fe20a0e-4a28-426e-97c2-424750881dd2@github.com>
Message-ID: <XyPAA42JC1nKAMKaSALFdbsWtDD9HibNtp9qcIoMdI0=.55802387-3e15-41f0-b842-aa137e3cbff9@github.com>

On Mon, 20 Sep 2021 11:26:13 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use Double-check idiom for lazy initialization of instance fields with local variable
>  - Remove unnecessary explicit initialization of volatile variable

Marked as reviewed by azvegint (Reviewer).

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

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


From github.com+2996845+bokken at openjdk.java.net  Mon Sep 20 17:18:55 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Mon, 20 Sep 2021 17:18:55 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v3]
In-Reply-To: <F5hXXgpNGckOEnjlPnfRv8NFloysmRy3zFd31l7EqxY=.b4d2c0ab-2779-4b70-be97-89380527dec2@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>
 <bL30zfna64rA2ZnE13AWOxSltCndsjTeZMEvobsKeFk=.440e635a-14f4-47fd-acdc-b663a7024fee@github.com>
 <fcO7I3jva-NsKRtZ8xincfMFWddRfhAVAoYe8eyCSPk=.c624343e-16b6-46c4-a611-0ba07a078933@github.com>
 <bvWxapV1WMSAxODiaoNa42dhWxutfsuq58HiPzVlA2Y=.8c95abbe-ca01-4cd1-bb78-b3b4edc6200c@github.com>
 <Tm_yosjTPCevWRYyy1vhdcyXvWaHGM65M4yYI6VJ8qE=.bee1acfb-9f3b-431a-94fa-f1d12257af92@github.com>
 <5X3StSdc5ub4iAVb4qyKBbosK51hyOVaIEPJRbJQYAc=.edae1140-5a46-4cd9-b4e8-f60e473be27e@github.com>
 <F5hXXgpNGckOEnjlPnfRv8NFloysmRy3zFd31l7EqxY=.b4d2c0ab-2779-4b70-be97-89380527dec2@github.com>
Message-ID: <Lz2Qe0-Mic0EQ5kXdwP3zRWt_1S9qXpeRI4S4teyD7o=.a3d0c01b-7272-4e7f-95e1-1d657ca49709@github.com>

On Mon, 20 Sep 2021 16:58:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Does that stack trace difference really matter?
>> if so, you could wrap the `return FontManagerHolder.instance;` in a try/catch that throws that caused by:
>> 
>> 
>> try {
>>   return FontManagerHolder.instance;
>> } catch (java.lang.ExceptionInInitializerError e) {
>>   final Throwable cause = e.getCause();
>>   if (cause instanceof RuntimeException re) {
>>     throw re;
>>   }
>>   //could wrap in IllegalStateException or just throw the error
>> }
>> 
>> 
>> If this getInstance method is called with any frequency, getting rid of the volatile access each time is a nice bonus.
>
> The difference is that Holder will fail that way forever, while the DLC have a chance to resurrect on next call.

So I guess the question is whether there is a valid transitory failure use case?

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

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


From azvegint at openjdk.java.net  Mon Sep 20 17:20:52 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 20 Sep 2021 17:20:52 GMT
Subject: RFR: 8273907: Cleanup redundant Math.max/min calls in
 DefaultHighlighter
In-Reply-To: <VJylGXYSbxLWIVFDE4vQGoRvhS7T0XqELx_eQvVYgKY=.96d1c0b9-0e90-4d19-ac99-925ba3e39185@github.com>
References: <VJylGXYSbxLWIVFDE4vQGoRvhS7T0XqELx_eQvVYgKY=.96d1c0b9-0e90-4d19-ac99-925ba3e39185@github.com>
Message-ID: <T36vZQUGjQzpNcvmV5jZ8FOIGeI0wGcPRaqdm-dqPTA=.c16ed6d2-295b-49e0-ac62-3e3fa0ba1d97@github.com>

On Thu, 16 Sep 2021 08:08:07 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> This calls are redundant, because order of `p0` and `p1` is checked in method pre-conditions.
> Checks were added under [JDK-6771184](https://bugs.openjdk.java.net/browse/JDK-6771184) - https://github.com/openjdk/jdk/commit/79ed0e75ceeb

Marked as reviewed by azvegint (Reviewer).

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

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


From github.com+741251+turbanoff at openjdk.java.net  Mon Sep 20 17:27:02 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 20 Sep 2021 17:27:02 GMT
Subject: Integrated: 8273907: Cleanup redundant Math.max/min calls in
 DefaultHighlighter
In-Reply-To: <VJylGXYSbxLWIVFDE4vQGoRvhS7T0XqELx_eQvVYgKY=.96d1c0b9-0e90-4d19-ac99-925ba3e39185@github.com>
References: <VJylGXYSbxLWIVFDE4vQGoRvhS7T0XqELx_eQvVYgKY=.96d1c0b9-0e90-4d19-ac99-925ba3e39185@github.com>
Message-ID: <3BeZ3GzVGETUarCDZpnMBbExecdv6RDVhlAxgemixM0=.1ad20331-12a9-47a3-be41-b590c5318a06@github.com>

On Thu, 16 Sep 2021 08:08:07 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> This calls are redundant, because order of `p0` and `p1` is checked in method pre-conditions.
> Checks were added under [JDK-6771184](https://bugs.openjdk.java.net/browse/JDK-6771184) - https://github.com/openjdk/jdk/commit/79ed0e75ceeb

This pull request has now been integrated.

Changeset: b3b4b1cc
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b3b4b1cc218d4c02809eb7fd4d83d541acfbd9bd
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8273907: Cleanup redundant Math.max/min calls in DefaultHighlighter

Reviewed-by: pbansal, aivanov, azvegint

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

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


From github.com+741251+turbanoff at openjdk.java.net  Mon Sep 20 17:47:28 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 20 Sep 2021 17:47:28 GMT
Subject: RFR: 8274016: Replace 'for' cycles with iterator with enhanced-for in
 java.desktop
Message-ID: <J_99QqIiSe6JHaUJP4vgaeN0GAA5Cebu0ycpQupFiJo=.bcb78736-629a-4ca8-8262-0fee90bbf06d@github.com>

There are few places in code where manual `for` loop is used with Iterator to iterate over Collection.
Instead of manual `for` cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.

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

Commit messages:
 - [PATCH] Replace 'for' cycles with iterator with enhanced-for in java.desktop

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

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


From shade at openjdk.java.net  Mon Sep 20 17:47:28 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 20 Sep 2021 17:47:28 GMT
Subject: RFR: 8274016: Replace 'for' cycles with iterator with
 enhanced-for in java.desktop
In-Reply-To: <J_99QqIiSe6JHaUJP4vgaeN0GAA5Cebu0ycpQupFiJo=.bcb78736-629a-4ca8-8262-0fee90bbf06d@github.com>
References: <J_99QqIiSe6JHaUJP4vgaeN0GAA5Cebu0ycpQupFiJo=.bcb78736-629a-4ca8-8262-0fee90bbf06d@github.com>
Message-ID: <RZLoTg8ocR0zQJ8vZ0x1c86qNKd5B4hDbPpVyf17A1I=.c78c4bef-bdda-423a-a095-a8d8aa1726dc@github.com>

On Sun, 19 Sep 2021 10:13:49 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are few places in code where manual `for` loop is used with Iterator to iterate over Collection.
> Instead of manual `for` cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.

Once again, you have access to JIRA, so you can submit the RFEs for all these PRs yourself :)

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

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


From aivanov at openjdk.java.net  Mon Sep 20 17:50:50 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 20 Sep 2021 17:50:50 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v3]
In-Reply-To: <Lz2Qe0-Mic0EQ5kXdwP3zRWt_1S9qXpeRI4S4teyD7o=.a3d0c01b-7272-4e7f-95e1-1d657ca49709@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>
 <bL30zfna64rA2ZnE13AWOxSltCndsjTeZMEvobsKeFk=.440e635a-14f4-47fd-acdc-b663a7024fee@github.com>
 <fcO7I3jva-NsKRtZ8xincfMFWddRfhAVAoYe8eyCSPk=.c624343e-16b6-46c4-a611-0ba07a078933@github.com>
 <bvWxapV1WMSAxODiaoNa42dhWxutfsuq58HiPzVlA2Y=.8c95abbe-ca01-4cd1-bb78-b3b4edc6200c@github.com>
 <Tm_yosjTPCevWRYyy1vhdcyXvWaHGM65M4yYI6VJ8qE=.bee1acfb-9f3b-431a-94fa-f1d12257af92@github.com>
 <5X3StSdc5ub4iAVb4qyKBbosK51hyOVaIEPJRbJQYAc=.edae1140-5a46-4cd9-b4e8-f60e473be27e@github.com>
 <F5hXXgpNGckOEnjlPnfRv8NFloysmRy3zFd31l7EqxY=.b4d2c0ab-2779-4b70-be97-89380527dec2@github.com>
 <Lz2Qe0-Mic0EQ5kXdwP3zRWt_1S9qXpeRI4S4teyD7o=.a3d0c01b-7272-4e7f-95e1-1d657ca49709@github.com>
Message-ID: <Aa1khQD2orgKmsWAzAu8PCneDYbp_9NB30RzVre-pYk=.df66d07f-ad12-4607-8319-44886a84f06e@github.com>

On Mon, 20 Sep 2021 17:15:48 GMT, Brett Okken <github.com+2996845+bokken at openjdk.org> wrote:

>> The difference is that Holder will fail that way forever, while the DLC have a chance to resurrect on next call.
>
> So I guess the question is whether there is a valid transitory failure use case?

> The difference is that Holder will fail that way forever, while the DLC have a chance to resurrect on next call.

Is it really possible that next call will succeed after the previous one failed with an exception?

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

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


From aivanov at openjdk.java.net  Mon Sep 20 17:59:54 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 20 Sep 2021 17:59:54 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v6]
In-Reply-To: <kKADnqLKuC0mHwnI55cKBATkmnbIyOigk5n24LEiyRI=.1fe20a0e-4a28-426e-97c2-424750881dd2@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <kKADnqLKuC0mHwnI55cKBATkmnbIyOigk5n24LEiyRI=.1fe20a0e-4a28-426e-97c2-424750881dd2@github.com>
Message-ID: <WkjPXV9h6M_KkFtFwbYMC-Skt6alYOfSIZT0P3lPliM=.c48850ea-01c4-463c-a985-4b07ded16f03@github.com>

On Mon, 20 Sep 2021 11:26:13 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use Double-check idiom for lazy initialization of instance fields with local variable
>  - Remove unnecessary explicit initialization of volatile variable

Should `PlatformFontInfo` classes be marked `final`? They're not supposed to be subclassed.

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

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


From serb at openjdk.java.net  Mon Sep 20 19:47:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 20 Sep 2021 19:47:40 GMT
Subject: RFR: 8273887: [macos]
 java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java timed out
Message-ID: <cKJVY2fIW2jLzbXoEfrMl7yxvbCp9Ey_EvHs97e1AzY=.058327ce-e472-47b8-b1bd-2fb9651e137f@github.com>

This testcase creates two threads for each tag, one thread continuously change the profiles, the second thread use that profiles for color conversion. The first thread executed no more than 15 seconds, and the second thread should be stopped when the first thread end.

Unfortunately on the slow systems the second thread may occupy all cpu time, and will run forever since the first thread will not be able make even one iteration to stop the second thread. I was able to reproduce it by changing implementation of color conversion so it will do x10 more work.

The fix add a check to stop the second thread after 15 seconds.

@lawrence-andrew please take a look and confirm that it will work fine on your system

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

Commit messages:
 - Update MTTransformReplacedProfile.java

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Mon Sep 20 20:36:51 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Mon, 20 Sep 2021 20:36:51 GMT
Subject: RFR: 8273887: [macos]
 java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java timed out
In-Reply-To: <cKJVY2fIW2jLzbXoEfrMl7yxvbCp9Ey_EvHs97e1AzY=.058327ce-e472-47b8-b1bd-2fb9651e137f@github.com>
References: <cKJVY2fIW2jLzbXoEfrMl7yxvbCp9Ey_EvHs97e1AzY=.058327ce-e472-47b8-b1bd-2fb9651e137f@github.com>
Message-ID: <c81J0fhZQpQ8wwRmX0sbxM7Qkd8EFaF_RcV0RVx7KIc=.aeec77d7-2ac2-4324-b88d-99c056e5de8b@github.com>

On Mon, 20 Sep 2021 19:29:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This testcase creates two threads for each tag, one thread continuously change the profiles, the second thread use that profiles for color conversion. The first thread executed no more than 15 seconds, and the second thread should be stopped when the first thread end.
> 
> Unfortunately on the slow systems the second thread may occupy all cpu time, and will run forever since the first thread will not be able make even one iteration to stop the second thread. I was able to reproduce it by changing implementation of color conversion so it will do x10 more work.
> 
> The fix add a check to stop the second thread after 15 seconds.
> 
> @lawrence-andrew please take a look and confirm that it will work fine on your system

Run the fixed testcase on the same host where the timeout was reproduced and the issue is not reproduced after running the test case several time and one more observation is test case run finish running faster.
Looks good to me!

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

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


From serb at openjdk.java.net  Mon Sep 20 20:57:44 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 20 Sep 2021 20:57:44 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v3]
In-Reply-To: <Aa1khQD2orgKmsWAzAu8PCneDYbp_9NB30RzVre-pYk=.df66d07f-ad12-4607-8319-44886a84f06e@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <ojlN6Ear6sfAsiDUvFSD54m6hirYfnPl-ARhf8o4dmQ=.56d53508-29b6-40b1-ad01-eba03be2ddf3@github.com>
 <bL30zfna64rA2ZnE13AWOxSltCndsjTeZMEvobsKeFk=.440e635a-14f4-47fd-acdc-b663a7024fee@github.com>
 <fcO7I3jva-NsKRtZ8xincfMFWddRfhAVAoYe8eyCSPk=.c624343e-16b6-46c4-a611-0ba07a078933@github.com>
 <bvWxapV1WMSAxODiaoNa42dhWxutfsuq58HiPzVlA2Y=.8c95abbe-ca01-4cd1-bb78-b3b4edc6200c@github.com>
 <Tm_yosjTPCevWRYyy1vhdcyXvWaHGM65M4yYI6VJ8qE=.bee1acfb-9f3b-431a-94fa-f1d12257af92@github.com>
 <5X3StSdc5ub4iAVb4qyKBbosK51hyOVaIEPJRbJQYAc=.edae1140-5a46-4cd9-b4e8-f60e473be27e@github.com>
 <F5hXXgpNGckOEnjlPnfRv8NFloysmRy3zFd31l7EqxY=.b4d2c0ab-2779-4b70-be97-89380527dec2@github.com>
 <Lz2Qe0-Mic0EQ5kXdwP3zRWt_1S9qXpeRI4S4teyD7o=.a3d0c01b-7272-4e7f-95e1-1d657ca49709@github.com>
 <Aa1khQD2orgKmsWAzAu8PCneDYbp_9NB30RzVre-pYk=.df66d07f-ad12-4607-8319-44886a84f06e@github.com>
Message-ID: <q6nC-N9hU8QnkgvYTWwSpLjhf84ykUJeqQzGJUGVSmc=.cf7f651c-6359-477d-b537-73476f0e06e2@github.com>

On Mon, 20 Sep 2021 17:47:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> So I guess the question is whether there is a valid transitory failure use case?
>
>> The difference is that Holder will fail that way forever, while the DLC have a chance to resurrect on next call.
> 
> Is it really possible that next call will succeed after the previous one failed with an exception?

It may fail when one thread got OOM, but later another/this one will work fine. We can use a holder if there will be some real benefits from using it, but DCL is just simpler and safer in this particular case.

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

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


From serb at openjdk.java.net  Mon Sep 20 21:01:44 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 20 Sep 2021 21:01:44 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v6]
In-Reply-To: <kKADnqLKuC0mHwnI55cKBATkmnbIyOigk5n24LEiyRI=.1fe20a0e-4a28-426e-97c2-424750881dd2@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <kKADnqLKuC0mHwnI55cKBATkmnbIyOigk5n24LEiyRI=.1fe20a0e-4a28-426e-97c2-424750881dd2@github.com>
Message-ID: <Rdgz7T6OG3N1cy70dqVfVGv_LCmbBLgBI25PYZHvyus=.006c6f63-c7bf-4448-b38f-3f8577021ba6@github.com>

On Mon, 20 Sep 2021 11:26:13 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use Double-check idiom for lazy initialization of instance fields with local variable
>  - Remove unnecessary explicit initialization of volatile variable

Marked as reviewed by serb (Reviewer).

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

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


From aivanov at openjdk.java.net  Mon Sep 20 21:06:45 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 20 Sep 2021 21:06:45 GMT
Subject: RFR: 8273887: [macos]
 java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java timed out
In-Reply-To: <cKJVY2fIW2jLzbXoEfrMl7yxvbCp9Ey_EvHs97e1AzY=.058327ce-e472-47b8-b1bd-2fb9651e137f@github.com>
References: <cKJVY2fIW2jLzbXoEfrMl7yxvbCp9Ey_EvHs97e1AzY=.058327ce-e472-47b8-b1bd-2fb9651e137f@github.com>
Message-ID: <ePoPY9-627PuYggaq3woNqptYyk6EYRVUw_xvSYa2aQ=.2703d704-6889-4a14-97d0-020c7530276a@github.com>

On Mon, 20 Sep 2021 19:29:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This testcase creates two threads for each tag, one thread continuously change the profiles, the second thread use that profiles for color conversion. The first thread executed no more than 15 seconds, and the second thread should be stopped when the first thread end.
> 
> Unfortunately on the slow systems the second thread may occupy all cpu time, and will run forever since the first thread will not be able make even one iteration to stop the second thread. I was able to reproduce it by changing implementation of color conversion so it will do x10 more work.
> 
> The fix add a check to stop the second thread after 15 seconds.
> 
> @lawrence-andrew please take a look and confirm that it will work fine on your system

Marked as reviewed by aivanov (Reviewer).

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

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


From serb at openjdk.java.net  Mon Sep 20 21:28:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 20 Sep 2021 21:28:54 GMT
Subject: Integrated: 8273887: [macos]
 java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java timed out
In-Reply-To: <cKJVY2fIW2jLzbXoEfrMl7yxvbCp9Ey_EvHs97e1AzY=.058327ce-e472-47b8-b1bd-2fb9651e137f@github.com>
References: <cKJVY2fIW2jLzbXoEfrMl7yxvbCp9Ey_EvHs97e1AzY=.058327ce-e472-47b8-b1bd-2fb9651e137f@github.com>
Message-ID: <SNyjuSOEf7YETnonDyL4wtyUfbrtWPoX-OTp68Q7GVc=.832298db-4060-4399-9f6a-c9b844c7e3ff@github.com>

On Mon, 20 Sep 2021 19:29:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This testcase creates two threads for each tag, one thread continuously change the profiles, the second thread use that profiles for color conversion. The first thread executed no more than 15 seconds, and the second thread should be stopped when the first thread end.
> 
> Unfortunately on the slow systems the second thread may occupy all cpu time, and will run forever since the first thread will not be able make even one iteration to stop the second thread. I was able to reproduce it by changing implementation of color conversion so it will do x10 more work.
> 
> The fix add a check to stop the second thread after 15 seconds.
> 
> @lawrence-andrew please take a look and confirm that it will work fine on your system

This pull request has now been integrated.

Changeset: 1bd11a7f
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1bd11a7f2ca433f4aa9c545a20960e0778ec545e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8273887: [macos] java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java timed out

Reviewed-by: aivanov

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Mon Sep 20 21:44:40 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Mon, 20 Sep 2021 21:44:40 GMT
Subject: RFR: 8274029 : Remove jtreg tag manual=yesno for
 java/awt/print/Dialog/DialogOrient.java
Message-ID: <Ro_fn0IJMpEylrSDc18KA2ja2kqn9pXV2VGJVNYILBw=.32f3e969-5ea3-4739-81dc-84199b86ab50@github.com>

Problem : Testcase was failing with parser exception 
test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno 
Fix : Removed =yesno and run the testcase and Test UI ( instruction and print dialog ) is visible

@shurymury

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

Commit messages:
 - 8274029 : Remove jtreg tag manual=yesno for java/awt/print/Dialog/DialogOrient.java

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

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


From kizune at openjdk.java.net  Tue Sep 21 03:21:49 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 21 Sep 2021 03:21:49 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation [v3]
In-Reply-To: <OYD5nXxsk7Rb6orDwB2ulOOxfuMu93OjB-O998fFF3M=.9f8b878e-988e-4a19-b06b-5d45214565e8@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
 <OYD5nXxsk7Rb6orDwB2ulOOxfuMu93OjB-O998fFF3M=.9f8b878e-988e-4a19-b06b-5d45214565e8@github.com>
Message-ID: <Oxv32wx-NfWfjHSEgatuEw5R3-co4kjS8D92LQ4jkBQ=.d3dec987-d01e-4999-bebc-d58e1527cf42@github.com>

On Tue, 14 Sep 2021 15:50:34 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> We've extended the current implementation of TableAccessibility to make sure that individual cells are voiced when navigating with the keyboard.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   It is not clear why we should manage columns without children. Would it be better if you investigate it separately, and here you do not remove this method?

The biggest problem i have is that the new logic reverts the mechanic of the selection mode of the table - when no selection mode set it announces the content of all the cells in the current row and when either row or column selection mode is set it only announces the content of a single cell. Also when only cell selection is allowed it announces row as dimmed which is strange.

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Tue Sep 21 03:33:59 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Tue, 21 Sep 2021 03:33:59 GMT
Subject: RFR: 8274032 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java & show test UI
Message-ID: <3PeA1uV6v8hufkV83MCl4ADDpKRSqoM39m8vkkuOdak=.d30c9535-1d20-49d9-8df1-d48bae3fd483@github.com>

Problem : 
1) Testcase was failing due to parse exception yesno
2) After removing yesno tag test frame and immediately get disposed

Fix : 
1) Removed yesno tag
2) Show the test frame with pass, fail button.  Now user can click on the `print' button to show the print dialog and take the print out and compare the print with the graphics rendered on the frame. Click either on the 'Pass' or 'Fail' button to make the pass or fail also clicking the 'Pass' or 'Fail' closes the test frame.
3) Added the timeout If not interaction is performed on the test frame.

@shurymury

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

Commit messages:
 - 8274032 : Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java & show test UI

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

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


From alexsch at openjdk.java.net  Tue Sep 21 08:01:32 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Tue, 21 Sep 2021 08:01:32 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v7]
In-Reply-To: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
Message-ID: <5jBqYks3WA75ZwinZ5VAyAQ6EvKQHIZtMTO8UaSUs34=.42d55022-2106-4c2c-80da-90bb8fa88010@github.com>

> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
> 
> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
> 
> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
> 
> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.

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

  Add final keyword to PlatformFontInfo class

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5517/files
  - new: https://git.openjdk.java.net/jdk/pull/5517/files/d965a1bc..f4d0b8a5

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

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

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


From alexsch at openjdk.java.net  Tue Sep 21 08:01:33 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Tue, 21 Sep 2021 08:01:33 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v6]
In-Reply-To: <WkjPXV9h6M_KkFtFwbYMC-Skt6alYOfSIZT0P3lPliM=.c48850ea-01c4-463c-a985-4b07ded16f03@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <kKADnqLKuC0mHwnI55cKBATkmnbIyOigk5n24LEiyRI=.1fe20a0e-4a28-426e-97c2-424750881dd2@github.com>
 <WkjPXV9h6M_KkFtFwbYMC-Skt6alYOfSIZT0P3lPliM=.c48850ea-01c4-463c-a985-4b07ded16f03@github.com>
Message-ID: <0qZrdKN5SA4HJpzbaSp4mnmKo5plqO9HZdZq5CSMays=.d7667160-f31e-4820-ab56-32f5b975459f@github.com>

On Mon, 20 Sep 2021 17:56:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Should `PlatformFontInfo` classes be marked `final`? They're not supposed to be subclassed.

The final keyword is added to the `PlatformFontInfo` clases.

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

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


From aivanov at openjdk.java.net  Tue Sep 21 08:04:55 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 21 Sep 2021 08:04:55 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v7]
In-Reply-To: <5jBqYks3WA75ZwinZ5VAyAQ6EvKQHIZtMTO8UaSUs34=.42d55022-2106-4c2c-80da-90bb8fa88010@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <5jBqYks3WA75ZwinZ5VAyAQ6EvKQHIZtMTO8UaSUs34=.42d55022-2106-4c2c-80da-90bb8fa88010@github.com>
Message-ID: <lcs0zZ8XulSW_Otk6EoXcnGSg6lRUMNqdBD33etUK1Y=.0be38047-486c-4ca0-9b4e-4dfc921efe8e@github.com>

On Tue, 21 Sep 2021 08:01:32 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add final keyword to PlatformFontInfo class

Marked as reviewed by aivanov (Reviewer).

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

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


From pbansal at openjdk.java.net  Tue Sep 21 08:16:56 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 21 Sep 2021 08:16:56 GMT
Subject: RFR: 8274032 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java & show test UI
In-Reply-To: <3PeA1uV6v8hufkV83MCl4ADDpKRSqoM39m8vkkuOdak=.d30c9535-1d20-49d9-8df1-d48bae3fd483@github.com>
References: <3PeA1uV6v8hufkV83MCl4ADDpKRSqoM39m8vkkuOdak=.d30c9535-1d20-49d9-8df1-d48bae3fd483@github.com>
Message-ID: <3Y88eDO5fj2oGjOVnyrMrRJuPTln751sDwlVUf_HTNU=.c1bace71-b8ff-460c-b668-8dee6f1a9116@github.com>

On Tue, 21 Sep 2021 03:24:24 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

> Problem : 
> 1) Testcase was failing due to parse exception yesno
> 2) After removing yesno tag test frame and immediately get disposed
> 
> Fix : 
> 1) Removed yesno tag
> 2) Show the test frame with pass, fail button.  Now user can click on the `print' button to show the print dialog and take the print out and compare the print with the graphics rendered on the frame. Click either on the 'Pass' or 'Fail' button to make the pass or fail also clicking the 'Pass' or 'Fail' closes the test frame.
> 3) Added the timeout If not interaction is performed on the test frame.
> 
> @shurymury

test/jdk/java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java line 83:

> 81: import static java.awt.image.BufferedImage.TYPE_INT_RGB;
> 82: import static java.awt.image.BufferedImage.TYPE_USHORT_555_RGB;
> 83: import static java.awt.image.BufferedImage.TYPE_USHORT_GRAY;

Thats lot of static imports from just two classes. This just looks weird. Is it recommended practice to do? I am not saying this is wrong as you are removing wild card imports, but it just does not look good to have so many statement for importing from two classes.

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

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


From kizune at openjdk.java.net  Tue Sep 21 09:02:53 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 21 Sep 2021 09:02:53 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v4]
In-Reply-To: <eciHLB1bKgy02_eV0d-Y-RiECZshzMxHakK2ZaUhFk0=.298fe17f-0913-4f1e-8eba-4587c28b05b1@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <eciHLB1bKgy02_eV0d-Y-RiECZshzMxHakK2ZaUhFk0=.298fe17f-0913-4f1e-8eba-4587c28b05b1@github.com>
Message-ID: <ZM4mZ3AxOmywSXnOnNwY-evQuqo3gOjGx_ehjEnhZTM=.efd35f37-dbd4-4d16-b0b7-771e94b2e6aa@github.com>

On Thu, 1 Jul 2021 12:19:53 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8268764: Update copy-right year

Marked as reviewed by kizune (Reviewer).

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

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


From github.com+36081106+savoptik at openjdk.java.net  Tue Sep 21 10:07:05 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 21 Sep 2021 10:07:05 GMT
Subject: RFR: 8274056 JavaAccessibilityUtilities leaks JNI objects
Message-ID: <S-rk740tZEr-qx6elUnlswUCNWdTerWB0_rCbhAeZQQ=.69921a93-8150-453d-b439-fc54415e4a8d@github.com>

8274056 JavaAccessibilityUtilities leaks JNI objects

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

Commit messages:
 - 8274056 JavaAccessibilityUtilities leaks JNI objects - Java Bug System

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

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


From github.com+10835776+stsypanov at openjdk.java.net  Tue Sep 21 11:37:42 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 21 Sep 2021 11:37:42 GMT
Subject: RFR: 8272756: Remove unnecessary explicit initialization of
 volatile variables in java.desktop [v2]
In-Reply-To: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
Message-ID: <csenEuZ1tDdW2ikoycJqLBg7s4XAYKYPVl56wtmE6Sk=.68d6bdd5-adcd-473f-b086-a3b9e202df9b@github.com>

> This is a continuation of
> 
> - https://bugs.openjdk.java.net/browse/JDK-6736490
> - https://bugs.openjdk.java.net/browse/JDK-8035284
> - https://bugs.openjdk.java.net/browse/JDK-8145680
> - https://bugs.openjdk.java.net/browse/JDK-8251548
> 
> As mentioned in JDK-6736490:
> 
> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._

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

  8272756: Remove unnecessary explicit initialization of volatile fields in java.desktop

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5197/files
  - new: https://git.openjdk.java.net/jdk/pull/5197/files/d06aff5b..a3558d0a

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

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

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


From aivanov at openjdk.java.net  Tue Sep 21 11:44:46 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 21 Sep 2021 11:44:46 GMT
Subject: RFR: 8274056 JavaAccessibilityUtilities leaks JNI objects
In-Reply-To: <S-rk740tZEr-qx6elUnlswUCNWdTerWB0_rCbhAeZQQ=.69921a93-8150-453d-b439-fc54415e4a8d@github.com>
References: <S-rk740tZEr-qx6elUnlswUCNWdTerWB0_rCbhAeZQQ=.69921a93-8150-453d-b439-fc54415e4a8d@github.com>
Message-ID: <8O0YFj8ge6Hew2vOOHFdB3xnw2wnCZGDaxh14YMVkk0=.1ec6a5ac-da2a-44fc-8067-b58db84b889c@github.com>

On Tue, 21 Sep 2021 09:51:48 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> 8274056 JavaAccessibilityUtilities leaks JNI objects

Marked as reviewed by aivanov (Reviewer).

I would appreciate if you add more details in the description of the PR. Copying that from the JBS would be enough.

I expect @forantar will also take a look and approve.

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

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


From github.com+10835776+stsypanov at openjdk.java.net  Tue Sep 21 11:44:49 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 21 Sep 2021 11:44:49 GMT
Subject: RFR: 8272756: Remove unnecessary explicit initialization of
 volatile variables in java.desktop
In-Reply-To: <LSqf1R0_ikoaW6UNtFVzuZQcEkjaVsuz35QzPNTVMIc=.394b7c0a-c381-4b75-a85e-ed09cfda7044@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <LSqf1R0_ikoaW6UNtFVzuZQcEkjaVsuz35QzPNTVMIc=.394b7c0a-c381-4b75-a85e-ed09cfda7044@github.com>
Message-ID: <hXYYNMkrGNw0iu4zOR5wd1nO-iAbd2vcxB5oAtLpF2Y=.83091259-71e5-4721-8e9f-6e4e52105eee@github.com>

On Mon, 20 Sep 2021 11:55:43 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> This is a continuation of
>> 
>> - https://bugs.openjdk.java.net/browse/JDK-6736490
>> - https://bugs.openjdk.java.net/browse/JDK-8035284
>> - https://bugs.openjdk.java.net/browse/JDK-8145680
>> - https://bugs.openjdk.java.net/browse/JDK-8251548
>> 
>> As mentioned in JDK-6736490:
>> 
>> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._
>
> As I can see there are a few more zero-initializations of volatiles. Are they intentionally skipped?
> 1. sun.lwawt.macosx.CPlatformEmbeddedFrame#screenX
> 2. sun.lwawt.macosx.CPlatformEmbeddedFrame#screenY
> 3. sun.lwawt.macosx.CWarningWindow#currentIcon
> 4. com.sun.media.sound.SoftSynthesizer.WeakAudioStream#silent_samples

@turbanoff nice catch! I've missed them in my original commit, no intention here. I've included them either.

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

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


From ant at openjdk.java.net  Tue Sep 21 11:53:01 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Tue, 21 Sep 2021 11:53:01 GMT
Subject: RFR: 8274056 JavaAccessibilityUtilities leaks JNI objects
In-Reply-To: <S-rk740tZEr-qx6elUnlswUCNWdTerWB0_rCbhAeZQQ=.69921a93-8150-453d-b439-fc54415e4a8d@github.com>
References: <S-rk740tZEr-qx6elUnlswUCNWdTerWB0_rCbhAeZQQ=.69921a93-8150-453d-b439-fc54415e4a8d@github.com>
Message-ID: <KDoCsi4NeNSxIOgE2_xELkedp55iEAsx_G7_JTqty0s=.7bac8431-bc39-47b5-b540-55da5dee5506@github.com>

On Tue, 21 Sep 2021 09:51:48 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> The following methods in JavaAccessibilityUtilities leak JNI objects got from up-calls to Java: 
> - getAxComponentSize 
> - getJavaRole 
> 
> Also, getAxComponentSize calls jm_getSize on wrong class.

Marked as reviewed by ant (Reviewer).

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

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


From github.com+741251+turbanoff at openjdk.java.net  Tue Sep 21 11:52:57 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 21 Sep 2021 11:52:57 GMT
Subject: RFR: 8272756: Remove unnecessary explicit initialization of
 volatile variables in java.desktop [v2]
In-Reply-To: <csenEuZ1tDdW2ikoycJqLBg7s4XAYKYPVl56wtmE6Sk=.68d6bdd5-adcd-473f-b086-a3b9e202df9b@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <csenEuZ1tDdW2ikoycJqLBg7s4XAYKYPVl56wtmE6Sk=.68d6bdd5-adcd-473f-b086-a3b9e202df9b@github.com>
Message-ID: <InTvtP4Xvp4zfn7wdTts49EBZFsBiprwAM5GwiQPkr4=.8953184f-6520-43f0-8333-29d39813a54b@github.com>

On Tue, 21 Sep 2021 11:37:42 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> This is a continuation of
>> 
>> - https://bugs.openjdk.java.net/browse/JDK-6736490
>> - https://bugs.openjdk.java.net/browse/JDK-8035284
>> - https://bugs.openjdk.java.net/browse/JDK-8145680
>> - https://bugs.openjdk.java.net/browse/JDK-8251548
>> 
>> As mentioned in JDK-6736490:
>> 
>> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272756: Remove unnecessary explicit initialization of volatile fields in java.desktop

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

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

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


From psadhukhan at openjdk.java.net  Tue Sep 21 11:53:09 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 21 Sep 2021 11:53:09 GMT
Subject: RFR: 8274070: Rectify problemlist platform for failing test on macos12
Message-ID: <3yIDDATTyVJ4ahRPivLNc37iR91SHOcrnUee1P50DZA=.d99bd4c8-d631-487e-9486-832c57042abd@github.com>

It was mentioned in JDK-8273618

> java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java is timing out on a macOS 12 aarch64 (an Apple Silicon Mac Mini) system.
> I'm not seeing the same on x64.

but it is problemlisted for macos-all..It should be problemlisted only for macos-aarch64. 
Mach5 jobs (listed in JBS) also shows this test pass for macos-x64 but fails for macos-aarch64

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

Commit messages:
 - 8274070: Rectify problemlist platform for failing test on macos12

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Tue Sep 21 11:58:49 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Tue, 21 Sep 2021 11:58:49 GMT
Subject: RFR: 8274032 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java & show test UI
In-Reply-To: <3Y88eDO5fj2oGjOVnyrMrRJuPTln751sDwlVUf_HTNU=.c1bace71-b8ff-460c-b668-8dee6f1a9116@github.com>
References: <3PeA1uV6v8hufkV83MCl4ADDpKRSqoM39m8vkkuOdak=.d30c9535-1d20-49d9-8df1-d48bae3fd483@github.com>
 <3Y88eDO5fj2oGjOVnyrMrRJuPTln751sDwlVUf_HTNU=.c1bace71-b8ff-460c-b668-8dee6f1a9116@github.com>
Message-ID: <Ftwyh_54-fzF7qOa7dKUDH7NxSWrtsI0K78xIWvtg1o=.9f7a8fd9-2c27-4813-b632-0f6c27a48dd5@github.com>

On Tue, 21 Sep 2021 08:13:41 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Problem : 
>> 1) Testcase was failing due to parse exception yesno
>> 2) After removing yesno tag test frame and immediately get disposed
>> 
>> Fix : 
>> 1) Removed yesno tag
>> 2) Show the test frame with pass, fail button.  Now user can click on the `print' button to show the print dialog and take the print out and compare the print with the graphics rendered on the frame. Click either on the 'Pass' or 'Fail' button to make the pass or fail also clicking the 'Pass' or 'Fail' closes the test frame.
>> 3) Added the timeout If not interaction is performed on the test frame.
>> 
>> @shurymury
>
> test/jdk/java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java line 83:
> 
>> 81: import static java.awt.image.BufferedImage.TYPE_INT_RGB;
>> 82: import static java.awt.image.BufferedImage.TYPE_USHORT_555_RGB;
>> 83: import static java.awt.image.BufferedImage.TYPE_USHORT_GRAY;
> 
> Thats lot of static imports from just two classes. This just looks weird. Is it recommended practice to do? I am not saying this is wrong as you are removing wild card imports, but it just does not look good to have so many statement for importing from two classes.

In most of the test cases wild card is removed and its replaced with each class import statement.

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

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


From github.com+36081106+savoptik at openjdk.java.net  Tue Sep 21 12:41:48 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 21 Sep 2021 12:41:48 GMT
Subject: Integrated: 8274056 JavaAccessibilityUtilities leaks JNI objects
In-Reply-To: <S-rk740tZEr-qx6elUnlswUCNWdTerWB0_rCbhAeZQQ=.69921a93-8150-453d-b439-fc54415e4a8d@github.com>
References: <S-rk740tZEr-qx6elUnlswUCNWdTerWB0_rCbhAeZQQ=.69921a93-8150-453d-b439-fc54415e4a8d@github.com>
Message-ID: <Is1s6noHWNO989YAn8WFsku6wFMhu8R0sJnCHwD8tfs=.b326b0d6-ce20-49c7-a5c3-6091219e5ef3@github.com>

On Tue, 21 Sep 2021 09:51:48 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> The following methods in JavaAccessibilityUtilities leak JNI objects got from up-calls to Java: 
> - getAxComponentSize 
> - getJavaRole 
> 
> Also, getAxComponentSize calls jm_getSize on wrong class.

This pull request has now been integrated.

Changeset: 42d5d2ab
Author:    Artem Semenov <Artem.Semenov at jetbrains.com>
Committer: Anton Tarasov <ant at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/42d5d2abaad8a88a5e1326ea8b4494aeb8b5748b
Stats:     8 lines in 1 file changed: 5 ins; 0 del; 3 mod

8274056: JavaAccessibilityUtilities leaks JNI objects

Reviewed-by: aivanov, ant

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Tue Sep 21 13:59:08 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Tue, 21 Sep 2021 13:59:08 GMT
Subject: RFR: 8274032 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java & show test UI [v2]
In-Reply-To: <3PeA1uV6v8hufkV83MCl4ADDpKRSqoM39m8vkkuOdak=.d30c9535-1d20-49d9-8df1-d48bae3fd483@github.com>
References: <3PeA1uV6v8hufkV83MCl4ADDpKRSqoM39m8vkkuOdak=.d30c9535-1d20-49d9-8df1-d48bae3fd483@github.com>
Message-ID: <fT1a-KWwBBLNvg13OKKaqLsLrKIXVT3Gf-yIhEIrJmI=.020c14b4-dd2f-463e-ac28-cb3e47d0fc66@github.com>

> Problem : 
> 1) Testcase was failing due to parse exception yesno
> 2) After removing yesno tag test frame and immediately get disposed
> 
> Fix : 
> 1) Removed yesno tag
> 2) Show the test frame with pass, fail button.  Now user can click on the `print' button to show the print dialog and take the print out and compare the print with the graphics rendered on the frame. Click either on the 'Pass' or 'Fail' button to make the pass or fail also clicking the 'Pass' or 'Fail' closes the test frame.
> 3) Added the timeout If not interaction is performed on the test frame.
> 
> @shurymury

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Add wild character for static imports

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5595/files
  - new: https://git.openjdk.java.net/jdk/pull/5595/files/924167f9..98a9e315

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

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

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


From github.com+87324768+lawrence-andrew at openjdk.java.net  Tue Sep 21 13:59:10 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Tue, 21 Sep 2021 13:59:10 GMT
Subject: RFR: 8274032 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java & show test UI [v2]
In-Reply-To: <Ftwyh_54-fzF7qOa7dKUDH7NxSWrtsI0K78xIWvtg1o=.9f7a8fd9-2c27-4813-b632-0f6c27a48dd5@github.com>
References: <3PeA1uV6v8hufkV83MCl4ADDpKRSqoM39m8vkkuOdak=.d30c9535-1d20-49d9-8df1-d48bae3fd483@github.com>
 <3Y88eDO5fj2oGjOVnyrMrRJuPTln751sDwlVUf_HTNU=.c1bace71-b8ff-460c-b668-8dee6f1a9116@github.com>
 <Ftwyh_54-fzF7qOa7dKUDH7NxSWrtsI0K78xIWvtg1o=.9f7a8fd9-2c27-4813-b632-0f6c27a48dd5@github.com>
Message-ID: <qIau9CjzTkmBQxnq5RniSOdYcp0voNb3c0GPykPzOKE=.7e658abb-2958-4fdd-9908-72df310fed16@github.com>

On Tue, 21 Sep 2021 11:56:07 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

>> test/jdk/java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java line 83:
>> 
>>> 81: import static java.awt.image.BufferedImage.TYPE_INT_RGB;
>>> 82: import static java.awt.image.BufferedImage.TYPE_USHORT_555_RGB;
>>> 83: import static java.awt.image.BufferedImage.TYPE_USHORT_GRAY;
>> 
>> Thats lot of static imports from just two classes. This just looks weird. Is it recommended practice to do? I am not saying this is wrong as you are removing wild card imports, but it just does not look good to have so many statement for importing from two classes.
>
> In most of the test cases wild card is removed and its replaced with each class import statement.

Found the java doc about the static import. In this case we can use a wild card instead of importing all the static imports. 
https://docs.oracle.com/javase/7/docs/technotes/guides/language/static-import.html

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

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


From azvegint at openjdk.java.net  Tue Sep 21 14:01:35 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 21 Sep 2021 14:01:35 GMT
Subject: RFR: 8274070: Rectify problemlist platform for failing test on
 macos12
In-Reply-To: <3yIDDATTyVJ4ahRPivLNc37iR91SHOcrnUee1P50DZA=.d99bd4c8-d631-487e-9486-832c57042abd@github.com>
References: <3yIDDATTyVJ4ahRPivLNc37iR91SHOcrnUee1P50DZA=.d99bd4c8-d631-487e-9486-832c57042abd@github.com>
Message-ID: <5BC_94qEeULssXzPGK-LBN6mDOKdDMC5M2vWE3Sn1RI=.b43d4deb-acc3-4a22-9a44-232aa6ace4a9@github.com>

On Tue, 21 Sep 2021 11:39:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It was mentioned in JDK-8273618
> 
>> java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java is timing out on a macOS 12 aarch64 (an Apple Silicon Mac Mini) system.
>> I'm not seeing the same on x64.
> 
> but it is problemlisted for macos-all..It should be problemlisted only for macos-aarch64. 
> Mach5 jobs (listed in JBS) also shows this test pass for macos-x64 but fails for macos-aarch64

Marked as reviewed by azvegint (Reviewer).

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Tue Sep 21 18:10:50 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Tue, 21 Sep 2021 18:10:50 GMT
Subject: RFR: 8262945: [macos] Regression Manual Test for Key Events Fails
Message-ID: <LhSIteG6WssDHH2if3oeA-0qLZGhxfqb11JyTC4EPh8=.b8b62eb4-a50c-4eb2-98c7-6f122f87d08b@github.com>

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.

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

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

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

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


From kizune at openjdk.java.net  Tue Sep 21 18:33:31 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 21 Sep 2021 18:33:31 GMT
Subject: RFR: 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: <2m45n2EZBuiIDKblC2F7fDmclmR22rT8E4veLyOjtKM=.72bbdd94-b6d6-4777-a1cb-1edac88130e3@github.com>

On Tue, 21 Sep 2021 18:00:13 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> 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.

src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m line 483:

> 481:             *keyLocation = java_awt_event_KeyEvent_KEY_LOCATION_STANDARD;
> 482:             return;
> 483:         } else if([lang isEqualToString:@"ru"]) {

Does it affect only Russian locale? What about other non-Latin locales? Seems little bit too narrow of a fix.

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

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


From kizune at openjdk.java.net  Tue Sep 21 18:51:37 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 21 Sep 2021 18:51:37 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v5]
In-Reply-To: <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
Message-ID: <oRzKEKnAfPW9dUhWK8wMNm9LcOfmnZOXbXni8JQ_PFY=.ec88a243-a6a2-4a3c-85f1-e77e71218a95@github.com>

On Fri, 17 Sep 2021 16:33:10 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added check for inLiveResize in AWTWindow

Marked as reviewed by kizune (Reviewer).

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

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


From serb at openjdk.java.net  Tue Sep 21 19:18:32 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 21 Sep 2021 19:18:32 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v5]
In-Reply-To: <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
Message-ID: <BzrNR0VeMIegZ8yA0nFYkG9GGaVl6mHfgbs_vCjxwT8=.b85ff14c-2265-4f97-a5cb-e2c2b9d2af53@github.com>

On Fri, 17 Sep 2021 16:33:10 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added check for inLiveResize in AWTWindow

src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 659:

> 657:     if (![self.nsWindow inLiveResize]) {
> 658:         [AWTWindow synthesizeMouseEnteredExitedEventsForAllWindows];
> 659:     }

Are you sure that inLiveResize is only set when the user resizes the window? What happens if the user will move the window to the fullscreen or maximize it(by clicking on the title/buttons), will the inLiveResize be set to true or not?

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

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


From prr at openjdk.java.net  Tue Sep 21 22:41:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 21 Sep 2021 22:41:57 GMT
Subject: RFR: 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: <bR0e6I30DQA0kaSi-xqH-yt8d1r3wfpH2DYAy3SzwOk=.cbc2bcd7-259b-4da6-9166-96a34091b213@github.com>

On Tue, 21 Sep 2021 18:00:13 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> 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.

src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m line 471:

> 469:             lang = languages;
> 470:         }
> 471: 

This may become irrelevant if the fix changes, as it well might, but I'm not sure what to make of line 469 above.

the check "If (languages .." implies that there's a chance languages may be null  and I'm a bit
surprised the compiler doesn't complain about the assignment of an NSArray* to an NSString*
and then later on you dereference lang (line 483)

src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m line 485:

> 483:         } else if([lang isEqualToString:@"ru"]) {
> 484:             // checking for Russian characters
> 485:             offset += 0x01000000;

where did this value come from ?
And I agree adding only russian looks odd. Actually I have no idea (and am curious) why the submitter was actually testing a russian layout keyboard.
Are we doing something weird, or does macOS really make developers have to understand every single supported language -> keyboard mapping ?
Is there a better (more generic) way ?
Is this the ONLY place we'd need to add understanding of Russian ? If there's more it would not be worth doing it just here.

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

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


From prr at openjdk.java.net  Tue Sep 21 22:48:00 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 21 Sep 2021 22:48:00 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v5]
In-Reply-To: <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
Message-ID: <EZF13WntcCeeYONvKhcu47BaDFcT7KOq5KB8r-NmXfs=.d58a0e5d-fe08-4c9a-9bbe-a3409b269121@github.com>

On Fri, 17 Sep 2021 16:33:10 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added check for inLiveResize in AWTWindow

I fixed the bug synopsis in JBS but the PR owner will need to update it to match

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

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


From prr at openjdk.java.net  Tue Sep 21 22:51:59 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 21 Sep 2021 22:51:59 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v5]
In-Reply-To: <BzrNR0VeMIegZ8yA0nFYkG9GGaVl6mHfgbs_vCjxwT8=.b85ff14c-2265-4f97-a5cb-e2c2b9d2af53@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <BzrNR0VeMIegZ8yA0nFYkG9GGaVl6mHfgbs_vCjxwT8=.b85ff14c-2265-4f97-a5cb-e2c2b9d2af53@github.com>
Message-ID: <teA9k8QiuTgwUUFE4c3QRhW7wWcPhbO09oiJyjYD39M=.1469ae59-42ea-420a-81f6-36e0b7b7b925@github.com>

On Tue, 21 Sep 2021 19:15:43 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 check for inLiveResize in AWTWindow
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 659:
> 
>> 657:     if (![self.nsWindow inLiveResize]) {
>> 658:         [AWTWindow synthesizeMouseEnteredExitedEventsForAllWindows];
>> 659:     }
> 
> Are you sure that inLiveResize is only set when the user resizes the window? What happens if the user will move the window to the fullscreen or maximize it(by clicking on the title/buttons), will the inLiveResize be set to true or not?

The docs seem to me to be saying it is only when the user is dragging :
https://developer.apple.com/documentation/appkit/nsview/1483267-inliveresize?language=objc

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

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


From prr at openjdk.java.net  Tue Sep 21 22:55:00 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 21 Sep 2021 22:55:00 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v5]
In-Reply-To: <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
Message-ID: <CU1i-G5sUs30Xa5El_jEF3dXP96RZXMJE-ksS8it0qE=.b4374b1d-586c-485b-a6ff-6cbc17547afb@github.com>

On Fri, 17 Sep 2021 16:33:10 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added check for inLiveResize in AWTWindow

Marked as reviewed by prr (Reviewer).

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

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


From serb at openjdk.java.net  Tue Sep 21 23:38:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 21 Sep 2021 23:38:07 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v5]
In-Reply-To: <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
Message-ID: <dw7RON104pcLpSJD4DBWC5PdyYJCMc7tn29i819I2Ck=.0e0c41dc-a503-49b8-8736-27fb1017f0ac@github.com>

On Fri, 17 Sep 2021 16:33:10 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added check for inLiveResize in AWTWindow

> The docs seem to me to be saying it is only when the user is dragging :
> https://developer.apple.com/documentation/appkit/nsview/1483267-inliveresize?language=objc

I do not see that it says that:

_AppKit sets the value of this property to YES when a live resizing operation involving the view is underway. Use this property to determine when to optimize your view?s drawing behavior. Typically, you access this property from your drawRect: method and use the value to change the fidelity of the content you draw, or to draw your content more efficiently_

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

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


From serb at openjdk.java.net  Tue Sep 21 23:43:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 21 Sep 2021 23:43:01 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v5]
In-Reply-To: <dw7RON104pcLpSJD4DBWC5PdyYJCMc7tn29i819I2Ck=.0e0c41dc-a503-49b8-8736-27fb1017f0ac@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <dw7RON104pcLpSJD4DBWC5PdyYJCMc7tn29i819I2Ck=.0e0c41dc-a503-49b8-8736-27fb1017f0ac@github.com>
Message-ID: <cSvkVQbEIMOFqbWA3SZlC6fJ3-m-abiqta3dVfFIwTc=.e4255d97-6870-4eb4-be17-84c795cd7a28@github.com>

On Tue, 21 Sep 2021 23:33:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> _AppKit sets the value of this property to YES when a live resizing operation involving the view is underway. Use this property to determine when to optimize your view?s drawing behavior. Typically, you access this property from your drawRect: method and use the value to change the fidelity of the content you draw, or to draw your content more efficiently_

I did not check but I think it might be set when the "resize animation" is in progress.

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

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


From prr at openjdk.java.net  Tue Sep 21 23:59:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 21 Sep 2021 23:59:57 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v5]
In-Reply-To: <cSvkVQbEIMOFqbWA3SZlC6fJ3-m-abiqta3dVfFIwTc=.e4255d97-6870-4eb4-be17-84c795cd7a28@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <dw7RON104pcLpSJD4DBWC5PdyYJCMc7tn29i819I2Ck=.0e0c41dc-a503-49b8-8736-27fb1017f0ac@github.com>
 <cSvkVQbEIMOFqbWA3SZlC6fJ3-m-abiqta3dVfFIwTc=.e4255d97-6870-4eb4-be17-84c795cd7a28@github.com>
Message-ID: <T9PGcihZUtRFlv2kXWSPVwgCgbqQaeGdEcCL2vlAw0A=.442d3af0-cec3-4ffb-a02c-b241b77d652a@github.com>

On Tue, 21 Sep 2021 23:39:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > _AppKit sets the value of this property to YES when a live resizing operation involving the view is underway. Use this property to determine when to optimize your view?s drawing behavior. Typically, you access this property from your drawRect: method and use the value to change the fidelity of the content you draw, or to draw your content more efficiently_
> 
> I did not check but I think it might be set when the "resize animation" is in progress.

That seems unlikely to generate a sequence of such events

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

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


From javalists at cbfiddle.com  Wed Sep 22 00:07:57 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 21 Sep 2021 17:07:57 -0700
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v5]
In-Reply-To: <T9PGcihZUtRFlv2kXWSPVwgCgbqQaeGdEcCL2vlAw0A=.442d3af0-cec3-4ffb-a02c-b241b77d652a@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <dw7RON104pcLpSJD4DBWC5PdyYJCMc7tn29i819I2Ck=.0e0c41dc-a503-49b8-8736-27fb1017f0ac@github.com>
 <cSvkVQbEIMOFqbWA3SZlC6fJ3-m-abiqta3dVfFIwTc=.e4255d97-6870-4eb4-be17-84c795cd7a28@github.com>
 <T9PGcihZUtRFlv2kXWSPVwgCgbqQaeGdEcCL2vlAw0A=.442d3af0-cec3-4ffb-a02c-b241b77d652a@github.com>
Message-ID: <CAF7C8BA-066D-4849-B1BE-8D1667331344@cbfiddle.com>

My understanding is that live resizing means the window display updates continuously as the window size is changed by the user (who is dragging a resize handle).

The alternative is for AppKit to scale the original window display to fit the updated window size until the user stops dragging.

Live resizing is generally preferable. Even blanking the window is probably better than showing a scaled (and probably distorted) version of the content.

I?m not aware of any application that shows a scaled image during resize.



> On Sep 21, 2021, at 4:59 PM, Phil Race <prr at openjdk.java.net> wrote:
> 
> On Tue, 21 Sep 2021 23:39:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:
> 
>>> _AppKit sets the value of this property to YES when a live resizing operation involving the view is underway. Use this property to determine when to optimize your view?s drawing behavior. Typically, you access this property from your drawRect: method and use the value to change the fidelity of the content you draw, or to draw your content more efficiently_
>> 
>> I did not check but I think it might be set when the "resize animation" is in progress.
> 
> That seems unlikely to generate a sequence of such events
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/5497
> 



From serb at openjdk.java.net  Wed Sep 22 01:19:59 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 22 Sep 2021 01:19:59 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v5]
In-Reply-To: <T9PGcihZUtRFlv2kXWSPVwgCgbqQaeGdEcCL2vlAw0A=.442d3af0-cec3-4ffb-a02c-b241b77d652a@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <dw7RON104pcLpSJD4DBWC5PdyYJCMc7tn29i819I2Ck=.0e0c41dc-a503-49b8-8736-27fb1017f0ac@github.com>
 <cSvkVQbEIMOFqbWA3SZlC6fJ3-m-abiqta3dVfFIwTc=.e4255d97-6870-4eb4-be17-84c795cd7a28@github.com>
 <T9PGcihZUtRFlv2kXWSPVwgCgbqQaeGdEcCL2vlAw0A=.442d3af0-cec3-4ffb-a02c-b241b77d652a@github.com>
Message-ID: <5jmrtnb6x_uHpS4Wbkn2v-06TxkFcwJxX0PfsvOdPc4=.1ac3a6d8-5c07-4238-b796-e49d520a8505@github.com>

On Tue, 21 Sep 2021 23:56:29 GMT, Phil Race <prr at openjdk.org> wrote:

> That seems unlikely to generate a sequence of such events

The macOS for sure will generate the native resize events in such cases, and I think this flag will be true in that case.

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

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


From github.com+741251+turbanoff at openjdk.java.net  Wed Sep 22 01:30:00 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 22 Sep 2021 01:30:00 GMT
Subject: Integrated: 8273684: Replace usages of java.util.Stack with ArrayDeque
In-Reply-To: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
References: <r9PM-yc4mTMCRgCLv2Av7wBPGLMLt3X4JzUSs-Cl8aA=.c9dad8d4-5411-4ded-9ac0-37a76b75df10@github.com>
Message-ID: <_dDsg5tLCLNbbCioTSEwJkofd1yicdZbODJ0htuHlC4=.b78091f3-fcc3-4859-92cd-25d4a877b110@github.com>

On Sun, 29 Aug 2021 21:14:19 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Usage of thread-safe collection Stack is unnecessary. It's recommended to use ArrayDequeue if a thread-safe implementation is not needed.

This pull request has now been integrated.

Changeset: cbe57e86
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cbe57e860487d1a31a092ec326dc64bf5599a00e
Stats:     17 lines in 4 files changed: 2 ins; 3 del; 12 mod

8273684: Replace usages of java.util.Stack with ArrayDeque

Reviewed-by: cjplummer, serb

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

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


From prr at openjdk.java.net  Wed Sep 22 02:13:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 22 Sep 2021 02:13:57 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v5]
In-Reply-To: <5jmrtnb6x_uHpS4Wbkn2v-06TxkFcwJxX0PfsvOdPc4=.1ac3a6d8-5c07-4238-b796-e49d520a8505@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <dw7RON104pcLpSJD4DBWC5PdyYJCMc7tn29i819I2Ck=.0e0c41dc-a503-49b8-8736-27fb1017f0ac@github.com>
 <cSvkVQbEIMOFqbWA3SZlC6fJ3-m-abiqta3dVfFIwTc=.e4255d97-6870-4eb4-be17-84c795cd7a28@github.com>
 <T9PGcihZUtRFlv2kXWSPVwgCgbqQaeGdEcCL2vlAw0A=.442d3af0-cec3-4ffb-a02c-b241b77d652a@github.com>
 <5jmrtnb6x_uHpS4Wbkn2v-06TxkFcwJxX0PfsvOdPc4=.1ac3a6d8-5c07-4238-b796-e49d520a8505@github.com>
Message-ID: <Lfrx4nv7U2RwtjRJj_4yfEqV6ewhNDdfky7tQuSu6UU=.44ed800b-7ffc-44d6-a4c9-70568d26986c@github.com>

On Wed, 22 Sep 2021 01:16:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > That seems unlikely to generate a sequence of such events
> 
> The macOS for sure will generate the native resize events in such cases, and I think this flag will be true in that case.

I love your confidence .. so does that mean you tested it ? 
But in my comment the word sequence was important.
Watching such a resize I find it unlikely more than one exit event would be generated.

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

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


From serb at openjdk.java.net  Wed Sep 22 05:11:00 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 22 Sep 2021 05:11:00 GMT
Subject: RFR: 8254841: [macos] Enter or Exit events are shouldn't be
 displayed while resizing [v5]
In-Reply-To: <Lfrx4nv7U2RwtjRJj_4yfEqV6ewhNDdfky7tQuSu6UU=.44ed800b-7ffc-44d6-a4c9-70568d26986c@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <dw7RON104pcLpSJD4DBWC5PdyYJCMc7tn29i819I2Ck=.0e0c41dc-a503-49b8-8736-27fb1017f0ac@github.com>
 <cSvkVQbEIMOFqbWA3SZlC6fJ3-m-abiqta3dVfFIwTc=.e4255d97-6870-4eb4-be17-84c795cd7a28@github.com>
 <T9PGcihZUtRFlv2kXWSPVwgCgbqQaeGdEcCL2vlAw0A=.442d3af0-cec3-4ffb-a02c-b241b77d652a@github.com>
 <5jmrtnb6x_uHpS4Wbkn2v-06TxkFcwJxX0PfsvOdPc4=.1ac3a6d8-5c07-4238-b796-e49d520a8505@github.com>
 <Lfrx4nv7U2RwtjRJj_4yfEqV6ewhNDdfky7tQuSu6UU=.44ed800b-7ffc-44d6-a4c9-70568d26986c@github.com>
Message-ID: <-1RubZUQc3YWx0rnF50ZKLDurEnuUghpiU4BSowDaKc=.763e58ea-a982-4cb2-8d2d-6becde1bc028@github.com>

On Wed, 22 Sep 2021 02:10:26 GMT, Phil Race <prr at openjdk.org> wrote:

> I love your confidence .. so does that mean you tested it ?

=)
I did not test, the code which we try to exclude was added as part of the JDK-8028485, so if the flag=true in that use case we reintroduce that bug. I touched that code to make resize animation smoother and as far as I remember that code is executed when the user maximizes the window. 

It is better to test and confirm how it actually works.

> Watching such a resize I find it unlikely more than one exit event would be generated.

If we exclude this synthetic event we may get a situation when no enter/exit event will be generated.

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

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


From jdv at openjdk.java.net  Wed Sep 22 05:27:57 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 22 Sep 2021 05:27:57 GMT
Subject: RFR: 8268084: [macos] Disabled JMenuItem arrow is not disabled
 [v7]
In-Reply-To: <O0VdzC73jbrtVB5nIIcyTg3TAbaaMtbKjI6Qg8f_c4o=.6b177929-4f11-473d-abb7-2a4283956c93@github.com>
References: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>
 <O0VdzC73jbrtVB5nIIcyTg3TAbaaMtbKjI6Qg8f_c4o=.6b177929-4f11-473d-abb7-2a4283956c93@github.com>
Message-ID: <X4UNl_89HipYDoR2KMrl-xCoYL1iY96t_pZNFIUqvco=.2f05e64b-9de7-4a94-b20d-bb3663bfa52f@github.com>

On Mon, 13 Sep 2021 08:41:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It is seen in macos disabled JMenuItem arrow is not disabled even though JMenuItem itself is disabled.
>> In native app, same menuitem arrow is disabled for disabled menuitem.
>> 
>> Issue is when AquaMenuPainter#paintMenuItem() is called, it tries to draw a ImageIcon image of the arrow via ImageIcon#paintIcon which tries to generate MultiResolutionCachedImage via getResolutionVariant() by calling AquaUtils#generateFilteredImage.
>> It does not take into account if disabled arrow icon image needs to be drawn or not, so it is always enabled.
>> 
>> Proposed fix is to generate a disabled ImageIcon image of the same arrow icon and use it for disabled state.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable invertedIcon icon too

Marked as reviewed by jdv (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Wed Sep 22 07:53:06 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 22 Sep 2021 07:53:06 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v5]
In-Reply-To: <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
Message-ID: <us-eq3p9dnRVL6FT433-3ub7LEMwnDNr4u1BwvCYpfQ=.b9143e3f-e424-4265-b2b0-5d9c09179e46@github.com>

On Fri, 17 Sep 2021 16:33:10 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added check for inLiveResize in AWTWindow

test/jdk/java/awt/event/MouseEvent/ResizeMouseExitEnterMisfire/ResizeMouseExitEnterMisfire.java line 38:

> 36:  * @bug 8254841
> 37:  * @summary Tests spurious firing of mouseEntered and mouseExit on resize
> 38:  * @run main ResizeMouseExitEnterMisfire

I guess the test should be marked headful.
Also, did you test on all platforms by giving CI job since you did not mark it only for mac?
It seems it fails on windows.

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

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


From psadhukhan at openjdk.java.net  Wed Sep 22 08:06:14 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 22 Sep 2021 08:06:14 GMT
Subject: Integrated: 8274070: Rectify problemlist platform for failing test on
 macos12
In-Reply-To: <3yIDDATTyVJ4ahRPivLNc37iR91SHOcrnUee1P50DZA=.d99bd4c8-d631-487e-9486-832c57042abd@github.com>
References: <3yIDDATTyVJ4ahRPivLNc37iR91SHOcrnUee1P50DZA=.d99bd4c8-d631-487e-9486-832c57042abd@github.com>
Message-ID: <8RuAEWWDnN8CbDD-oWbG1PGE9E1BwkbvFi_KhspOlZw=.dd2c12ae-acac-404a-9182-3b2d2f7b7833@github.com>

On Tue, 21 Sep 2021 11:39:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It was mentioned in JDK-8273618
> 
>> java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java is timing out on a macOS 12 aarch64 (an Apple Silicon Mac Mini) system.
>> I'm not seeing the same on x64.
> 
> but it is problemlisted for macos-all..It should be problemlisted only for macos-aarch64. 
> Mach5 jobs (listed in JBS) also shows this test pass for macos-x64 but fails for macos-aarch64

This pull request has now been integrated.

Changeset: 688b3fe2
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/688b3fe2eb2593e2cad675fb0f40b8bc6adce22f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8274070: Rectify problemlist platform for failing test on macos12

Reviewed-by: azvegint

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Wed Sep 22 08:08:17 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Wed, 22 Sep 2021 08:08:17 GMT
Subject: RFR: 8262945: [macos] Regression Manual Test for Key Events Fails
In-Reply-To: <bR0e6I30DQA0kaSi-xqH-yt8d1r3wfpH2DYAy3SzwOk=.cbc2bcd7-259b-4da6-9166-96a34091b213@github.com>
References: <LhSIteG6WssDHH2if3oeA-0qLZGhxfqb11JyTC4EPh8=.b8b62eb4-a50c-4eb2-98c7-6f122f87d08b@github.com>
 <bR0e6I30DQA0kaSi-xqH-yt8d1r3wfpH2DYAy3SzwOk=.cbc2bcd7-259b-4da6-9166-96a34091b213@github.com>
Message-ID: <KRPbbQ7F_VIeZ04c-yeDaYRR2DRcKH3ZBOZX9FWhPjA=.90435ebb-83c5-4c06-ac64-45a4060e1987@github.com>

On Tue, 21 Sep 2021 22:39:12 GMT, Phil Race <prr at openjdk.org> wrote:

> where did this value come from ?

The 0x01000000 offset value is copied from share/classes/sun/awt/ExtendedKeyCodes.java. When using getExtendedKeyCodeForChar(int c), if the character isn't in the regularKeyCodesMap, that 0x01000000 offset is added and the new value is checked for again in the extendedKeyCodeSet. I noticed that Russian was in the extendedKeyCodeSet so I just checked for Russian active keyboard layout and added that offset since the case wasn't being handled before. 

> Are we doing something weird, or does macOS really make developers have to understand every single supported language -> keyboard mapping ?
Is there a better (more generic) way ?

I can try to test whether removing the Russian language check also fixes other languages (since that's what we do in ExtendedKeyCodes.java anyway), but macOS might have a different system of keycodes so I can't tell for sure that it would work for all of them.

> Is this the ONLY place we'd need to add understanding of Russian ? If there's more it would not be worth doing it just here.

>From my understanding anything that relies on keycodes would be fixed with this since AWTEvent.m was only checking for English to translate NSKeyCodes to Java virtual keycodes. I didn't see anywhere else related to keycodes we would need to have a language check .

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Wed Sep 22 08:28:55 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Wed, 22 Sep 2021 08:28:55 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v5]
In-Reply-To: <teA9k8QiuTgwUUFE4c3QRhW7wWcPhbO09oiJyjYD39M=.1469ae59-42ea-420a-81f6-36e0b7b7b925@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <BzrNR0VeMIegZ8yA0nFYkG9GGaVl6mHfgbs_vCjxwT8=.b85ff14c-2265-4f97-a5cb-e2c2b9d2af53@github.com>
 <teA9k8QiuTgwUUFE4c3QRhW7wWcPhbO09oiJyjYD39M=.1469ae59-42ea-420a-81f6-36e0b7b7b925@github.com>
Message-ID: <G_JbYeJ74c84pfcW204Bd0att-4nnR3FLQ66Rfx9ir4=.1b80682b-7691-4875-b5fa-401e82adaefd@github.com>

On Tue, 21 Sep 2021 22:49:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 659:
>> 
>>> 657:     if (![self.nsWindow inLiveResize]) {
>>> 658:         [AWTWindow synthesizeMouseEnteredExitedEventsForAllWindows];
>>> 659:     }
>> 
>> Are you sure that inLiveResize is only set when the user resizes the window? What happens if the user will move the window to the fullscreen or maximize it(by clicking on the title/buttons), will the inLiveResize be set to true or not?
>
> The docs seem to me to be saying it is only when the user is dragging :
> https://developer.apple.com/documentation/appkit/nsview/1483267-inliveresize?language=objc

When the user maximizes the window a mouseEntered event does fire, so it preserves the fix for JDK-8028485. But I noticed another problem is that a mouseEntered event will be generated if the window is dragged around (without resizing or entering the actual window). This could cause a situation where you can drag a window around to create a mouseEntered event, move the mouse away from the window, and re-enter the window without generating a mouseEntered event.

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Wed Sep 22 17:55:57 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Wed, 22 Sep 2021 17:55:57 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v5]
In-Reply-To: <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
Message-ID: <57_CpBYrvFjr586rGPWjeDbbLfUqqVcwDm4pbT2neO8=.e09a2e78-3d44-41c7-b2d0-8add8fcf8c2f@github.com>

On Fri, 17 Sep 2021 16:33:10 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added check for inLiveResize in AWTWindow

> When the user maximizes the window a mouseEntered event does fire, so it preserves the fix for JDK-8028485. But I noticed another problem is that a mouseEntered event will be generated if the window is dragged around (without resizing or entering the actual window). This could cause a situation where you can drag a window around to create a mouseEntered event, move the mouse away from the window, and re-enter the window without generating a mouseEntered event.

Moving the frame and causing a mouseEntered event seems to be a separate bug that isn't caused by the fix. Before the changes the mouseEntered and mouseExited events would constantly fire, while after the fix only a mouseEntered event would fire. I think correct behavior would be having no mouse events during a window move. I filed another bug (JDK-8274159) for this window-moving mouseEntered event bug.

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Wed Sep 22 18:35:59 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Wed, 22 Sep 2021 18:35:59 GMT
Subject: Integrated: 8205137: Remove Applet support from SwingSet2
In-Reply-To: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
References: <7BNaYiUnQbx8H2aAOMHX-vV7DQTVAzla0yF0ZXw9v1g=.3f91dde5-4897-4bf8-86dd-cbcaad463a76@github.com>
Message-ID: <odmNTHY7RYQCtXoKG974CC-9rKxQOYjdz9w0XHsPmLk=.16ebe89d-d13d-4afe-8049-a4f29bf74946@github.com>

On Tue, 7 Sep 2021 22:08:58 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> removed support for running demo from applet for J2Ddemo and SwingSet2
> same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)

This pull request has now been integrated.

Changeset: 8821b000
Author:    Alisen Chung <alisen.chung at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8821b0004170e18c8e7d6e5bbe8759344ff769b1
Stats:     499 lines in 21 files changed: 183 ins; 183 del; 133 mod

8205137: Remove Applet support from SwingSet2
8205139: Remove Applet support from J2Ddemo

Reviewed-by: aivanov, kizune

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Wed Sep 22 19:29:04 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Wed, 22 Sep 2021 19:29:04 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v5]
In-Reply-To: <us-eq3p9dnRVL6FT433-3ub7LEMwnDNr4u1BwvCYpfQ=.b9143e3f-e424-4265-b2b0-5d9c09179e46@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <us-eq3p9dnRVL6FT433-3ub7LEMwnDNr4u1BwvCYpfQ=.b9143e3f-e424-4265-b2b0-5d9c09179e46@github.com>
Message-ID: <wwKaaJ8TzClNLotGrkicpplT9kA1wZhFt7xjXKjN7KI=.1e21e438-a31b-4eee-8415-650c45890850@github.com>

On Wed, 22 Sep 2021 07:49:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added check for inLiveResize in AWTWindow
>
> test/jdk/java/awt/event/MouseEvent/ResizeMouseExitEnterMisfire/ResizeMouseExitEnterMisfire.java line 38:
> 
>> 36:  * @bug 8254841
>> 37:  * @summary Tests spurious firing of mouseEntered and mouseExit on resize
>> 38:  * @run main ResizeMouseExitEnterMisfire
> 
> I guess the test should be marked headful.
> Also, did you test on all platforms by giving CI job since you did not mark it only for mac?
> It seems it fails on windows.

I'm currently unable to test windows platform, so I'm not sure..

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

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


From prr at openjdk.java.net  Wed Sep 22 19:35:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 22 Sep 2021 19:35:57 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v5]
In-Reply-To: <wwKaaJ8TzClNLotGrkicpplT9kA1wZhFt7xjXKjN7KI=.1e21e438-a31b-4eee-8415-650c45890850@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <us-eq3p9dnRVL6FT433-3ub7LEMwnDNr4u1BwvCYpfQ=.b9143e3f-e424-4265-b2b0-5d9c09179e46@github.com>
 <wwKaaJ8TzClNLotGrkicpplT9kA1wZhFt7xjXKjN7KI=.1e21e438-a31b-4eee-8415-650c45890850@github.com>
Message-ID: <shjlu7UebKMCsibvBPw6Ykvlfy4iAEtFrYCa8O-vKrg=.74442580-1a2e-45f5-9156-664163f86fa7@github.com>

On Wed, 22 Sep 2021 19:26:23 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> test/jdk/java/awt/event/MouseEvent/ResizeMouseExitEnterMisfire/ResizeMouseExitEnterMisfire.java line 38:
>> 
>>> 36:  * @bug 8254841
>>> 37:  * @summary Tests spurious firing of mouseEntered and mouseExit on resize
>>> 38:  * @run main ResizeMouseExitEnterMisfire
>> 
>> I guess the test should be marked headful.
>> Also, did you test on all platforms by giving CI job since you did not mark it only for mac?
>> It seems it fails on windows.
>
> I'm currently unable to test windows platform, so I'm not sure..

Not a "CI" job (CI jobs run on the integrated fixes in mainline) but you can submit a test job (ask me how)

Yes this test absolutely needs
@key headful 
else it will cause problems in the CI jobs.

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Wed Sep 22 19:49:37 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Wed, 22 Sep 2021 19:49:37 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v6]
In-Reply-To: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
Message-ID: <IkC0obnNWgjDISVxs2JVHdaSlJGa0wPlxy1G15kwp34=.9696112b-c275-4bad-a92e-c1cf33e860a9@github.com>

> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.

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

  marked test headful

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5497/files
  - new: https://git.openjdk.java.net/jdk/pull/5497/files/27743318..ce46976f

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

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

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


From serb at openjdk.java.net  Thu Sep 23 00:40:55 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 23 Sep 2021 00:40:55 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v5]
In-Reply-To: <57_CpBYrvFjr586rGPWjeDbbLfUqqVcwDm4pbT2neO8=.e09a2e78-3d44-41c7-b2d0-8add8fcf8c2f@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <57_CpBYrvFjr586rGPWjeDbbLfUqqVcwDm4pbT2neO8=.e09a2e78-3d44-41c7-b2d0-8add8fcf8c2f@github.com>
Message-ID: <GqCIC4UlNdfmK4fi5OtgVZGPc1br6JXZB_IqDCivIxg=.51b1bbe0-e8e0-4f47-a6bf-08322d610487@github.com>

On Wed, 22 Sep 2021 17:53:09 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> Before the changes the mouseEntered and mouseExited events would constantly fire, while after the fix only a mouseEntered event would fire

Does it mean that after the fix we will post a few enter events w/o exit events? Then it is worse than posting enter/exit events that are paired, even if we will post many such pairs.

> When the user maximizes the window a mouseEntered event does fire, so it preserves the fix for JDK-8028485.

Just for the record did you check what is the inLiveResize value when the user maximizes the window, or moves it to the full screen/tile the window to the left/right?

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

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


From jdv at openjdk.java.net  Thu Sep 23 04:45:08 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 23 Sep 2021 04:45:08 GMT
Subject: RFR: 8273578: javax/swing/JMenu/4515762/bug4515762.java fails on
 macOS 12
In-Reply-To: <24NoEFkW488AOfiZ8_PxM1NgFK7TlU2QGC-7IHlKLZI=.4612676d-4f7e-4d24-9219-5520701ca837@github.com>
References: <24NoEFkW488AOfiZ8_PxM1NgFK7TlU2QGC-7IHlKLZI=.4612676d-4f7e-4d24-9219-5520701ca837@github.com>
Message-ID: <ui5TxtMscbdxvU_0ctgQpymqnNleH-YJ6F_VGduKqvQ=.e0c6c5e8-273d-4193-8532-f815c6422db0@github.com>

On Fri, 17 Sep 2021 12:24:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The test sometimes fail on macos12 citing "Action has not been received". Seems like some key events sometimes are not received reliably. 
> Proposed fix is to apply mach5 stability fixes which is to set autodelay to 100ms, move frame to center of screen from top-left, added extra waitForIdle(), wait for 1 sec after frame is made visible.
> Additionally, it is seen that it mixes Util.hitKeys and robot.keyPress/Release. Changed to make it use robot.keyPress/keyRelease all times. Also, updated test to have specific error message for specific keyevent so that we know which keyevent is not received in case it fails again.
> 
> Run on mac12 and all other platforms multiple times and test run is green. Link in JBS.

Marked as reviewed by jdv (Reviewer).

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

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


From serb at openjdk.java.net  Thu Sep 23 04:49:59 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 23 Sep 2021 04:49:59 GMT
Subject: RFR: 8274016: Replace 'for' cycles with iterator with
 enhanced-for in java.desktop
In-Reply-To: <J_99QqIiSe6JHaUJP4vgaeN0GAA5Cebu0ycpQupFiJo=.bcb78736-629a-4ca8-8262-0fee90bbf06d@github.com>
References: <J_99QqIiSe6JHaUJP4vgaeN0GAA5Cebu0ycpQupFiJo=.bcb78736-629a-4ca8-8262-0fee90bbf06d@github.com>
Message-ID: <9wq0weATLzWP9AoTz3V_LqmEF-PF69v4jnqAajeQLhc=.4de9275a-6094-47f0-97f5-990cee851927@github.com>

On Sun, 19 Sep 2021 10:13:49 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are few places in code where manual `for` loop is used with Iterator to iterate over Collection.
> Instead of manual `for` cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
> This is continuation of [JDK-8258006](https://bugs.openjdk.java.net/browse/JDK-8258006)

src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleRenderedImage.java line 285:

> 283:         }
> 284: 
> 285:         // Copy the strings from the Vector over to a String array.

Looks like JDK-8271603 missed "Vector" here.

src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleRenderedImage.java line 289:

> 287:         int count = 0;
> 288:         for (String name : names) {
> 289:             prefixNames[count++] = name;

Why we cannot use names.toArray here?

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

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


From serb at openjdk.java.net  Thu Sep 23 04:52:51 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 23 Sep 2021 04:52:51 GMT
Subject: RFR: 8273578: javax/swing/JMenu/4515762/bug4515762.java fails on
 macOS 12
In-Reply-To: <24NoEFkW488AOfiZ8_PxM1NgFK7TlU2QGC-7IHlKLZI=.4612676d-4f7e-4d24-9219-5520701ca837@github.com>
References: <24NoEFkW488AOfiZ8_PxM1NgFK7TlU2QGC-7IHlKLZI=.4612676d-4f7e-4d24-9219-5520701ca837@github.com>
Message-ID: <-KYPXVNX0ceWZhbLwkCrlW7kjnXEnUeUOc9Ipo5GWIA=.4bbdd36a-fa6d-4aa9-acff-992483cb6af2@github.com>

On Fri, 17 Sep 2021 12:24:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The test sometimes fail on macos12 citing "Action has not been received". Seems like some key events sometimes are not received reliably. 
> Proposed fix is to apply mach5 stability fixes which is to set autodelay to 100ms, move frame to center of screen from top-left, added extra waitForIdle(), wait for 1 sec after frame is made visible.
> Additionally, it is seen that it mixes Util.hitKeys and robot.keyPress/Release. Changed to make it use robot.keyPress/keyRelease all times. Also, updated test to have specific error message for specific keyevent so that we know which keyevent is not received in case it fails again.
> 
> Run on mac12 and all other platforms multiple times and test run is green. Link in JBS.

Let's see what additional information by this logging we can get next time.

Do you need to remove it from the problem list?

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

Marked as reviewed by serb (Reviewer).

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


From jdv at openjdk.java.net  Thu Sep 23 04:52:51 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 23 Sep 2021 04:52:51 GMT
Subject: RFR: 8273578: javax/swing/JMenu/4515762/bug4515762.java fails on
 macOS 12
In-Reply-To: <24NoEFkW488AOfiZ8_PxM1NgFK7TlU2QGC-7IHlKLZI=.4612676d-4f7e-4d24-9219-5520701ca837@github.com>
References: <24NoEFkW488AOfiZ8_PxM1NgFK7TlU2QGC-7IHlKLZI=.4612676d-4f7e-4d24-9219-5520701ca837@github.com>
Message-ID: <tSen02VcIgHWkOEPFxr40tFUwaOiIw942R-d8x_28yw=.e418bab9-bbf6-4e9d-a7f2-e5951b2ae51d@github.com>

On Fri, 17 Sep 2021 12:24:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The test sometimes fail on macos12 citing "Action has not been received". Seems like some key events sometimes are not received reliably. 
> Proposed fix is to apply mach5 stability fixes which is to set autodelay to 100ms, move frame to center of screen from top-left, added extra waitForIdle(), wait for 1 sec after frame is made visible.
> Additionally, it is seen that it mixes Util.hitKeys and robot.keyPress/Release. Changed to make it use robot.keyPress/keyRelease all times. Also, updated test to have specific error message for specific keyevent so that we know which keyevent is not received in case it fails again.
> 
> Run on mac12 and all other platforms multiple times and test run is green. Link in JBS.

8273578 is used in problem lists: [test/jdk/ProblemList.txt] dont know why this error is shown. I dont see it in problemList.
@prsadhuk please verify before push.

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

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


From psadhukhan at openjdk.java.net  Thu Sep 23 05:12:46 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 23 Sep 2021 05:12:46 GMT
Subject: RFR: 8273578: javax/swing/JMenu/4515762/bug4515762.java fails on
 macOS 12 [v2]
In-Reply-To: <24NoEFkW488AOfiZ8_PxM1NgFK7TlU2QGC-7IHlKLZI=.4612676d-4f7e-4d24-9219-5520701ca837@github.com>
References: <24NoEFkW488AOfiZ8_PxM1NgFK7TlU2QGC-7IHlKLZI=.4612676d-4f7e-4d24-9219-5520701ca837@github.com>
Message-ID: <8uqzuRw7nQiF2za0-Yoc6gxSq6TloRfEEzC4YcZXeJY=.e95dc550-1bde-42bc-a31a-524bc497d563@github.com>

> The test sometimes fail on macos12 citing "Action has not been received". Seems like some key events sometimes are not received reliably. 
> Proposed fix is to apply mach5 stability fixes which is to set autodelay to 100ms, move frame to center of screen from top-left, added extra waitForIdle(), wait for 1 sec after frame is made visible.
> Additionally, it is seen that it mixes Util.hitKeys and robot.keyPress/Release. Changed to make it use robot.keyPress/keyRelease all times. Also, updated test to have specific error message for specific keyevent so that we know which keyevent is not received in case it fails again.
> 
> Run on mac12 and all other platforms multiple times and test run is green. Link in JBS.

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

 - Problemlist update
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8273578
 - 8273578: javax/swing/JMenu/4515762/bug4515762.java fails on macOS 12

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5564/files
  - new: https://git.openjdk.java.net/jdk/pull/5564/files/ff8796ce..23c57e06

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

  Stats: 20445 lines in 515 files changed: 14665 ins; 2582 del; 3198 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5564.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5564/head:pull/5564

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


From jdv at openjdk.java.net  Thu Sep 23 05:12:49 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 23 Sep 2021 05:12:49 GMT
Subject: RFR: 8273578: javax/swing/JMenu/4515762/bug4515762.java fails on
 macOS 12 [v2]
In-Reply-To: <8uqzuRw7nQiF2za0-Yoc6gxSq6TloRfEEzC4YcZXeJY=.e95dc550-1bde-42bc-a31a-524bc497d563@github.com>
References: <24NoEFkW488AOfiZ8_PxM1NgFK7TlU2QGC-7IHlKLZI=.4612676d-4f7e-4d24-9219-5520701ca837@github.com>
 <8uqzuRw7nQiF2za0-Yoc6gxSq6TloRfEEzC4YcZXeJY=.e95dc550-1bde-42bc-a31a-524bc497d563@github.com>
Message-ID: <BuFAH56EnWmnrRJQ3-lxqrVObNsuf0e5qE4AysME4rY=.28318c09-dd18-401b-bfd5-689e3172cd6a@github.com>

On Thu, 23 Sep 2021 05:08:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The test sometimes fail on macos12 citing "Action has not been received". Seems like some key events sometimes are not received reliably. 
>> Proposed fix is to apply mach5 stability fixes which is to set autodelay to 100ms, move frame to center of screen from top-left, added extra waitForIdle(), wait for 1 sec after frame is made visible.
>> Additionally, it is seen that it mixes Util.hitKeys and robot.keyPress/Release. Changed to make it use robot.keyPress/keyRelease all times. Also, updated test to have specific error message for specific keyevent so that we know which keyevent is not received in case it fails again.
>> 
>> Run on mac12 and all other platforms multiple times and test run is green. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Problemlist update
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8273578
>  - 8273578: javax/swing/JMenu/4515762/bug4515762.java fails on macOS 12

Marked as reviewed by jdv (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Thu Sep 23 05:18:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 23 Sep 2021 05:18:56 GMT
Subject: Integrated: 8273578: javax/swing/JMenu/4515762/bug4515762.java fails
 on macOS 12
In-Reply-To: <24NoEFkW488AOfiZ8_PxM1NgFK7TlU2QGC-7IHlKLZI=.4612676d-4f7e-4d24-9219-5520701ca837@github.com>
References: <24NoEFkW488AOfiZ8_PxM1NgFK7TlU2QGC-7IHlKLZI=.4612676d-4f7e-4d24-9219-5520701ca837@github.com>
Message-ID: <jeXG9GVAXBrrYmJMAsGhNZ9f9P6aW2GylQkp2G-l3Bw=.a7239e5b-0462-4909-8adf-3e6691d662c0@github.com>

On Fri, 17 Sep 2021 12:24:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The test sometimes fail on macos12 citing "Action has not been received". Seems like some key events sometimes are not received reliably. 
> Proposed fix is to apply mach5 stability fixes which is to set autodelay to 100ms, move frame to center of screen from top-left, added extra waitForIdle(), wait for 1 sec after frame is made visible.
> Additionally, it is seen that it mixes Util.hitKeys and robot.keyPress/Release. Changed to make it use robot.keyPress/keyRelease all times. Also, updated test to have specific error message for specific keyevent so that we know which keyevent is not received in case it fails again.
> 
> Run on mac12 and all other platforms multiple times and test run is green. Link in JBS.

This pull request has now been integrated.

Changeset: 45adc922
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/45adc9227a28c8d614c41ac496bbeaa752e5fd7b
Stats:     32 lines in 2 files changed: 13 ins; 1 del; 18 mod

8273578: javax/swing/JMenu/4515762/bug4515762.java fails on macOS 12

Reviewed-by: jdv, serb

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

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


From psadhukhan at openjdk.java.net  Thu Sep 23 06:57:11 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 23 Sep 2021 06:57:11 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out on
 macOS 12
Message-ID: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>

java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java is timing out every time on macOS 12 even though the test passed.
Looks like the the main process waits for child process created in the test forever, making it timeout after jtreg timeout of 2min.
Modified to wait for childprocess for 30secs.

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

Commit messages:
 - Merge master
 - Fix
 - 8273617: UninitializedDisplayModeChangeTest.java times out on macOS 12

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

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


From psadhukhan at openjdk.java.net  Thu Sep 23 07:17:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 23 Sep 2021 07:17:56 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out
 on macOS 12
In-Reply-To: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
References: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
Message-ID: <6ozMvaICkKINscsdCFQDz1O-VW2IIIk_w_GQk-FZlHI=.0deb0ff5-7641-493e-b114-27a728645721@github.com>

On Thu, 23 Sep 2021 06:47:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java is timing out every time on macOS 12 even though the test passed.
> Looks like the the main process waits for child process created in the test forever, making it timeout after jtreg timeout of 2min.
> Modified to wait for childprocess for 30secs.

Mach5 Test job running for several iterations for all platforms (including macos 12 both x64 and aarch64) is green

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

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


From github.com+741251+turbanoff at openjdk.java.net  Thu Sep 23 07:51:39 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 23 Sep 2021 07:51:39 GMT
Subject: RFR: 8274016: Replace 'for' cycles with iterator with
 enhanced-for in java.desktop [v2]
In-Reply-To: <J_99QqIiSe6JHaUJP4vgaeN0GAA5Cebu0ycpQupFiJo=.bcb78736-629a-4ca8-8262-0fee90bbf06d@github.com>
References: <J_99QqIiSe6JHaUJP4vgaeN0GAA5Cebu0ycpQupFiJo=.bcb78736-629a-4ca8-8262-0fee90bbf06d@github.com>
Message-ID: <FcHxhv6ha4HAzcfSRVpqZ0HWTtrE52cVsy4Y1xXrbok=.a03356ef-a43a-4ef1-bc13-67752831016b@github.com>

> There are few places in code where manual `for` loop is used with Iterator to iterate over Collection.
> Instead of manual `for` cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
> This is continuation of [JDK-8258006](https://bugs.openjdk.java.net/browse/JDK-8258006)

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

  8274016: Replace 'for' cycles with iterator with enhanced-for in java.desktop
  cleanup toArray conversion in SimpleRenderedImage

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5578/files
  - new: https://git.openjdk.java.net/jdk/pull/5578/files/121e7c22..fe07b885

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

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

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


From github.com+741251+turbanoff at openjdk.java.net  Thu Sep 23 07:51:43 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 23 Sep 2021 07:51:43 GMT
Subject: RFR: 8274016: Replace 'for' cycles with iterator with
 enhanced-for in java.desktop [v2]
In-Reply-To: <9wq0weATLzWP9AoTz3V_LqmEF-PF69v4jnqAajeQLhc=.4de9275a-6094-47f0-97f5-990cee851927@github.com>
References: <J_99QqIiSe6JHaUJP4vgaeN0GAA5Cebu0ycpQupFiJo=.bcb78736-629a-4ca8-8262-0fee90bbf06d@github.com>
 <9wq0weATLzWP9AoTz3V_LqmEF-PF69v4jnqAajeQLhc=.4de9275a-6094-47f0-97f5-990cee851927@github.com>
Message-ID: <gGl4Hq-Mn6uRFf062q0RFphhUxMT3eyKBAK5MHdo3M0=.8a547d44-d1b4-44b7-9534-ed85d43d88f0@github.com>

On Thu, 23 Sep 2021 04:43:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274016: Replace 'for' cycles with iterator with enhanced-for in java.desktop
>>   cleanup toArray conversion in SimpleRenderedImage
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleRenderedImage.java line 285:
> 
>> 283:         }
>> 284: 
>> 285:         // Copy the strings from the Vector over to a String array.
> 
> Looks like JDK-8271603 missed "Vector" here.

Fixed.

> src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleRenderedImage.java line 289:
> 
>> 287:         int count = 0;
>> 288:         for (String name : names) {
>> 289:             prefixNames[count++] = name;
> 
> Why we cannot use names.toArray here?

We can. Updated.

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

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


From serb at openjdk.java.net  Thu Sep 23 08:39:02 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 23 Sep 2021 08:39:02 GMT
Subject: RFR: 8274016: Replace 'for' cycles with iterator with
 enhanced-for in java.desktop [v2]
In-Reply-To: <FcHxhv6ha4HAzcfSRVpqZ0HWTtrE52cVsy4Y1xXrbok=.a03356ef-a43a-4ef1-bc13-67752831016b@github.com>
References: <J_99QqIiSe6JHaUJP4vgaeN0GAA5Cebu0ycpQupFiJo=.bcb78736-629a-4ca8-8262-0fee90bbf06d@github.com>
 <FcHxhv6ha4HAzcfSRVpqZ0HWTtrE52cVsy4Y1xXrbok=.a03356ef-a43a-4ef1-bc13-67752831016b@github.com>
Message-ID: <Sq_yNN3ri1cHBAauh1PtNkdRwDDEjKyUH1ONaTLUbVI=.661e30cc-bfc2-42ce-aba0-296dbc02b92b@github.com>

On Thu, 23 Sep 2021 07:51:39 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> There are few places in code where manual `for` loop is used with Iterator to iterate over Collection.
>> Instead of manual `for` cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
>> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
>> This is continuation of [JDK-8258006](https://bugs.openjdk.java.net/browse/JDK-8258006)
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274016: Replace 'for' cycles with iterator with enhanced-for in java.desktop
>   cleanup toArray conversion in SimpleRenderedImage

src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleRenderedImage.java line 286:

> 284: 
> 285:         // Copy the strings from the ArrayList over to a String array.
> 286:         String[] prefixNames = names.toArray(new String[0]);

Looks like the comment became useless

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

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


From github.com+741251+turbanoff at openjdk.java.net  Thu Sep 23 09:47:21 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 23 Sep 2021 09:47:21 GMT
Subject: RFR: 8274016: Replace 'for' cycles with iterator with
 enhanced-for in java.desktop [v3]
In-Reply-To: <J_99QqIiSe6JHaUJP4vgaeN0GAA5Cebu0ycpQupFiJo=.bcb78736-629a-4ca8-8262-0fee90bbf06d@github.com>
References: <J_99QqIiSe6JHaUJP4vgaeN0GAA5Cebu0ycpQupFiJo=.bcb78736-629a-4ca8-8262-0fee90bbf06d@github.com>
Message-ID: <-QIK4YJVRpqbJ4Yiu4SqBHPaFK0yPlfR78ZkN0QZwgM=.a4cf88ac-0327-4431-8d2e-d857aa0e8b75@github.com>

> There are few places in code where manual `for` loop is used with Iterator to iterate over Collection.
> Instead of manual `for` cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
> This is continuation of [JDK-8258006](https://bugs.openjdk.java.net/browse/JDK-8258006)

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

  8274016: Replace 'for' cycles with iterator with enhanced-for in java.desktop
  drop useless comment
  cleanup unused imports

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5578/files
  - new: https://git.openjdk.java.net/jdk/pull/5578/files/fe07b885..3a77c210

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

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

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


From github.com+741251+turbanoff at openjdk.java.net  Thu Sep 23 09:47:26 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 23 Sep 2021 09:47:26 GMT
Subject: RFR: 8274016: Replace 'for' cycles with iterator with
 enhanced-for in java.desktop [v2]
In-Reply-To: <Sq_yNN3ri1cHBAauh1PtNkdRwDDEjKyUH1ONaTLUbVI=.661e30cc-bfc2-42ce-aba0-296dbc02b92b@github.com>
References: <J_99QqIiSe6JHaUJP4vgaeN0GAA5Cebu0ycpQupFiJo=.bcb78736-629a-4ca8-8262-0fee90bbf06d@github.com>
 <FcHxhv6ha4HAzcfSRVpqZ0HWTtrE52cVsy4Y1xXrbok=.a03356ef-a43a-4ef1-bc13-67752831016b@github.com>
 <Sq_yNN3ri1cHBAauh1PtNkdRwDDEjKyUH1ONaTLUbVI=.661e30cc-bfc2-42ce-aba0-296dbc02b92b@github.com>
Message-ID: <xHM0hc5KELKGixWE6hdZhi7RkADglzipm0fD28eLAaw=.2a7ff94f-6bf7-4f26-af9e-d787db853535@github.com>

On Thu, 23 Sep 2021 08:35:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274016: Replace 'for' cycles with iterator with enhanced-for in java.desktop
>>   cleanup toArray conversion in SimpleRenderedImage
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleRenderedImage.java line 286:
> 
>> 284: 
>> 285:         // Copy the strings from the ArrayList over to a String array.
>> 286:         String[] prefixNames = names.toArray(new String[0]);
> 
> Looks like the comment became useless

Agree. Removed.

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

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


From ihse at openjdk.java.net  Thu Sep 23 10:33:04 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 23 Sep 2021 10:33:04 GMT
Subject: RFR: 8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on
 Manjaro Linux [v3]
In-Reply-To: <Vo5CWeyG6_cBHQXdh2AUv8a2WDJw7ehqITEMW8zW32c=.6476f2ea-c5dc-4d49-b04f-80cbc3177b17@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
 <Dd1tpX41xYE43y7GoNxSiApEHoniYEx3YcpbQGCwOmE=.d9146b76-b2e9-4f37-aa4b-b4d7a96c6ba2@github.com>
 <Vo5CWeyG6_cBHQXdh2AUv8a2WDJw7ehqITEMW8zW32c=.6476f2ea-c5dc-4d49-b04f-80cbc3177b17@github.com>
Message-ID: <SAbebNxHOirtDKMahbju6CHXtnhMF1BAxL0TfB4tqGE=.ef23805f-8131-4368-9f75-8a9e7656c27b@github.com>

On Wed, 15 Sep 2021 19:43:45 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux
>
> You mention that "too many systems have to old a version of harfbuzz".
> Is the required version defined somewhere? There's no check in configure for either a version or a required symbol:
> https://github.com/openjdk/jdk/blob/cbffecc61e4a9ac1172926ef4f20d918d73adde9/make/autoconf/lib-bundled.m4#L291
> 
> With undefined symbols also being left to runtime (hence why JDK-8272332 doesn't show up during build), it seems this could lead to sporadic runtime failures if OpenJDK is unknowingly built against a harfbuzz that is too old.

@gnu-andrew Maybe I'm misunderstanding here, but if symbol lookup is done at runtime, then the failure would occur if the JDK is *run* on a system with a too old harfbuzz, not if it is *built* on it. So it seems you want runtime checks, not build-time checks, right?

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

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


From shade at openjdk.java.net  Thu Sep 23 11:20:53 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 23 Sep 2021 11:20:53 GMT
Subject: RFR: 8273821: Limit parallelism for sanity/client/SwingSet tests
In-Reply-To: <m5LUIlpQozmWLFepnVYRhcAXy0aEaJkmlupF3p5sC1A=.d91299d5-d870-4499-9c3b-0388bf1b2d9b@github.com>
References: <m5LUIlpQozmWLFepnVYRhcAXy0aEaJkmlupF3p5sC1A=.d91299d5-d870-4499-9c3b-0388bf1b2d9b@github.com>
Message-ID: <nNSTFKCTlq4tqGtscO15fLx1RVLySZ-ETeHzMIjciNY=.bccd67ca-e2df-4ffe-8d01-4582e1fdb1ab@github.com>

On Wed, 15 Sep 2021 14:18:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> If you run them today on a parallel machine with the usual invocation:
> 
> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/client/SwingSet/
> 
> ...then a whole lot of these tests would fail. It seems to be caused by the overlapping GUI windows that robots fail to reach properly then. It seems these tests need to be run exclusively. 
> 
> @mrserb, maybe I am missing something? How do you run these tests? 
> 
> Additional testing:
>  - [x] `sanity/client/SwingSet/` tests now pass on TR 3970X

All right, I am going to withdraw it, because the issue is more generic than this.

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

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


From shade at openjdk.java.net  Thu Sep 23 11:20:53 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 23 Sep 2021 11:20:53 GMT
Subject: Withdrawn: 8273821: Limit parallelism for sanity/client/SwingSet tests
In-Reply-To: <m5LUIlpQozmWLFepnVYRhcAXy0aEaJkmlupF3p5sC1A=.d91299d5-d870-4499-9c3b-0388bf1b2d9b@github.com>
References: <m5LUIlpQozmWLFepnVYRhcAXy0aEaJkmlupF3p5sC1A=.d91299d5-d870-4499-9c3b-0388bf1b2d9b@github.com>
Message-ID: <Z8tJIBCdvDZ49j9v6yPSGslOPKOvjl02AAzyAgDDKMA=.7fcada7d-8929-4644-b762-321618c5e5ff@github.com>

On Wed, 15 Sep 2021 14:18:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> If you run them today on a parallel machine with the usual invocation:
> 
> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/client/SwingSet/
> 
> ...then a whole lot of these tests would fail. It seems to be caused by the overlapping GUI windows that robots fail to reach properly then. It seems these tests need to be run exclusively. 
> 
> @mrserb, maybe I am missing something? How do you run these tests? 
> 
> Additional testing:
>  - [x] `sanity/client/SwingSet/` tests now pass on TR 3970X

This pull request has been closed without being integrated.

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

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


From josef.koeble at sap.com  Thu Sep 23 13:27:31 2021
From: josef.koeble at sap.com (Koeble, Josef)
Date: Thu, 23 Sep 2021 13:27:31 +0000
Subject: [macOS] Is there a Roadmap for availability of NSAcccessibility
 implementation?
Message-ID: <AM0PR02MB58117FAADE5FB7A6DC53E62B86A39@AM0PR02MB5811.eurprd02.prod.outlook.com>

Hi,

we are using OpenJDK for our large Java Swing application. When testing our application for Accessibility running with JDK 17 on macOS with its screen reader VoiceOver, we realize some bigger issues (e.g. no announcements in tree or in table). These issues also occur when testing SwingSet running the same environment. On Windows running screen reader JAWS or NVDA, there are no such issues.

I found the following bug task, happy to read that you are working on it:
https://bugs.openjdk.java.net/browse/JDK-8152350
When testing with JDK 18, I noticed that some of the issues were fixed.

Is there any roadmap for the availability of the complete NSAccessibility implementation?

Thanks and best regards,
Josef


From psadhukhan at openjdk.java.net  Thu Sep 23 14:02:24 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 23 Sep 2021 14:02:24 GMT
Subject: RFR: 8273618: DisplayChangeVITest.java is timing out on macOS 12
 aarch64
Message-ID: <AFbV2Uqsh4airkhkCe4pgdG3P7l8vsKXuQd3K_sRqq8=.2038d763-90bb-494f-b937-28dc6dd39707@github.com>

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)

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

Commit messages:
 - 8273618: DisplayChangeVITest.java is timing out on macOS 12 aarch64
 - 8273618: DisplayChangeVITest.java is timing out on macOS 12 aarch64

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

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


From prr at openjdk.java.net  Thu Sep 23 15:32:55 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 23 Sep 2021 15:32:55 GMT
Subject: RFR: 8273821: Limit parallelism for sanity/client/SwingSet tests
In-Reply-To: <m5LUIlpQozmWLFepnVYRhcAXy0aEaJkmlupF3p5sC1A=.d91299d5-d870-4499-9c3b-0388bf1b2d9b@github.com>
References: <m5LUIlpQozmWLFepnVYRhcAXy0aEaJkmlupF3p5sC1A=.d91299d5-d870-4499-9c3b-0388bf1b2d9b@github.com>
Message-ID: <lzAC6eHddjqz2irBpEiBpHZ-SDUwsYb399gp3Vg1CpU=.581e30f7-4e94-49ba-a828-8d6a642cb314@github.com>

On Wed, 15 Sep 2021 14:18:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> If you run them today on a parallel machine with the usual invocation:
> 
> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/client/SwingSet/
> 
> ...then a whole lot of these tests would fail. It seems to be caused by the overlapping GUI windows that robots fail to reach properly then. It seems these tests need to be run exclusively. 
> 
> @mrserb, maybe I am missing something? How do you run these tests? 
> 
> Additional testing:
>  - [x] `sanity/client/SwingSet/` tests now pass on TR 3970X

We run headful and headless tests in SEPARATE jtreg runs because there if you set JOBS=1 for all tests that's inefficient for the headless tests.

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Thu Sep 23 16:53:56 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Thu, 23 Sep 2021 16:53:56 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v5]
In-Reply-To: <GqCIC4UlNdfmK4fi5OtgVZGPc1br6JXZB_IqDCivIxg=.51b1bbe0-e8e0-4f47-a6bf-08322d610487@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <57_CpBYrvFjr586rGPWjeDbbLfUqqVcwDm4pbT2neO8=.e09a2e78-3d44-41c7-b2d0-8add8fcf8c2f@github.com>
 <GqCIC4UlNdfmK4fi5OtgVZGPc1br6JXZB_IqDCivIxg=.51b1bbe0-e8e0-4f47-a6bf-08322d610487@github.com>
Message-ID: <mboe3-va-xCqCw-3V6v8dZCS3qKY6XCo1s-11A5SJT0=.6b82f148-0608-44be-bed9-c43178523d91@github.com>

On Thu, 23 Sep 2021 00:37:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Before the changes the mouseEntered and mouseExited events would constantly fire, while after the fix only a mouseEntered event would fire
> 
> Does it mean that after the fix we will post a few enter events w/o exit events? Then it is worse than posting enter/exit events that are paired, even if we will post many such pairs.

It always posts a single enter event without an exit event.
 
> > When the user maximizes the window a mouseEntered event does fire, so it preserves the fix for JDK-8028485.
> 
> Just for the record did you check what is the inLiveResize value when the user maximizes the window, or moves it to the full screen/tile the window to the left/right?

I checked for when the user maximizes the window and tiles to the left or right of the screen and both seem to work.

I just ran all the tests and my test fails on both windows and linux platforms so I think this bug isn't platform specific.

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

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


From serb at openjdk.java.net  Thu Sep 23 17:10:52 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 23 Sep 2021 17:10:52 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v5]
In-Reply-To: <mboe3-va-xCqCw-3V6v8dZCS3qKY6XCo1s-11A5SJT0=.6b82f148-0608-44be-bed9-c43178523d91@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <57_CpBYrvFjr586rGPWjeDbbLfUqqVcwDm4pbT2neO8=.e09a2e78-3d44-41c7-b2d0-8add8fcf8c2f@github.com>
 <GqCIC4UlNdfmK4fi5OtgVZGPc1br6JXZB_IqDCivIxg=.51b1bbe0-e8e0-4f47-a6bf-08322d610487@github.com>
 <mboe3-va-xCqCw-3V6v8dZCS3qKY6XCo1s-11A5SJT0=.6b82f148-0608-44be-bed9-c43178523d91@github.com>
Message-ID: <hL97MSSd0FzPLyjpYA69aVKPYaBHiwUWosienSYYXx0=.ae293cff-8a54-4608-9094-81be55a19b83@github.com>

On Thu, 23 Sep 2021 16:50:36 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> I checked for when the user maximizes the window and tiles to the left or right of the screen and both seem to work.

But what is the flag value? Is it true or false? If it's true and everything works maybe we do not need this line at all?

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

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


From serb at openjdk.java.net  Thu Sep 23 17:48:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 23 Sep 2021 17:48:56 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out
 on macOS 12
In-Reply-To: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
References: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
Message-ID: <d1b2YM4LZDIC2qwjYsh_lLLI_k4NQDU8eE_ga5B0U3M=.58fdda72-e354-4b55-b525-c18f08e9e4c1@github.com>

On Thu, 23 Sep 2021 06:47:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java is timing out every time on macOS 12 even though the test passed.
> Looks like the the main process waits for child process created in the test forever, making it timeout after jtreg timeout of 2min.
> Modified to wait for childprocess for 30secs.

It intentionally waits forever since if the child process is alive some bug has occurred. So you need to find why the child hangs.

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

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


From aivanov at openjdk.java.net  Thu Sep 23 18:51:37 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 23 Sep 2021 18:51:37 GMT
Subject: RFR: 8239502: [TEST_BUG] Test
 javax/swing/text/FlowView/6318524/bug6318524.java never fails
Message-ID: <G6yZf1yEz84BFlJbn20yWxMZTseik7J1tJVlGYpZfXE=.1a2bb761-74f0-451a-9db9-f54e67867d2b@github.com>

The test is being moved from the closed to open. It's nearly a complete re-write of the original test.

I made the test headless by painting into image.

To detect failure, the test uses the position of the caret at the end of first line of the paragraph where the wrapping occurs.

I made sure that the updated test reproduces the original problem in [JDK-6318524](https://bugs.openjdk.java.net/browse/JDK-6318524). (There are some tweaks required to compile it with JDK 6.) The updated test fails when run with 6-b52. In fact, it also fails with 6-b53 up to 6-b76 where [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882) is fixed.

The behaviour in 6-b76 coincides with that in the latest JDK.

[1] [JDK-6318524](https://bugs.openjdk.java.net/browse/JDK-6318524): Regression: views in paragraph are not children of Paragraph.Row is some cases
[2] [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882): Last line of a paragraph should not be justified

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

Commit messages:
 - 8239502: Make sure -saveAll saves all the images
 - 8239502: [TEST_BUG] Test javax/swing/text/FlowView/6318524/bug6318524.java never fails

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

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


From serb at openjdk.java.net  Thu Sep 23 19:13:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 23 Sep 2021 19:13:57 GMT
Subject: RFR: 8239502: [TEST_BUG] Test
 javax/swing/text/FlowView/6318524/bug6318524.java never fails
In-Reply-To: <G6yZf1yEz84BFlJbn20yWxMZTseik7J1tJVlGYpZfXE=.1a2bb761-74f0-451a-9db9-f54e67867d2b@github.com>
References: <G6yZf1yEz84BFlJbn20yWxMZTseik7J1tJVlGYpZfXE=.1a2bb761-74f0-451a-9db9-f54e67867d2b@github.com>
Message-ID: <mRDQET1hNaOhDulXljag0a1Ci3kmQ6c4aGay-rln9vU=.5ed31ee9-27dc-4852-9bd1-40e2ff18f895@github.com>

On Thu, 23 Sep 2021 18:41:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test is being moved from the closed to open. It's nearly a complete re-write of the original test.
> 
> I made the test headless by painting into image.
> 
> To detect failure, the test uses the position of the caret at the end of first line of the paragraph where the wrapping occurs.
> 
> I made sure that the updated test reproduces the original problem in [JDK-6318524](https://bugs.openjdk.java.net/browse/JDK-6318524). (There are some tweaks required to compile it with JDK 6.) The updated test fails when run with 6-b52. In fact, it also fails with 6-b53 up to 6-b76 where [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882) is fixed.
> 
> The behaviour in 6-b76 coincides with that in the latest JDK.
> 
> [1] [JDK-6318524](https://bugs.openjdk.java.net/browse/JDK-6318524): Regression: views in paragraph are not children of Paragraph.Row is some cases
> [2] [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882): Last line of a paragraph should not be justified

Marked as reviewed by serb (Reviewer).

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

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


From aivanov at openjdk.java.net  Thu Sep 23 19:28:17 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 23 Sep 2021 19:28:17 GMT
Subject: RFR: 8273634: [TEST_BUG] Improve
 javax/swing/text/ParagraphView/6364882/bug6364882.java
Message-ID: <acWloNjzZyq31_HOlFJtQL-B7tVJE0PeAm-gXSUSa88=.79753fa2-d1b1-49b1-b972-d487be9011b4@github.com>

The test is being moved from the closed to open.

I updated the `bug6364882.java` test so that it's headless now. If it fails, the image of the `editorPane` is saved for analysis. I also added more asserts which verify:

? the first three lines are aligned to the right edge;
? the fourth line isn't justified and its width is less than 3/4 of the width;
? the fifth and sixth lines have width less than that of the fourth line and have the same width.

There's an option to show the UI for visual inspection as well as to save the image even if the test passes; use `-show` and/or `-save` parameters to the test correspondingly.

[1] [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882): Last line of a paragraph should not be justified

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

Commit messages:
 - 8273634: [TEST_BUG] Improve javax/swing/text/ParagraphView/6364882/bug6364882.java

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

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


From alexander.zuev at oracle.com  Thu Sep 23 19:50:29 2021
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Thu, 23 Sep 2021 12:50:29 -0700
Subject: [macOS] Is there a Roadmap for availability of NSAcccessibility
 implementation?
In-Reply-To: <AM0PR02MB58117FAADE5FB7A6DC53E62B86A39@AM0PR02MB5811.eurprd02.prod.outlook.com>
References: <AM0PR02MB58117FAADE5FB7A6DC53E62B86A39@AM0PR02MB5811.eurprd02.prod.outlook.com>
Message-ID: <07748a05-2a81-a3eb-0b0c-b28b8e40f444@oracle.com>

Hi Josef,

 ? yes, the three and table navigation announcements are known issues 
that we are trying
to deal with in the upcoming re-implementation of the accessibility 
native code responsible
for interaction between Java and Mac OS X system Accessibility API.

 ? The main task with the roadmap is indeed 
https://bugs.openjdk.java.net/browse/JDK-8152350

 ? Table part is currently on review here: 
https://github.com/openjdk/jdk/pull/5466

 ? Tree part should be addressed in a consequent bug fix.

 ? Current plan is to implement the new code in JDK 18 and then backport 
it to an appropriate JDK 17 update release.

 ? If you see any accessibility issue not being resolved by already 
implemented code please file a bug
and we will look at it in addition to the current general rework.

With best regards,
/Alex

On 9/23/21 06:27, Koeble, Josef wrote:
> Hi,
>
> we are using OpenJDK for our large Java Swing application. When testing our application for Accessibility running with JDK 17 on macOS with its screen reader VoiceOver, we realize some bigger issues (e.g. no announcements in tree or in table). These issues also occur when testing SwingSet running the same environment. On Windows running screen reader JAWS or NVDA, there are no such issues.
>
> I found the following bug task, happy to read that you are working on it:
> https://bugs.openjdk.java.net/browse/JDK-8152350
> When testing with JDK 18, I noticed that some of the issues were fixed.
>
> Is there any roadmap for the availability of the complete NSAccessibility implementation?
>
> Thanks and best regards,
> Josef



From github.com+90066231+alisenchung at openjdk.java.net  Thu Sep 23 20:29:58 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Thu, 23 Sep 2021 20:29:58 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v5]
In-Reply-To: <hL97MSSd0FzPLyjpYA69aVKPYaBHiwUWosienSYYXx0=.ae293cff-8a54-4608-9094-81be55a19b83@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <57_CpBYrvFjr586rGPWjeDbbLfUqqVcwDm4pbT2neO8=.e09a2e78-3d44-41c7-b2d0-8add8fcf8c2f@github.com>
 <GqCIC4UlNdfmK4fi5OtgVZGPc1br6JXZB_IqDCivIxg=.51b1bbe0-e8e0-4f47-a6bf-08322d610487@github.com>
 <mboe3-va-xCqCw-3V6v8dZCS3qKY6XCo1s-11A5SJT0=.6b82f148-0608-44be-bed9-c43178523d91@github.com>
 <hL97MSSd0FzPLyjpYA69aVKPYaBHiwUWosienSYYXx0=.ae293cff-8a54-4608-9094-81be55a19b83@github.com>
Message-ID: <u5gbtUqadhb2mBqdqZy-Okek_5_hLLpMzQBuBCoL-6M=.05e4698c-dc77-44d7-8386-c5769f01841f@github.com>

On Thu, 23 Sep 2021 17:07:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I checked for when the user maximizes the window and tiles to the left or right of the screen and both seem to work.
> 
> But what is the flag value? Is it true or false? If it's true and everything works maybe we do not need this line at all?

Oh the flag is always true. And removing the line completely fixes the bug and doesn't have any problems with fullscreen or tiling.

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

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


From github.com+90066231+alisenchung at openjdk.java.net  Thu Sep 23 20:42:28 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Thu, 23 Sep 2021 20:42:28 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v7]
In-Reply-To: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
Message-ID: <71SXyzArsgn7Xd9Kk-2f03DqZdWVeWVMKnfx893TVk8=.06a4b9f2-d4b0-4c09-9ed3-cff90957fbb5@github.com>

> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.

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

  removed synthesizeMouseEnteredExitEvent call

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5497/files
  - new: https://git.openjdk.java.net/jdk/pull/5497/files/ce46976f..024f15cf

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

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

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


From prr at openjdk.java.net  Thu Sep 23 21:53:56 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 23 Sep 2021 21:53:56 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v5]
In-Reply-To: <u5gbtUqadhb2mBqdqZy-Okek_5_hLLpMzQBuBCoL-6M=.05e4698c-dc77-44d7-8386-c5769f01841f@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <57_CpBYrvFjr586rGPWjeDbbLfUqqVcwDm4pbT2neO8=.e09a2e78-3d44-41c7-b2d0-8add8fcf8c2f@github.com>
 <GqCIC4UlNdfmK4fi5OtgVZGPc1br6JXZB_IqDCivIxg=.51b1bbe0-e8e0-4f47-a6bf-08322d610487@github.com>
 <mboe3-va-xCqCw-3V6v8dZCS3qKY6XCo1s-11A5SJT0=.6b82f148-0608-44be-bed9-c43178523d91@github.com>
 <hL97MSSd0FzPLyjpYA69aVKPYaBHiwUWosienSYYXx0=.ae293cff-8a54-4608-9094-81be55a19b83@github.com>
 <u5gbtUqadhb2mBqdqZy-Okek_5_hLLpMzQBuBCoL-6M=.05e4698c-dc77-44d7-8386-c5769f01841f@github.com>
Message-ID: <g-Aa0w-ayHdF9wpwBtrKQ2qxxy-djWQllojs1YFpIEg=.64f0e4a3-95ce-4e17-b567-236c45576979@github.com>

On Thu, 23 Sep 2021 20:26:43 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> > > I checked for when the user maximizes the window and tiles to the left or right of the screen and both seem to work.
> > 
> > 
> > But what is the flag value? Is it true or false? If it's true and everything works maybe we do not need this line at all?
> 
> Oh the flag is always true. And removing the line completely fixes the bug and doesn't have any problems with fullscreen or tiling.

Surely that was there for a reason ? Looks like it might be important for the synthesized full screen mode ?
It was added in that location by this fix : https://mail.openjdk.java.net/pipermail/awt-dev/2013-November/006372.html
and that just moved it a few lines so it was already in use before then.

Does the test from there still pass ? Any others fail ?

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

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


From serb at openjdk.java.net  Fri Sep 24 00:09:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 24 Sep 2021 00:09:54 GMT
Subject: RFR: 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: <TF2nR4DsOOHYy4JAIso3xuTZou-nTQ1-eI5qfGb6QN4=.12818eea-e0f7-4543-8e42-9bad9516591c@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)

Does it mean that the app will hang if it tries to dispose of the full-screen window? Why does it is happening? The dispose machinery in the window class should handle this case:
DisposeAction{
....
                if (gd.getFullScreenWindow() == Window.this) {
                    gd.setFullScreenWindow(null);
                }

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

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


From serb at openjdk.java.net  Fri Sep 24 00:12:53 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 24 Sep 2021 00:12:53 GMT
Subject: RFR: 8273634: [TEST_BUG] Improve
 javax/swing/text/ParagraphView/6364882/bug6364882.java
In-Reply-To: <acWloNjzZyq31_HOlFJtQL-B7tVJE0PeAm-gXSUSa88=.79753fa2-d1b1-49b1-b972-d487be9011b4@github.com>
References: <acWloNjzZyq31_HOlFJtQL-B7tVJE0PeAm-gXSUSa88=.79753fa2-d1b1-49b1-b972-d487be9011b4@github.com>
Message-ID: <G2fBqexjzWZ40knDVk9xN5Uran2YYdC6j0_vFKNTyXQ=.6d86abaa-74a6-4f97-b204-9f6829b6727c@github.com>

On Thu, 23 Sep 2021 19:19:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test is being moved from the closed to open.
> 
> I updated the `bug6364882.java` test so that it's headless now. If it fails, the image of the `editorPane` is saved for analysis. I also added more asserts which verify:
> 
> ? the first three lines are aligned to the right edge;
> ? the fourth line isn't justified and its width is less than 3/4 of the width;
> ? the fifth and sixth lines have width less than that of the fourth line and have the same width.
> 
> There's an option to show the UI for visual inspection as well as to save the image even if the test passes; use `-show` and/or `-save` parameters to the test correspondingly.
> 
> [1] [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882): Last line of a paragraph should not be justified

I assume that an updated test still fail before JDK-6364882

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

Marked as reviewed by serb (Reviewer).

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


From psadhukhan at openjdk.java.net  Fri Sep 24 05:53:55 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 24 Sep 2021 05:53:55 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out
 on macOS 12
In-Reply-To: <d1b2YM4LZDIC2qwjYsh_lLLI_k4NQDU8eE_ga5B0U3M=.58fdda72-e354-4b55-b525-c18f08e9e4c1@github.com>
References: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
 <d1b2YM4LZDIC2qwjYsh_lLLI_k4NQDU8eE_ga5B0U3M=.58fdda72-e354-4b55-b525-c18f08e9e4c1@github.com>
Message-ID: <hdfRvJS_ZhlFZ4LQdWCQQoFIl1D44tpx_uSzkrKz8mg=.83d0d900-873f-47ee-b904-5bdff400649e@github.com>

On Thu, 23 Sep 2021 17:46:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> 
> 
> It intentionally waits forever since if the child process is alive some bug has occurred. So you need to find why the child hangs.

Can you point out which bugs you were referring to if we don't wait for ever? AFAICT, it was done that way in jdk6(JDK-6358034) because there was no provision for waitFor(timeout), it only has waitFor() API...If test cannot finish/change display in 30secs, then it should fail..

-------------

PR: https://git.openjdk.java.net/jdk/pull/5647


From psadhukhan at openjdk.java.net  Fri Sep 24 07:21:58 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 24 Sep 2021 07:21:58 GMT
Subject: RFR: 8239502: [TEST_BUG] Test
 javax/swing/text/FlowView/6318524/bug6318524.java never fails
In-Reply-To: <G6yZf1yEz84BFlJbn20yWxMZTseik7J1tJVlGYpZfXE=.1a2bb761-74f0-451a-9db9-f54e67867d2b@github.com>
References: <G6yZf1yEz84BFlJbn20yWxMZTseik7J1tJVlGYpZfXE=.1a2bb761-74f0-451a-9db9-f54e67867d2b@github.com>
Message-ID: <QdUZYGdk_rzrzSDsEag5OvQ4iRvZOaADaBsX278mrGM=.b141a782-9e35-4189-8e0c-7b66c2f209be@github.com>

On Thu, 23 Sep 2021 18:41:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test is being moved from the closed to open. It's nearly a complete re-write of the original test.
> 
> I made the test headless by painting into image.
> 
> To detect failure, the test uses the position of the caret at the end of first line of the paragraph where the wrapping occurs.
> 
> I made sure that the updated test reproduces the original problem in [JDK-6318524](https://bugs.openjdk.java.net/browse/JDK-6318524). (There are some tweaks required to compile it with JDK 6.) The updated test fails when run with 6-b52. In fact, it also fails with 6-b53 up to 6-b76 where [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882) is fixed.
> 
> The behaviour in 6-b76 coincides with that in the latest JDK.
> 
> There are three parameters provided for debugging purposes:
> ? `-show`: Show frame for visual inspection
> ? `-save`: Save *the start image* after the first paragraph is justified, and *the last image* before it's checked that the first paragraph remains justified
> ? `-saveAll`: Save images for all the intermediate steps
> 
> [1] [JDK-6318524](https://bugs.openjdk.java.net/browse/JDK-6318524): Regression: views in paragraph are not children of Paragraph.Row is some cases
> [2] [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882): Last line of a paragraph should not be justified

Probably it will be better to use descriptive name for the test rather than bugid. Probably it was done to maintain consistency with closed test but since it is supposedly a rewrite and we have done away with bugid in testname, a descriptive name will be better. Also @bug tag will let us know for which it was written..

-------------

PR: https://git.openjdk.java.net/jdk/pull/5660


From myano at openjdk.java.net  Fri Sep 24 11:19:53 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 24 Sep 2021 11:19:53 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <ACRHmQY8PTs2zOxEKTqpI3UP2P_OdWXHccoaHC3FrwM=.6bd5a2c9-b92e-4fbb-babe-005fa463a221@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <ACRHmQY8PTs2zOxEKTqpI3UP2P_OdWXHccoaHC3FrwM=.6bd5a2c9-b92e-4fbb-babe-005fa463a221@github.com>
Message-ID: <G4VS1_zNJrOsdiajA3_BrSPWpxzSsRafaUs66mTXv4s=.9a7105b0-c946-4815-a118-00c9fd17cbe1@github.com>

On Fri, 17 Sep 2021 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> my question was why the first CopyArea is ignored? 

This is a RepaintArea's behavior. clearRect() is called before paint() because shouldClearRectBeforePaint is true for Canvas. Then, if 2nd paint() is called and paint() does nothing, blank window will be drawn.
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/awt/RepaintArea.java#L235

-------------

PR: https://git.openjdk.java.net/jdk/pull/5491


From aivanov at openjdk.java.net  Fri Sep 24 15:13:56 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 24 Sep 2021 15:13:56 GMT
Subject: RFR: 8239502: [TEST_BUG] Test
 javax/swing/text/FlowView/6318524/bug6318524.java never fails
In-Reply-To: <QdUZYGdk_rzrzSDsEag5OvQ4iRvZOaADaBsX278mrGM=.b141a782-9e35-4189-8e0c-7b66c2f209be@github.com>
References: <G6yZf1yEz84BFlJbn20yWxMZTseik7J1tJVlGYpZfXE=.1a2bb761-74f0-451a-9db9-f54e67867d2b@github.com>
 <QdUZYGdk_rzrzSDsEag5OvQ4iRvZOaADaBsX278mrGM=.b141a782-9e35-4189-8e0c-7b66c2f209be@github.com>
Message-ID: <HhMSTX-nGZGjequoDRCgPU7e7S6j85rN40tBc4BPrmc=.88e7e2e3-57c8-4426-8330-0db2c0ac5065@github.com>

On Fri, 24 Sep 2021 07:19:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Probably it will be better to use descriptive name for the test rather than bugid.

In the majority of cases, the test name is not detailed enough, however, it usually gives a better idea than a plain bugid. If a test fails, you still have to analyse it.

> Probably it was done to maintain consistency with closed test but since it is supposedly a rewrite and we have done away with bugid in testname, a descriptive name will be better. Also @bug tag will let us know for which it was written..

Even if it's completely re-written, it's not a new test. I'd rather keep the original name: searching for it returns some bugs; if the test name is changed, those search results are lost.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5660


From aivanov at openjdk.java.net  Fri Sep 24 15:20:28 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 24 Sep 2021 15:20:28 GMT
Subject: RFR: 8273634: [TEST_BUG] Improve
 javax/swing/text/ParagraphView/6364882/bug6364882.java
In-Reply-To: <G2fBqexjzWZ40knDVk9xN5Uran2YYdC6j0_vFKNTyXQ=.6d86abaa-74a6-4f97-b204-9f6829b6727c@github.com>
References: <acWloNjzZyq31_HOlFJtQL-B7tVJE0PeAm-gXSUSa88=.79753fa2-d1b1-49b1-b972-d487be9011b4@github.com>
 <G2fBqexjzWZ40knDVk9xN5Uran2YYdC6j0_vFKNTyXQ=.6d86abaa-74a6-4f97-b204-9f6829b6727c@github.com>
Message-ID: <a9wZhD_r-TZWHMZ59mPW3TRx1KE6q3M-GQWRtDSWeII=.01ad0730-8053-458b-a639-ce2a73a72394@github.com>

On Fri, 24 Sep 2021 00:09:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I assume that an updated test still fail before JDK-6364882

Correct. I forgot to add this statement. The updated test fails with builds of JDK 6 until [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882) is fixed, that is the test fails when run with 6-b75 and passes when run with 6-b76.

In this way the test and PR are related to [JDK-8239502](https://bugs.openjdk.java.net/browse/JDK-8239502) and #5661 correspondingly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5661


From prr at openjdk.java.net  Fri Sep 24 16:37:10 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 24 Sep 2021 16:37:10 GMT
Subject: RFR: 8274296: Update or Problem List tests which may fail with
 uiScale=2 on macOS
Message-ID: <o77KLdyNbhOElBjnDjT8Q67oOXovFluJOQtIm8HIj0E=.388c84b8-3082-425c-9775-28a9560f8bce@github.com>

As described in https://bugs.openjdk.java.net/browse/JDK-8274106 a number of tests fail due to some inaccuracy in pixels copied from the screen when scaling down from device space to user space.
The subject of most of these tests is such that uiScale isn't important and we can have them pass with -Dsun.java2d.uiScale=1.
For the rest we can problem list them - as narrowly as we can on macos-aarch64 which is the only place we've seen the problem (not happening on retina displays with x64 it seems) whilst we try to figure out the root cause which is either in Apple code or something we are doing to trigger that Apple API misbehaviour.

-------------

Commit messages:
 - 8274296: Update or Problem List tests which may fail with uiScale=2 on macOS

Changes: https://git.openjdk.java.net/jdk/pull/5687/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5687&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274296
  Stats: 14 lines in 9 files changed: 6 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5687.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5687/head:pull/5687

PR: https://git.openjdk.java.net/jdk/pull/5687


From github.com+90066231+alisenchung at openjdk.java.net  Fri Sep 24 17:07:05 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Fri, 24 Sep 2021 17:07:05 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v5]
In-Reply-To: <g-Aa0w-ayHdF9wpwBtrKQ2qxxy-djWQllojs1YFpIEg=.64f0e4a3-95ce-4e17-b567-236c45576979@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <57_CpBYrvFjr586rGPWjeDbbLfUqqVcwDm4pbT2neO8=.e09a2e78-3d44-41c7-b2d0-8add8fcf8c2f@github.com>
 <GqCIC4UlNdfmK4fi5OtgVZGPc1br6JXZB_IqDCivIxg=.51b1bbe0-e8e0-4f47-a6bf-08322d610487@github.com>
 <mboe3-va-xCqCw-3V6v8dZCS3qKY6XCo1s-11A5SJT0=.6b82f148-0608-44be-bed9-c43178523d91@github.com>
 <hL97MSSd0FzPLyjpYA69aVKPYaBHiwUWosienSYYXx0=.ae293cff-8a54-4608-9094-81be55a19b83@github.com>
 <u5gbtUqadhb2mBqdqZy-Okek_5_hLLpMzQBuBCoL-6M=.05e4698c-dc77-44d7-8386-c5769f01841f@github.com>
 <g-Aa0w-ayHdF9wpwBtrKQ2qxxy-djWQllojs1YFpIEg=.64f0e4a3-95ce-4e17-b567-236c45576979@github.com>
Message-ID: <QItelGXQ3wfHIrIdt_PL1ocquQzWVjB4Ox6xvXRtwUY=.ba15cc5f-cb2e-4b88-b352-db90f91216a9@github.com>

On Thu, 23 Sep 2021 21:50:57 GMT, Phil Race <prr at openjdk.org> wrote:

> > > > I checked for when the user maximizes the window and tiles to the left or right of the screen and both seem to work.
> > > 
> > > 
> > > But what is the flag value? Is it true or false? If it's true and everything works maybe we do not need this line at all?
> > 
> > 
> > Oh the flag is always true. And removing the line completely fixes the bug and doesn't have any problems with fullscreen or tiling.
> 
> Surely that was there for a reason ? Looks like it might be important for the synthesized full screen mode ?
> It was added in that location by this fix : https://mail.openjdk.java.net/pipermail/awt-dev/2013-November/006372.html
> and that just moved it a few lines so it was already in use before then.

Sergey did mention it was added as a fix for JDK-8028485 earlier too. Reverting the changes made by JDK-8028485 doesn't seem to reintroduce the fullscreen not firing mouseEntered bug, so I'm not exactly sure how that fix worked. Behavior seems to be the same regardless of the position of the [AWTWindow synthesizeMouseEnteredExitedEventsForAllWindows] line.

> 
> Does the test from there still pass ? Any others fail ?

All manual and automatic tests are passing on macOS.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From jdv at openjdk.java.net  Fri Sep 24 17:26:50 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Fri, 24 Sep 2021 17:26:50 GMT
Subject: RFR: 8274296: Update or Problem List tests which may fail with
 uiScale=2 on macOS
In-Reply-To: <o77KLdyNbhOElBjnDjT8Q67oOXovFluJOQtIm8HIj0E=.388c84b8-3082-425c-9775-28a9560f8bce@github.com>
References: <o77KLdyNbhOElBjnDjT8Q67oOXovFluJOQtIm8HIj0E=.388c84b8-3082-425c-9775-28a9560f8bce@github.com>
Message-ID: <BjIEmo2fdrlohssdGu19241SNX2uWVgwAImXN3GHzKo=.00a2efb3-ddd6-4c85-92d0-a4e346f023f0@github.com>

On Fri, 24 Sep 2021 16:28:51 GMT, Phil Race <prr at openjdk.org> wrote:

> As described in https://bugs.openjdk.java.net/browse/JDK-8274106 a number of tests fail due to some inaccuracy in pixels copied from the screen when scaling down from device space to user space.
> The subject of most of these tests is such that uiScale isn't important and we can have them pass with -Dsun.java2d.uiScale=1.
> For the rest we can problem list them - as narrowly as we can on macos-aarch64 which is the only place we've seen the problem (not happening on retina displays with x64 it seems) whilst we try to figure out the root cause which is either in Apple code or something we are doing to trigger that Apple API misbehaviour.

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5687


From prr at openjdk.java.net  Fri Sep 24 17:32:56 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 24 Sep 2021 17:32:56 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v7]
In-Reply-To: <71SXyzArsgn7Xd9Kk-2f03DqZdWVeWVMKnfx893TVk8=.06a4b9f2-d4b0-4c09-9ed3-cff90957fbb5@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <71SXyzArsgn7Xd9Kk-2f03DqZdWVeWVMKnfx893TVk8=.06a4b9f2-d4b0-4c09-9ed3-cff90957fbb5@github.com>
Message-ID: <XHLWxKAe8-HPDLXv18aAA0qyZp-QoVtmZ8lwGYWR_Gk=.31e2afca-8ed2-4c89-bc25-819d6a9d9042@github.com>

On Thu, 23 Sep 2021 20:42:28 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed synthesizeMouseEnteredExitEvent call

OK. Unless someone else can point out what we are missing it seems like it should resolve this issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From prr at openjdk.java.net  Fri Sep 24 17:34:58 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 24 Sep 2021 17:34:58 GMT
Subject: Integrated: 8274296: Update or Problem List tests which may fail with
 uiScale=2 on macOS
In-Reply-To: <o77KLdyNbhOElBjnDjT8Q67oOXovFluJOQtIm8HIj0E=.388c84b8-3082-425c-9775-28a9560f8bce@github.com>
References: <o77KLdyNbhOElBjnDjT8Q67oOXovFluJOQtIm8HIj0E=.388c84b8-3082-425c-9775-28a9560f8bce@github.com>
Message-ID: <EJLG0MNZ8uQ89x4x2zbdIcs2cw4zB9rGCgLKTf8QpQY=.0350724e-d25d-4614-9219-49b2d8bed021@github.com>

On Fri, 24 Sep 2021 16:28:51 GMT, Phil Race <prr at openjdk.org> wrote:

> As described in https://bugs.openjdk.java.net/browse/JDK-8274106 a number of tests fail due to some inaccuracy in pixels copied from the screen when scaling down from device space to user space.
> The subject of most of these tests is such that uiScale isn't important and we can have them pass with -Dsun.java2d.uiScale=1.
> For the rest we can problem list them - as narrowly as we can on macos-aarch64 which is the only place we've seen the problem (not happening on retina displays with x64 it seems) whilst we try to figure out the root cause which is either in Apple code or something we are doing to trigger that Apple API misbehaviour.

This pull request has now been integrated.

Changeset: 753b2563
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/753b25633bf07eed40fd25b4b89313644763cd56
Stats:     14 lines in 9 files changed: 6 ins; 0 del; 8 mod

8274296: Update or Problem List tests which may fail with uiScale=2 on macOS

Reviewed-by: jdv

-------------

PR: https://git.openjdk.java.net/jdk/pull/5687


From serb at openjdk.java.net  Fri Sep 24 18:11:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 24 Sep 2021 18:11:56 GMT
Subject: RFR: 8274296: Update or Problem List tests which may fail with
 uiScale=2 on macOS
In-Reply-To: <o77KLdyNbhOElBjnDjT8Q67oOXovFluJOQtIm8HIj0E=.388c84b8-3082-425c-9775-28a9560f8bce@github.com>
References: <o77KLdyNbhOElBjnDjT8Q67oOXovFluJOQtIm8HIj0E=.388c84b8-3082-425c-9775-28a9560f8bce@github.com>
Message-ID: <6n1wcxANYyG7C0Xd5kx0nPIndVYGX-EOxsctGDtDQsY=.7cc105d3-029e-40d7-8f20-303900f1517a@github.com>

On Fri, 24 Sep 2021 16:28:51 GMT, Phil Race <prr at openjdk.org> wrote:

> As described in https://bugs.openjdk.java.net/browse/JDK-8274106 a number of tests fail due to some inaccuracy in pixels copied from the screen when scaling down from device space to user space.
> The subject of most of these tests is such that uiScale isn't important and we can have them pass with -Dsun.java2d.uiScale=1.
> For the rest we can problem list them - as narrowly as we can on macos-aarch64 which is the only place we've seen the problem (not happening on retina displays with x64 it seems) whilst we try to figure out the root cause which is either in Apple code or something we are doing to trigger that Apple API misbehaviour.

test/jdk/java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java line 29:

> 27:  * @summary [macosx] Order of overlapping of modal dialogs is wrong
> 28:  * @key headful
> 29:  * @run main/othervm -Dsun.java2d.uiScale=1 SiblingChildOrderTest

Switching this tests to scale=1 seems completely wrong. On macos it just tweak the rendering so that bug became invisible due to lost of precision. And now we will run the tests in lowDPI on all other platforms.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5687


From josef.koeble at sap.com  Fri Sep 24 18:49:56 2021
From: josef.koeble at sap.com (Koeble, Josef)
Date: Fri, 24 Sep 2021 18:49:56 +0000
Subject: [macOS] Is there a Roadmap for availability of NSAcccessibility
 implementation?
In-Reply-To: <07748a05-2a81-a3eb-0b0c-b28b8e40f444@oracle.com>
References: <AM0PR02MB58117FAADE5FB7A6DC53E62B86A39@AM0PR02MB5811.eurprd02.prod.outlook.com>
 <07748a05-2a81-a3eb-0b0c-b28b8e40f444@oracle.com>
Message-ID: <AM0PR02MB5811C3433BD7718B51B2454386A49@AM0PR02MB5811.eurprd02.prod.outlook.com>

Hi Alex,

thank you for your quick response! We are glad to read that you will backport these fixes to JDK 17.

As we are interested in a good interaction between Java Accessibility API and macOS system Accessibility API, I plan to do some tests with VoiceOver.

In a first quick test with SwingSet I noticed that VoiceOver announces some information of JTree (e.g. role, node/item text, open/close action) and JTable (role, cell text), but I missed the essential structure information like:
Focus on tree items -> level of node/item in tree structure, number of focused item and total number of items within the parent node
Focus on table cells -> number of column and number of row, text of column header

I also noticed that the bug task is still open, and possibly this has already been implemented. Therefore I will check with the next pre-release build.

Best regards,
Josef

-----Original Message-----
From: Alexander Zuev <alexander.zuev at oracle.com> 
Sent: Donnerstag, 23. September 2021 21:50
To: client-libs-dev at openjdk.java.net
Subject: Re: [macOS] Is there a Roadmap for availability of NSAcccessibility implementation?

Hi Josef,

 ? yes, the three and table navigation announcements are known issues 
that we are trying
to deal with in the upcoming re-implementation of the accessibility 
native code responsible
for interaction between Java and Mac OS X system Accessibility API.

 ? The main task with the roadmap is indeed 
https://bugs.openjdk.java.net/browse/JDK-8152350

 ? Table part is currently on review here: 
https://github.com/openjdk/jdk/pull/5466

 ? Tree part should be addressed in a consequent bug fix.

 ? Current plan is to implement the new code in JDK 18 and then backport 
it to an appropriate JDK 17 update release.

 ? If you see any accessibility issue not being resolved by already 
implemented code please file a bug
and we will look at it in addition to the current general rework.

With best regards,
/Alex

On 9/23/21 06:27, Koeble, Josef wrote:
> Hi,
>
> we are using OpenJDK for our large Java Swing application. When testing our application for Accessibility running with JDK 17 on macOS with its screen reader VoiceOver, we realize some bigger issues (e.g. no announcements in tree or in table). These issues also occur when testing SwingSet running the same environment. On Windows running screen reader JAWS or NVDA, there are no such issues.
>
> I found the following bug task, happy to read that you are working on it:
> https://bugs.openjdk.java.net/browse/JDK-8152350
> When testing with JDK 18, I noticed that some of the issues were fixed.
>
> Is there any roadmap for the availability of the complete NSAccessibility implementation?
>
> Thanks and best regards,
> Josef


From serb at openjdk.java.net  Fri Sep 24 19:12:51 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 24 Sep 2021 19:12:51 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out
 on macOS 12
In-Reply-To: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
References: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
Message-ID: <0l5z_wkpUjhi5xVuWoWgHOvu83o5KSQ_FyxlAOUbAjk=.02048230-bb3b-41cb-9918-1ee1949b361d@github.com>

On Thu, 23 Sep 2021 06:47:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java is timing out every time on macOS 12 even though the test passed.
> Looks like the the main process waits for child process created in the test forever, making it timeout after jtreg timeout of 2min.
> Modified to wait for childprocess for 30secs.

Are you sure that if it cannot change the display in two minutes it should pass? It looks like an important bug.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5647


From serb at openjdk.java.net  Fri Sep 24 19:52:58 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 24 Sep 2021 19:52:58 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v5]
In-Reply-To: <QItelGXQ3wfHIrIdt_PL1ocquQzWVjB4Ox6xvXRtwUY=.ba15cc5f-cb2e-4b88-b352-db90f91216a9@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <57_CpBYrvFjr586rGPWjeDbbLfUqqVcwDm4pbT2neO8=.e09a2e78-3d44-41c7-b2d0-8add8fcf8c2f@github.com>
 <GqCIC4UlNdfmK4fi5OtgVZGPc1br6JXZB_IqDCivIxg=.51b1bbe0-e8e0-4f47-a6bf-08322d610487@github.com>
 <mboe3-va-xCqCw-3V6v8dZCS3qKY6XCo1s-11A5SJT0=.6b82f148-0608-44be-bed9-c43178523d91@github.com>
 <hL97MSSd0FzPLyjpYA69aVKPYaBHiwUWosienSYYXx0=.ae293cff-8a54-4608-9094-81be55a19b83@github.com>
 <u5gbtUqadhb2mBqdqZy-Okek_5_hLLpMzQBuBCoL-6M=.05e4698c-dc77-44d7-8386-c5769f01841f@github.com>
 <g-Aa0w-ayHdF9wpwBtrKQ2qxxy-djWQllojs1YFpIEg=.64f0e4a3-95ce-4e17-b567-236c45576979@github.com>
 <QItelGXQ3wfHIrIdt_PL1ocquQzWVjB4Ox6xvXRtwUY=.ba15cc5f-cb2e-4b88-b352-db90f91216a9@github.com>
Message-ID: <0yD747f6JnEANPofJGjHIQ9pcbwfhEvM1IzJ9SDYZH4=.cc859447-00fd-4254-8946-452b25f89be1@github.com>

On Fri, 24 Sep 2021 17:03:21 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> > Does the test from there still pass ? Any others fail ?
> 
> All manual and automatic tests are passing on macOS.

I guess the only test which makes sense here is the test for JDK-8013468 and it is "problem listed" due to a reflection issue. I suggest checking how it works.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From serb at openjdk.java.net  Fri Sep 24 20:00:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 24 Sep 2021 20:00:57 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <G4VS1_zNJrOsdiajA3_BrSPWpxzSsRafaUs66mTXv4s=.9a7105b0-c946-4815-a118-00c9fd17cbe1@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <ACRHmQY8PTs2zOxEKTqpI3UP2P_OdWXHccoaHC3FrwM=.6bd5a2c9-b92e-4fbb-babe-005fa463a221@github.com>
 <G4VS1_zNJrOsdiajA3_BrSPWpxzSsRafaUs66mTXv4s=.9a7105b0-c946-4815-a118-00c9fd17cbe1@github.com>
Message-ID: <YEhDJGgk1J8Ah3dE9amNf6NrOgU6iy6Z23bY9IWA8KM=.c36e6711-f2c1-447b-a9c8-4eb8d2e7516f@github.com>

On Fri, 24 Sep 2021 11:17:18 GMT, Masanori Yano <myano at openjdk.org> wrote:

> This is a RepaintArea's behavior. clearRect() is called before paint() because shouldClearRectBeforePaint is true for Canvas. Then, if 2nd paint() is called and paint() does nothing, blank window will be drawn.

So the "sun.awt.noerasebackground" property may fix the problem? Or simple freeze the EDT after g2d.copyArea?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5491


From serb at openjdk.java.net  Fri Sep 24 20:14:19 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 24 Sep 2021 20:14:19 GMT
Subject: RFR: 8273972: Multi-core choke point in CMM engine
 (LCMSTransform.doTransform)
Message-ID: <RhBRJTwa0ln5XW5QlVODQBWcWjD25PIeVq5n14b1P5A=.ab864a64-9368-43d1-8761-a8892acbc63f@github.com>

Initially, the bug was discussed here:
https://stackoverflow.com/questions/35264582/why-is-multithreading-slowing-down/35264813

The root cause is that if for some reason directly or indirectly the color transform object is shared across the threads it cannot be used for parallel color transformation because the method LCMSTransform.doTransform()  is synchronized.

This code seems to be created when the littlecms 1.x was used which was not thread-safe, but the latest version is thread safe (subject to bugs). I can check that by compiling lcms with #define CMS_NO_PTHREADS which will cause some of our tests fail here and there.

To check that transform can be used across the threads I created two quite heavyweight tests which tests different color transformations using different threads.

The fix moves the data for the native transform from the LCMSTransform object to the NativeTransform class just to simplify synchronization steps, so only one volatile read of "transform" is executed in the common path.

Result for the testcase attached to SO: https://stackoverflow.com/a/35264713
|? threads|Before the fix|After the fix|
|-------------|-------------|-------------|
|1 |  693 ms | 699 ms|
|8 | 6641 ms| 873 ms|
|30 |34069 ms|1034 ms|

-------------

Commit messages:
 - Merge branch 'master' into JDK-8273972
 - new test
 - the test and comments
 - Initial version JDK-8273972

Changes: https://git.openjdk.java.net/jdk/pull/5671/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5671&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273972
  Stats: 358 lines in 5 files changed: 317 ins; 25 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5671.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5671/head:pull/5671

PR: https://git.openjdk.java.net/jdk/pull/5671


From serb at openjdk.java.net  Fri Sep 24 20:14:20 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 24 Sep 2021 20:14:20 GMT
Subject: RFR: 8273972: Multi-core choke point in CMM engine
 (LCMSTransform.doTransform)
In-Reply-To: <RhBRJTwa0ln5XW5QlVODQBWcWjD25PIeVq5n14b1P5A=.ab864a64-9368-43d1-8761-a8892acbc63f@github.com>
References: <RhBRJTwa0ln5XW5QlVODQBWcWjD25PIeVq5n14b1P5A=.ab864a64-9368-43d1-8761-a8892acbc63f@github.com>
Message-ID: <Ll5kvYTvbzM4gh82hkSM2LTMtyZEJEBotz2h1HbMq3I=.8ee112fa-fc71-4b11-ac56-b6c5a6d12c31@github.com>

On Fri, 24 Sep 2021 04:38:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Initially, the bug was discussed here:
> https://stackoverflow.com/questions/35264582/why-is-multithreading-slowing-down/35264813
> 
> The root cause is that if for some reason directly or indirectly the color transform object is shared across the threads it cannot be used for parallel color transformation because the method LCMSTransform.doTransform()  is synchronized.
> 
> This code seems to be created when the littlecms 1.x was used which was not thread-safe, but the latest version is thread safe (subject to bugs). I can check that by compiling lcms with #define CMS_NO_PTHREADS which will cause some of our tests fail here and there.
> 
> To check that transform can be used across the threads I created two quite heavyweight tests which tests different color transformations using different threads.
> 
> The fix moves the data for the native transform from the LCMSTransform object to the NativeTransform class just to simplify synchronization steps, so only one volatile read of "transform" is executed in the common path.
> 
> Result for the testcase attached to SO: https://stackoverflow.com/a/35264713
> |? threads|Before the fix|After the fix|
> |-------------|-------------|-------------|
> |1 |  693 ms | 699 ms|
> |8 | 6641 ms| 873 ms|
> |30 |34069 ms|1034 ms|

test/jdk/sun/java2d/cmm/ColorConvertOp/MTPerLineTransformValidation.java line 32:

> 30:  * @bug 8273972
> 31:  * @summary Verifies that ColorConvertOp works fine if shared between threads
> 32:  * @run main/othervm/timeout=600 MTTransformValidation

600 is quite pessimistic, on my system both tests are executed around 1 minute, but I am not sure how it will execute on the slow mac mini, so increased the timeout.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5671


From prr at openjdk.java.net  Fri Sep 24 20:53:58 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 24 Sep 2021 20:53:58 GMT
Subject: RFR: 8274296: Update or Problem List tests which may fail with
 uiScale=2 on macOS
In-Reply-To: <6n1wcxANYyG7C0Xd5kx0nPIndVYGX-EOxsctGDtDQsY=.7cc105d3-029e-40d7-8f20-303900f1517a@github.com>
References: <o77KLdyNbhOElBjnDjT8Q67oOXovFluJOQtIm8HIj0E=.388c84b8-3082-425c-9775-28a9560f8bce@github.com>
 <6n1wcxANYyG7C0Xd5kx0nPIndVYGX-EOxsctGDtDQsY=.7cc105d3-029e-40d7-8f20-303900f1517a@github.com>
Message-ID: <vNE2q5O773o35N9k05aQyRKfFxZxPj_2QtmchPct1EI=.e6908d53-d302-4327-bfe5-1bbe20a9e164@github.com>

On Fri, 24 Sep 2021 18:09:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> As described in https://bugs.openjdk.java.net/browse/JDK-8274106 a number of tests fail due to some inaccuracy in pixels copied from the screen when scaling down from device space to user space.
>> The subject of most of these tests is such that uiScale isn't important and we can have them pass with -Dsun.java2d.uiScale=1.
>> For the rest we can problem list them - as narrowly as we can on macos-aarch64 which is the only place we've seen the problem (not happening on retina displays with x64 it seems) whilst we try to figure out the root cause which is either in Apple code or something we are doing to trigger that Apple API misbehaviour.
>
> test/jdk/java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java line 29:
> 
>> 27:  * @summary [macosx] Order of overlapping of modal dialogs is wrong
>> 28:  * @key headful
>> 29:  * @run main/othervm -Dsun.java2d.uiScale=1 SiblingChildOrderTest
> 
> Switching this tests to scale=1 seems completely wrong. On macos it just tweak the rendering so that bug became invisible due to lost of precision. And now we will run the tests in lowDPI on all other platforms.

If really needed I can file a follow-on to change this test to problem listed on macOS like some of the others .. but this test doesn't look to me like its a pixel precision test ...

-------------

PR: https://git.openjdk.java.net/jdk/pull/5687


From github.com+90066231+alisenchung at openjdk.java.net  Fri Sep 24 22:10:32 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Fri, 24 Sep 2021 22:10:32 GMT
Subject: RFR: 8262945: [macos] Regression Manual Test for Key Events Fails
 [v2]
In-Reply-To: <LhSIteG6WssDHH2if3oeA-0qLZGhxfqb11JyTC4EPh8=.b8b62eb4-a50c-4eb2-98c7-6f122f87d08b@github.com>
References: <LhSIteG6WssDHH2if3oeA-0qLZGhxfqb11JyTC4EPh8=.b8b62eb4-a50c-4eb2-98c7-6f122f87d08b@github.com>
Message-ID: <SAB4_aF3WmfBy-_hTUluuE9R2GYRyjTMS2CHDtLKVaE=.a8c03712-1cd2-48d8-9ac8-164651de2ed4@github.com>

> 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.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  removed Russian language check

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5617/files
  - new: https://git.openjdk.java.net/jdk/pull/5617/files/043d1f05..05f376c6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5617&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5617&range=00-01

  Stats: 11 lines in 1 file changed: 0 ins; 9 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5617.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5617/head:pull/5617

PR: https://git.openjdk.java.net/jdk/pull/5617


From serb at openjdk.java.net  Sat Sep 25 05:24:59 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 25 Sep 2021 05:24:59 GMT
Subject: RFR: 8274016: Replace 'for' cycles with iterator with
 enhanced-for in java.desktop [v3]
In-Reply-To: <-QIK4YJVRpqbJ4Yiu4SqBHPaFK0yPlfR78ZkN0QZwgM=.a4cf88ac-0327-4431-8d2e-d857aa0e8b75@github.com>
References: <J_99QqIiSe6JHaUJP4vgaeN0GAA5Cebu0ycpQupFiJo=.bcb78736-629a-4ca8-8262-0fee90bbf06d@github.com>
 <-QIK4YJVRpqbJ4Yiu4SqBHPaFK0yPlfR78ZkN0QZwgM=.a4cf88ac-0327-4431-8d2e-d857aa0e8b75@github.com>
Message-ID: <Pi3JagXVxs0lsWo7RCQWAEbAzx7BLo45kfTYoZSri-0=.f8531e5b-533e-4211-8e7e-bf361d8b11f0@github.com>

On Thu, 23 Sep 2021 09:47:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> There are few places in code where manual `for` loop is used with Iterator to iterate over Collection.
>> Instead of manual `for` cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
>> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
>> This is continuation of [JDK-8258006](https://bugs.openjdk.java.net/browse/JDK-8258006)
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274016: Replace 'for' cycles with iterator with enhanced-for in java.desktop
>   drop useless comment
>   cleanup unused imports

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5578


From github.com+741251+turbanoff at openjdk.java.net  Sat Sep 25 10:42:28 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sat, 25 Sep 2021 10:42:28 GMT
Subject: RFR: 8274317: Unnecessary reentrant synchronized block in
 java.awt.Cursor
Message-ID: <x3I2kVaGeICu-xtH4JuiEyEUyFPBpirQJGUpFW0mSZ8=.0642ff8c-994f-4137-8526-c4ba447d0196@github.com>

No need to use 'synchronized(systemCustomCursors)' in 2 places. One is enough.

-------------

Commit messages:
 - [PATCH] Remove reentrant synchronized block in java.awt.Cursor.loadSystemCustomCursorProperties

Changes: https://git.openjdk.java.net/jdk/pull/5597/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5597&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274317
  Stats: 8 lines in 1 file changed: 3 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5597.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5597/head:pull/5597

PR: https://git.openjdk.java.net/jdk/pull/5597


From serb at openjdk.java.net  Sat Sep 25 10:42:29 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 25 Sep 2021 10:42:29 GMT
Subject: RFR: 8274317: Unnecessary reentrant synchronized block in
 java.awt.Cursor
In-Reply-To: <x3I2kVaGeICu-xtH4JuiEyEUyFPBpirQJGUpFW0mSZ8=.0642ff8c-994f-4137-8526-c4ba447d0196@github.com>
References: <x3I2kVaGeICu-xtH4JuiEyEUyFPBpirQJGUpFW0mSZ8=.0642ff8c-994f-4137-8526-c4ba447d0196@github.com>
Message-ID: <yeHoXsstkFWfzYYYLIGgvVjptIe1wxfAXFYIepV4cUY=.09ee0468-9731-4523-a452-bc90619c0235@github.com>

On Tue, 21 Sep 2021 07:17:43 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> No need to use 'synchronized(systemCustomCursors)' in 2 places. One is enough.

Marked as reviewed by serb (Reviewer).

Looks fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5597


From psadhukhan at openjdk.java.net  Sat Sep 25 10:50:54 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Sat, 25 Sep 2021 10:50:54 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out
 on macOS 12
In-Reply-To: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
References: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
Message-ID: <VXad01et4zwGYThbUUSYX-G9LROC8qxKDmygyObOK0Q=.8b65a10b-eab7-45db-aa16-168b0f4b9a21@github.com>

On Thu, 23 Sep 2021 06:47:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java is timing out every time on macOS 12 even though the test passed.
> Looks like the the main process waits for child process created in the test forever, making it timeout after jtreg timeout of 2min.
> Modified to wait for childprocess for 30secs.

The child process executing DisplayModeChanger class hangs when it is supposed to go into windowed mode in gd.setFullScreenWindow(null) call.
It seems in macos12, it hangs while executing CGCompleteDisplayConfiguration() in Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode method in CGraphicsDevice.m

Basically, setFullScreenWindow() calls CGGraphicsDevice.java#setFullScreenWindow which calls JNI nativeSetDisplayMode which does CGBeginDisplayConfiguration, CGConfigureDisplayWithDisplayMode and CGCompleteDisplayConfiguration.

Now, DisplayModeChanger class calls setFullScreenWindow to go to fullscreen mode and then to windowed mode. 
When going to fullscreen mode, it calls Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode()  with 
displayId:724860118, w:1280, h:720, bpp:32, refrate 60 and CGCompleteDisplayConfiguration works ok

But when it is called for windowed mode, Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode() is called with displayId:724860118, w:1920, h:1080, bpp:32, refrate 60 and CGCompleteDisplayConfiguration  hangs.

For macos11, also the same code flow is followed with same values but CGCompleteDisplayConfiguration  executes and the testcase works. 
For macos10.15.7 also, same codeflow is followed where fullscreen mode is called with 
displayId:731394562, w:640, h:480, bpp:32, refrate 60 and windowed mode with 
displayId:731394562, w:1920, h:1080, bpp:32, refrate 60 and it works.
So, it seems to be some macos12 quirk.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5647


From pbansal at openjdk.java.net  Sat Sep 25 19:15:53 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sat, 25 Sep 2021 19:15:53 GMT
Subject: RFR: 8274317: Unnecessary reentrant synchronized block in
 java.awt.Cursor
In-Reply-To: <x3I2kVaGeICu-xtH4JuiEyEUyFPBpirQJGUpFW0mSZ8=.0642ff8c-994f-4137-8526-c4ba447d0196@github.com>
References: <x3I2kVaGeICu-xtH4JuiEyEUyFPBpirQJGUpFW0mSZ8=.0642ff8c-994f-4137-8526-c4ba447d0196@github.com>
Message-ID: <3K8W5p8h4EBVwmI2I1vX5NhNesxJN6DPVpJD72MSoqI=.b6146ac2-43f0-4167-a88d-16627351c67c@github.com>

On Tue, 21 Sep 2021 07:17:43 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> No need to use 'synchronized(systemCustomCursors)' in 2 places. One is enough.

Looks good to me

-------------

Marked as reviewed by pbansal (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5597


From github.com+10835776+stsypanov at openjdk.java.net  Sat Sep 25 19:30:31 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sat, 25 Sep 2021 19:30:31 GMT
Subject: RFR: 8272756: Remove unnecessary explicit initialization of
 volatile variables in java.desktop [v3]
In-Reply-To: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
Message-ID: <HTEWllQGW95dAuz2LclbAaQ8DJrmzjUwJVSAem3GFh4=.e0f6cac2-07b0-43df-8d0a-c99b07434530@github.com>

> This is a continuation of
> 
> - https://bugs.openjdk.java.net/browse/JDK-6736490
> - https://bugs.openjdk.java.net/browse/JDK-8035284
> - https://bugs.openjdk.java.net/browse/JDK-8145680
> - https://bugs.openjdk.java.net/browse/JDK-8251548
> 
> As mentioned in JDK-6736490:
> 
> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._

?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into 8272756
 - 8272756: Remove unnecessary explicit initialization of volatile fields in java.desktop
 - 8272756: Remove unnecessary explicit initialization of volatile fields in java.desktop

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5197/files
  - new: https://git.openjdk.java.net/jdk/pull/5197/files/a3558d0a..d13ca900

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5197&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5197&range=01-02

  Stats: 53840 lines in 1699 files changed: 35340 ins; 9612 del; 8888 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5197.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5197/head:pull/5197

PR: https://git.openjdk.java.net/jdk/pull/5197


From serb at openjdk.java.net  Sat Sep 25 22:38:51 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 25 Sep 2021 22:38:51 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out
 on macOS 12
In-Reply-To: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
References: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
Message-ID: <kqiVaafBTeZTL_yW3e6wQN5TNzqkwoudMWcpGsBn-uI=.4a9ff8fd-333e-4640-8d26-8132d0cdb8ac@github.com>

On Thu, 23 Sep 2021 06:47:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java is timing out every time on macOS 12 even though the test passed.
> Looks like the the main process waits for child process created in the test forever, making it timeout after jtreg timeout of 2min.
> Modified to wait for childprocess for 30secs.

So this is not a test issue, I guess you should report this bug to Apple using some standalone native example.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5647


From prr at openjdk.java.net  Sat Sep 25 23:33:22 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 25 Sep 2021 23:33:22 GMT
Subject: RFR: 8262945: [macos] Regression Manual Test for Key Events Fails
 [v2]
In-Reply-To: <KRPbbQ7F_VIeZ04c-yeDaYRR2DRcKH3ZBOZX9FWhPjA=.90435ebb-83c5-4c06-ac64-45a4060e1987@github.com>
References: <LhSIteG6WssDHH2if3oeA-0qLZGhxfqb11JyTC4EPh8=.b8b62eb4-a50c-4eb2-98c7-6f122f87d08b@github.com>
 <bR0e6I30DQA0kaSi-xqH-yt8d1r3wfpH2DYAy3SzwOk=.cbc2bcd7-259b-4da6-9166-96a34091b213@github.com>
 <KRPbbQ7F_VIeZ04c-yeDaYRR2DRcKH3ZBOZX9FWhPjA=.90435ebb-83c5-4c06-ac64-45a4060e1987@github.com>
Message-ID: <NXegaYpX1Uj8bPSYymkDDDgLVyfmjyIq8aKlx4d0ZQM=.f4be5c34-1cd3-4c3e-89a1-44f62faa21c1@github.com>

On Wed, 22 Sep 2021 08:05:03 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m line 485:
>> 
>>> 483:         } else if([lang isEqualToString:@"ru"]) {
>>> 484:             // checking for Russian characters
>>> 485:             offset += 0x01000000;
>> 
>> where did this value come from ?
>> And I agree adding only russian looks odd. Actually I have no idea (and am curious) why the submitter was actually testing a russian layout keyboard.
>> Are we doing something weird, or does macOS really make developers have to understand every single supported language -> keyboard mapping ?
>> Is there a better (more generic) way ?
>> Is this the ONLY place we'd need to add understanding of Russian ? If there's more it would not be worth doing it just here.
>
>> where did this value come from ?
> 
> The 0x01000000 offset value is copied from share/classes/sun/awt/ExtendedKeyCodes.java. When using getExtendedKeyCodeForChar(int c), if the character isn't in the regularKeyCodesMap, that 0x01000000 offset is added and the new value is checked for again in the extendedKeyCodeSet. I noticed that Russian was in the extendedKeyCodeSet so I just checked for Russian active keyboard layout and added that offset since the case wasn't being handled before. 
> 
>> Are we doing something weird, or does macOS really make developers have to understand every single supported language -> keyboard mapping ?
> Is there a better (more generic) way ?
> 
> I can try to test whether removing the Russian language check also fixes other languages (since that's what we do in ExtendedKeyCodes.java anyway), but macOS might have a different system of keycodes so I can't tell for sure that it would work for all of them.
> 
>> Is this the ONLY place we'd need to add understanding of Russian ? If there's more it would not be worth doing it just here.
> 
> From my understanding anything that relies on keycodes would be fixed with this since AWTEvent.m was only checking for English to translate NSKeyCodes to Java virtual keycodes. I didn't see anywhere else related to keycodes we would need to have a language check .

This at least looks better. I guess you tried a few keyboard layout settings ?
Can you add a comment to the source where the 0x10000000 value comes from / what it means.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5617


From prr at openjdk.java.net  Sat Sep 25 23:38:12 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 25 Sep 2021 23:38:12 GMT
Subject: RFR: 8274317: Unnecessary reentrant synchronized block in
 java.awt.Cursor
In-Reply-To: <x3I2kVaGeICu-xtH4JuiEyEUyFPBpirQJGUpFW0mSZ8=.0642ff8c-994f-4137-8526-c4ba447d0196@github.com>
References: <x3I2kVaGeICu-xtH4JuiEyEUyFPBpirQJGUpFW0mSZ8=.0642ff8c-994f-4137-8526-c4ba447d0196@github.com>
Message-ID: <hwu5YhmWeQF9HknzhsloR6Tm2m7CmA3QzC4T8w7J7s0=.d5b34f99-b8c4-46d8-b42f-dd539916fdad@github.com>

On Tue, 21 Sep 2021 07:17:43 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> No need to use 'synchronized(systemCustomCursors)' in 2 places. One is enough.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5597


From prr at openjdk.java.net  Sat Sep 25 23:40:00 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 25 Sep 2021 23:40:00 GMT
Subject: RFR: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class [v7]
In-Reply-To: <5jBqYks3WA75ZwinZ5VAyAQ6EvKQHIZtMTO8UaSUs34=.42d55022-2106-4c2c-80da-90bb8fa88010@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
 <5jBqYks3WA75ZwinZ5VAyAQ6EvKQHIZtMTO8UaSUs34=.42d55022-2106-4c2c-80da-90bb8fa88010@github.com>
Message-ID: <Ic45D67vr_HMfFUTs4F2XYkBDTURaP3b6WTAz8q9skU=.57eed361-f701-42ab-b381-fc502813fa21@github.com>

On Tue, 21 Sep 2021 08:01:32 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add final keyword to PlatformFontInfo class

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5517


From prr at openjdk.java.net  Sat Sep 25 23:59:54 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 25 Sep 2021 23:59:54 GMT
Subject: RFR: 8273972: Multi-core choke point in CMM engine
 (LCMSTransform.doTransform)
In-Reply-To: <RhBRJTwa0ln5XW5QlVODQBWcWjD25PIeVq5n14b1P5A=.ab864a64-9368-43d1-8761-a8892acbc63f@github.com>
References: <RhBRJTwa0ln5XW5QlVODQBWcWjD25PIeVq5n14b1P5A=.ab864a64-9368-43d1-8761-a8892acbc63f@github.com>
Message-ID: <9GNGYKOMDhRRteMzVVDpKfNsMV97XfVyhZogT6MsA_k=.c005045f-a360-4371-be9f-26e0ad6261ac@github.com>

On Fri, 24 Sep 2021 04:38:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Initially, the bug was discussed here:
> https://stackoverflow.com/questions/35264582/why-is-multithreading-slowing-down/35264813
> 
> The root cause is that if for some reason directly or indirectly the color transform object is shared across the threads it cannot be used for parallel color transformation because the method LCMSTransform.doTransform()  is synchronized.
> 
> This code seems to be created when the littlecms 1.x was used which was not thread-safe, but the latest version is thread safe (subject to bugs). I can check that by compiling lcms with #define CMS_NO_PTHREADS which will cause some of our tests fail here and there.
> 
> To check that transform can be used across the threads I created two quite heavyweight tests which tests different color transformations using different threads.
> 
> The fix moves the data for the native transform from the LCMSTransform object to the NativeTransform class just to simplify synchronization steps, so only one volatile read of "transform" is executed in the common path.
> 
> Result for the testcase attached to SO: https://stackoverflow.com/a/35264713
> |? threads|Before the fix|After the fix|
> |-------------|-------------|-------------|
> |1 |  693 ms | 699 ms|
> |8 | 6641 ms| 873 ms|
> |30 |34069 ms|1034 ms|

This looks OK but I want to submit a test job to make sure no nasty surprises

-------------

PR: https://git.openjdk.java.net/jdk/pull/5671


From serb at openjdk.java.net  Sun Sep 26 21:00:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 26 Sep 2021 21:00:57 GMT
Subject: RFR: 8272756: Remove unnecessary explicit initialization of
 volatile variables in java.desktop [v3]
In-Reply-To: <xVBLj997Laf-N2IwD8dfI2bzfHvtV1P2ji63kXcc10g=.7127c961-2ddb-49e7-a565-4c3351303952@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com>
 <umwDn9Nke1Bnse87ZiQp9k_MyZDXpO45YUFtEXnFU80=.92a2b18b-f32d-4201-94ff-4c75b20e7bd8@github.com>
 <QeTE-KIuatog_Q5dU4BCp8u-U3HarxmHCSfw9uvyEd4=.0ea2627a-d2d5-4185-92cd-2069d9bb3f91@github.com>
 <aQwgzJ4B4oswyjPwlUna8_ccoFwQsnwtUz9TgUCxVmg=.7802c612-eb73-4b5d-b512-6fa6f829cebc@github.com>
 <xVBLj997Laf-N2IwD8dfI2bzfHvtV1P2ji63kXcc10g=.7127c961-2ddb-49e7-a565-4c3351303952@github.com>
Message-ID: <gnl7URRoEcqD7Dnb2-LkT6wucR7OH1eHY5ICtupHuoM=.56c7a040-fb9b-403e-ba3c-aeb83e847d4a@github.com>

On Mon, 23 Aug 2021 18:31:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I think we can drop it completely.
>
> Agree.

I still suggest to remove the local tag completely.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5197


From prr at openjdk.java.net  Sun Sep 26 21:06:02 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 26 Sep 2021 21:06:02 GMT
Subject: RFR: 8273972: Multi-core choke point in CMM engine
 (LCMSTransform.doTransform)
In-Reply-To: <RhBRJTwa0ln5XW5QlVODQBWcWjD25PIeVq5n14b1P5A=.ab864a64-9368-43d1-8761-a8892acbc63f@github.com>
References: <RhBRJTwa0ln5XW5QlVODQBWcWjD25PIeVq5n14b1P5A=.ab864a64-9368-43d1-8761-a8892acbc63f@github.com>
Message-ID: <D-UqkmKuryJu5xdzsdL5IfU8-m-sk9CzmBxG9YxqXAM=.7e8ae380-51e7-4bd8-92bc-a1ad796bf0f6@github.com>

On Fri, 24 Sep 2021 04:38:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Initially, the bug was discussed here:
> https://stackoverflow.com/questions/35264582/why-is-multithreading-slowing-down/35264813
> 
> The root cause is that if for some reason directly or indirectly the color transform object is shared across the threads it cannot be used for parallel color transformation because the method LCMSTransform.doTransform()  is synchronized.
> 
> This code seems to be created when the littlecms 1.x was used which was not thread-safe, but the latest version is thread safe (subject to bugs). I can check that by compiling lcms with #define CMS_NO_PTHREADS which will cause some of our tests fail here and there.
> 
> To check that transform can be used across the threads I created two quite heavyweight tests which tests different color transformations using different threads.
> 
> The fix moves the data for the native transform from the LCMSTransform object to the NativeTransform class just to simplify synchronization steps, so only one volatile read of "transform" is executed in the common path.
> 
> Result for the testcase attached to SO: https://stackoverflow.com/a/35264713
> |? threads|Before the fix|After the fix|
> |-------------|-------------|-------------|
> |1 |  693 ms | 699 ms|
> |8 | 6641 ms| 873 ms|
> |30 |34069 ms|1034 ms|

Testing was OK

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5671


From prr at openjdk.java.net  Mon Sep 27 02:08:18 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 27 Sep 2021 02:08:18 GMT
Subject: RFR: 8274326: [macos] Ensure initialisation of
 sun/lwawt/macosx/CAccessibility in JavaComponentAccessibility.m
Message-ID: <jDI9R1bvPAbBZX4CZwWV4TiyNo1jL7x2nBQNdxyRVTE=.c7028d01-69c0-4b6a-8ca5-52e25f088720@github.com>

A user with a very minimal swing test case has observed that it is possible with JDK 17 to get the exception
Exception in thread "AppKit Thread" java.lang.NoSuchMethodError: accessibilityHitTest
They have confirmed the fix here resolves that

-------------

Commit messages:
 - 8274326: [macos] Ensure initialisation of sun/lwawt/macosx/CAccessibility in JavaComponentAccessibility.m

Changes: https://git.openjdk.java.net/jdk/pull/5702/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5702&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274326
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5702.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5702/head:pull/5702

PR: https://git.openjdk.java.net/jdk/pull/5702


From serb at openjdk.java.net  Mon Sep 27 02:40:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 27 Sep 2021 02:40:08 GMT
Subject: RFR: 8274326: [macos] Ensure initialisation of
 sun/lwawt/macosx/CAccessibility in JavaComponentAccessibility.m
In-Reply-To: <jDI9R1bvPAbBZX4CZwWV4TiyNo1jL7x2nBQNdxyRVTE=.c7028d01-69c0-4b6a-8ca5-52e25f088720@github.com>
References: <jDI9R1bvPAbBZX4CZwWV4TiyNo1jL7x2nBQNdxyRVTE=.c7028d01-69c0-4b6a-8ca5-52e25f088720@github.com>
Message-ID: <9SXyWOQluLvubwk4fVPLWnrfb6ZggkUxucOw5VyhkHU=.03cb2bdb-be3f-4d03-9792-5d89e3cae261@github.com>

On Sun, 26 Sep 2021 04:08:06 GMT, Phil Race <prr at openjdk.org> wrote:

> A user with a very minimal swing test case has observed that it is possible with JDK 17 to get the exception
> Exception in thread "AppKit Thread" java.lang.NoSuchMethodError: accessibilityHitTest
> They have confirmed the fix here resolves that

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5702


From pbansal at openjdk.java.net  Mon Sep 27 04:57:05 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 27 Sep 2021 04:57:05 GMT
Subject: RFR: 8274326: [macos] Ensure initialisation of
 sun/lwawt/macosx/CAccessibility in JavaComponentAccessibility.m
In-Reply-To: <jDI9R1bvPAbBZX4CZwWV4TiyNo1jL7x2nBQNdxyRVTE=.c7028d01-69c0-4b6a-8ca5-52e25f088720@github.com>
References: <jDI9R1bvPAbBZX4CZwWV4TiyNo1jL7x2nBQNdxyRVTE=.c7028d01-69c0-4b6a-8ca5-52e25f088720@github.com>
Message-ID: <532WLVkCa2itE_6FB4oEeAabFNrK9Bz-pxsQDRsvAuo=.cc19016f-caa1-4f83-9f46-ec7235f3f408@github.com>

On Sun, 26 Sep 2021 04:08:06 GMT, Phil Race <prr at openjdk.org> wrote:

> A user with a very minimal swing test case has observed that it is possible with JDK 17 to get the exception
> Exception in thread "AppKit Thread" java.lang.NoSuchMethodError: accessibilityHitTest
> They have confirmed the fix here resolves that

Looks good to me

-------------

Marked as reviewed by pbansal (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5702


From darcy at openjdk.java.net  Mon Sep 27 09:29:09 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 27 Sep 2021 09:29:09 GMT
Subject: RFR: 8202056: Expand serial warning to check for bad overloads of
 serial-related methods and ineffectual fields
Message-ID: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>

This is an initial PR for expanded lint warnings done under two bugs:

8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type

to get feedback on the general approach and test strategy before further polishing the implementation.

The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.

Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.

Please also review the corresponding CSRs:

https://bugs.openjdk.java.net/browse/JDK-8274335
https://bugs.openjdk.java.net/browse/JDK-8274336

Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.

The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.

In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.

-------------

Commit messages:
 - Appease jcheck
 - Implement checks chegar recommended for interfaces.
 - Update comment.
 - Add tests for instance field checks.
 - Clean build with instance field checks in place.
 - Merge branch 'master' into JDK-8202056
 - Put Externalizable checks last.
 - Add checks for constructor access in Serializable classes.
 - Add no-arg ctor check for Externalizable classes.
 - Improve Externalization warnings.
 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5756385c...d498ff5f

Changes: https://git.openjdk.java.net/jdk/pull/5709/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8202056
  Stats: 1519 lines in 79 files changed: 1511 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709

PR: https://git.openjdk.java.net/jdk/pull/5709


From aivanov at openjdk.java.net  Mon Sep 27 10:32:03 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 27 Sep 2021 10:32:03 GMT
Subject: RFR: 8274326: [macos] Ensure initialisation of
 sun/lwawt/macosx/CAccessibility in JavaComponentAccessibility.m
In-Reply-To: <jDI9R1bvPAbBZX4CZwWV4TiyNo1jL7x2nBQNdxyRVTE=.c7028d01-69c0-4b6a-8ca5-52e25f088720@github.com>
References: <jDI9R1bvPAbBZX4CZwWV4TiyNo1jL7x2nBQNdxyRVTE=.c7028d01-69c0-4b6a-8ca5-52e25f088720@github.com>
Message-ID: <FfQmz49yLctWvehp-BsILfMwSn2CBBDX6rC2ya3YITc=.1398dec0-308a-4065-80f2-77af890150bb@github.com>

On Sun, 26 Sep 2021 04:08:06 GMT, Phil Race <prr at openjdk.org> wrote:

> A user with a very minimal swing test case has observed that it is possible with JDK 17 to get the exception
> Exception in thread "AppKit Thread" java.lang.NoSuchMethodError: accessibilityHitTest
> They have confirmed the fix here resolves that

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5702


From github.com+741251+turbanoff at openjdk.java.net  Mon Sep 27 12:11:06 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 27 Sep 2021 12:11:06 GMT
Subject: Integrated: 8274317: Unnecessary reentrant synchronized block in
 java.awt.Cursor
In-Reply-To: <x3I2kVaGeICu-xtH4JuiEyEUyFPBpirQJGUpFW0mSZ8=.0642ff8c-994f-4137-8526-c4ba447d0196@github.com>
References: <x3I2kVaGeICu-xtH4JuiEyEUyFPBpirQJGUpFW0mSZ8=.0642ff8c-994f-4137-8526-c4ba447d0196@github.com>
Message-ID: <AwdEAUuKDlO9IEmOSpJ3Iaey3LfSkD9-aUTmxsoWgqk=.1503a016-5c51-455f-8978-788111f47e62@github.com>

On Tue, 21 Sep 2021 07:17:43 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> No need to use 'synchronized(systemCustomCursors)' in 2 places. One is enough.

This pull request has now been integrated.

Changeset: 7436a77e
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Pankaj Bansal <pbansal at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7436a77e3d1232303264081cefb7166456601cac
Stats:     8 lines in 1 file changed: 3 ins; 3 del; 2 mod

8274317: Unnecessary reentrant synchronized block in java.awt.Cursor

Reviewed-by: serb, pbansal, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/5597


From erikj at openjdk.java.net  Mon Sep 27 13:01:58 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 27 Sep 2021 13:01:58 GMT
Subject: RFR: 8202056: Expand serial warning to check for bad overloads of
 serial-related methods and ineffectual fields
In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
Message-ID: <fleMwIh15sptLebA-p9240UO1uEZArpMzJ2LzaeAOms=.a8932c58-a9ea-45f4-a532-696aecdea5d3@github.com>

On Mon, 27 Sep 2021 01:00:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> This is an initial PR for expanded lint warnings done under two bugs:
> 
> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type
> 
> to get feedback on the general approach and test strategy before further polishing the implementation.
> 
> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.
> 
> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.
> 
> Please also review the corresponding CSRs:
> 
> https://bugs.openjdk.java.net/browse/JDK-8274335
> https://bugs.openjdk.java.net/browse/JDK-8274336
> 
> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.
> 
> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.
> 
> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.

Build change looks ok.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5709


From pbansal at openjdk.java.net  Mon Sep 27 13:34:44 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 27 Sep 2021 13:34:44 GMT
Subject: RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged()
 returns leftButton and rightButton as null with GTKLookAndFeel [v3]
In-Reply-To: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
Message-ID: <gn3LMUUrEY_c2nN80EtPV17dp4EngVkxIRghNQPmfkE=.37d5ff5e-2dd1-406c-995d-b40e3bb9c0bc@github.com>

> The function documentation for oneTouchExpandableChanged states that the function does couple of things, but in reality  it only does those things if the Look and Feel supports the supportsOneTouchButtons. In case the Look and Feel does not support supportsOneTouchButtons, this functions just returns in beginning and does not do anything.
> This change clarifies the above in function documentation.

Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:

  Changes according to JBS discussion

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5263/files
  - new: https://git.openjdk.java.net/jdk/pull/5263/files/f7b79a9d..d48ff5c8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5263&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5263&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5263.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5263/head:pull/5263

PR: https://git.openjdk.java.net/jdk/pull/5263


From github.com+90066231+alisenchung at openjdk.java.net  Mon Sep 27 16:19:21 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Mon, 27 Sep 2021 16:19:21 GMT
Subject: RFR: 8262945: [macos] Regression Manual Test for Key Events Fails
 [v3]
In-Reply-To: <LhSIteG6WssDHH2if3oeA-0qLZGhxfqb11JyTC4EPh8=.b8b62eb4-a50c-4eb2-98c7-6f122f87d08b@github.com>
References: <LhSIteG6WssDHH2if3oeA-0qLZGhxfqb11JyTC4EPh8=.b8b62eb4-a50c-4eb2-98c7-6f122f87d08b@github.com>
Message-ID: <k-0hmzZ-NTF8KavFyuo1m4RxJZjfB4b2INfWOwXX6JQ=.f34b98cd-5708-4a0e-96e0-0f6276fdc8eb@github.com>

> 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.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  adding comment explaining offset numbers

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5617/files
  - new: https://git.openjdk.java.net/jdk/pull/5617/files/05f376c6..9bb582a9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5617&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5617&range=01-02

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5617.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5617/head:pull/5617

PR: https://git.openjdk.java.net/jdk/pull/5617


From prr at openjdk.java.net  Mon Sep 27 16:43:51 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 27 Sep 2021 16:43:51 GMT
Subject: Integrated: 8274326: [macos] Ensure initialisation of
 sun/lwawt/macosx/CAccessibility in JavaComponentAccessibility.m
In-Reply-To: <jDI9R1bvPAbBZX4CZwWV4TiyNo1jL7x2nBQNdxyRVTE=.c7028d01-69c0-4b6a-8ca5-52e25f088720@github.com>
References: <jDI9R1bvPAbBZX4CZwWV4TiyNo1jL7x2nBQNdxyRVTE=.c7028d01-69c0-4b6a-8ca5-52e25f088720@github.com>
Message-ID: <fUW7eA8r7Ei-qWNMlkONGQen-47QxTOTt7ZkY8YJRyM=.0fca0ac9-c88e-481b-9c97-3528e4a3c121@github.com>

On Sun, 26 Sep 2021 04:08:06 GMT, Phil Race <prr at openjdk.org> wrote:

> A user with a very minimal swing test case has observed that it is possible with JDK 17 to get the exception
> Exception in thread "AppKit Thread" java.lang.NoSuchMethodError: accessibilityHitTest
> They have confirmed the fix here resolves that

This pull request has now been integrated.

Changeset: 2cffe4c8
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2cffe4c8e0b8e6d5843b7e9545e4b4408c56465c
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8274326: [macos] Ensure initialisation of sun/lwawt/macosx/CAccessibility in JavaComponentAccessibility.m

Reviewed-by: serb, pbansal, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/5702


From darcy at openjdk.java.net  Mon Sep 27 20:31:41 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 27 Sep 2021 20:31:41 GMT
Subject: RFR: 8274396: Suppress more warnings on non-serializable
 non-transient intance fields in client libs
Message-ID: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>

Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.

The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.

I'll run a script to update the copyright year before pushing.

-------------

Commit messages:
 - 8274396: Suppress more warnings on non-serializable non-transient instance fields in client libs

Changes: https://git.openjdk.java.net/jdk/pull/5723/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5723&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274396
  Stats: 7 lines in 5 files changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5723.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5723/head:pull/5723

PR: https://git.openjdk.java.net/jdk/pull/5723


From bpb at openjdk.java.net  Mon Sep 27 20:37:01 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 27 Sep 2021 20:37:01 GMT
Subject: RFR: 8274396: Suppress more warnings on non-serializable
 non-transient intance fields in client libs
In-Reply-To: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
Message-ID: <Wbq1SuRLPUarncHgqBbxu3VXLNu5JTz-PZBBSbD0wLs=.25f3d183-ce6e-435c-bd59-5b7b2159b135@github.com>

On Mon, 27 Sep 2021 20:21:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> I'll run a script to update the copyright year before pushing.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5723


From naoto at openjdk.java.net  Mon Sep 27 21:04:58 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 27 Sep 2021 21:04:58 GMT
Subject: RFR: 8274396: Suppress more warnings on non-serializable
 non-transient intance fields in client libs
In-Reply-To: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
Message-ID: <vcCCxNX__m_rdZfWPlPd_YxVDtDITOApWZKIkFazzyM=.48f9077a-c97d-4812-9431-af13d6666a08@github.com>

On Mon, 27 Sep 2021 20:21:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> I'll run a script to update the copyright year before pushing.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5723


From prr at openjdk.java.net  Mon Sep 27 21:20:47 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 27 Sep 2021 21:20:47 GMT
Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid> in
 launcher code
Message-ID: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>

macOS launcher code sets JAVA_MAIN_CLASS_<pid> which is read by AWT to set the name of the application in the system menu bar.

Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549

Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose,
we can set that instead of the env. var and avoid the threading issue.

This trades the JAVA_MAIN_CLASS_<pid> pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var.

-------------

Commit messages:
 - 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code
 - 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code

Changes: https://git.openjdk.java.net/jdk/pull/5724/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274397
  Stats: 75 lines in 2 files changed: 33 ins; 33 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5724.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5724/head:pull/5724

PR: https://git.openjdk.java.net/jdk/pull/5724


From serb at openjdk.java.net  Mon Sep 27 21:43:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 27 Sep 2021 21:43:01 GMT
Subject: RFR: 8274396: Suppress more warnings on non-serializable
 non-transient intance fields in client libs
In-Reply-To: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
Message-ID: <2wNXb0TGI4QE3XdISdz0GSPalFjGmiMeb5w9tuG6GKA=.20dd18b0-3eb9-4abe-a75d-ec73f52673cc@github.com>

On Mon, 27 Sep 2021 20:21:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> I'll run a script to update the copyright year before pushing.

Can we add comments to SuppressWarnings on why it was added? Previously we use this text
> // Not statically typed as Serializable

-------------

PR: https://git.openjdk.java.net/jdk/pull/5723


From darcy at openjdk.java.net  Mon Sep 27 22:48:24 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 27 Sep 2021 22:48:24 GMT
Subject: RFR: 8274396: Suppress more warnings on non-serializable
 non-transient intance fields in client libs [v2]
In-Reply-To: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
Message-ID: <TjAmogSCchLUCmS82lhXQIyjfY5mI1D-AbmjIuWiDLM=.6e56fa04-ccb3-4050-a296-c612e90ff7ff@github.com>

> Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> I'll run a script to update the copyright year before pushing.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Add comments requested in code review.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5723/files
  - new: https://git.openjdk.java.net/jdk/pull/5723/files/ab72612d..2977d859

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5723&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5723&range=00-01

  Stats: 7 lines in 5 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5723.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5723/head:pull/5723

PR: https://git.openjdk.java.net/jdk/pull/5723


From darcy at openjdk.java.net  Mon Sep 27 22:55:00 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 27 Sep 2021 22:55:00 GMT
Subject: RFR: 8274396: Suppress more warnings on non-serializable
 non-transient intance fields in client libs
In-Reply-To: <2wNXb0TGI4QE3XdISdz0GSPalFjGmiMeb5w9tuG6GKA=.20dd18b0-3eb9-4abe-a75d-ec73f52673cc@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
 <2wNXb0TGI4QE3XdISdz0GSPalFjGmiMeb5w9tuG6GKA=.20dd18b0-3eb9-4abe-a75d-ec73f52673cc@github.com>
Message-ID: <MyP2PU_B6BufARDaonSXrINBGn1kRsQoY1widUwx3ro=.fe3b0be5-01fd-41e4-8a63-2eb64602a089@github.com>

On Mon, 27 Sep 2021 21:40:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> 
> 
> Can we add comments to SuppressWarnings on why it was added? Previously we use this text
> 
> > // Not statically typed as Serializable

Added in revision; used a different comment wording.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5723


From prr at openjdk.java.net  Mon Sep 27 23:50:38 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 27 Sep 2021 23:50:38 GMT
Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid>
 in launcher code [v2]
In-Reply-To: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
Message-ID: <AMl7TgFd_mZOlyM0B--qaI38SiM4Krzh_CmbIYqnvgw=.951f9021-5643-4fd6-92fe-5275a644ff2a@github.com>

> macOS launcher code sets JAVA_MAIN_CLASS_<pid> which is read by AWT to set the name of the application in the system menu bar.
> 
> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
> 
> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose,
> we can set that instead of the env. var and avoid the threading issue.
> 
> This trades the JAVA_MAIN_CLASS_<pid> pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5724/files
  - new: https://git.openjdk.java.net/jdk/pull/5724/files/232bfae4..93108c59

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5724.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5724/head:pull/5724

PR: https://git.openjdk.java.net/jdk/pull/5724


From serb at openjdk.java.net  Tue Sep 28 01:24:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 28 Sep 2021 01:24:01 GMT
Subject: RFR: 8274396: Suppress more warnings on non-serializable
 non-transient intance fields in client libs [v2]
In-Reply-To: <TjAmogSCchLUCmS82lhXQIyjfY5mI1D-AbmjIuWiDLM=.6e56fa04-ccb3-4050-a296-c612e90ff7ff@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
 <TjAmogSCchLUCmS82lhXQIyjfY5mI1D-AbmjIuWiDLM=.6e56fa04-ccb3-4050-a296-c612e90ff7ff@github.com>
Message-ID: <jgBmqZjco39xUzmpvOeATPUAGMrw6PFAiwRuh6F4hqE=.79d6521b-11e1-47a4-a379-a6df089829df@github.com>

On Mon, 27 Sep 2021 22:48:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.
>> 
>> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
>> 
>> I'll run a script to update the copyright year before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments requested in code review.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5723


From myano at openjdk.java.net  Tue Sep 28 07:20:08 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Tue, 28 Sep 2021 07:20:08 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <YEhDJGgk1J8Ah3dE9amNf6NrOgU6iy6Z23bY9IWA8KM=.c36e6711-f2c1-447b-a9c8-4eb8d2e7516f@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <ACRHmQY8PTs2zOxEKTqpI3UP2P_OdWXHccoaHC3FrwM=.6bd5a2c9-b92e-4fbb-babe-005fa463a221@github.com>
 <G4VS1_zNJrOsdiajA3_BrSPWpxzSsRafaUs66mTXv4s=.9a7105b0-c946-4815-a118-00c9fd17cbe1@github.com>
 <YEhDJGgk1J8Ah3dE9amNf6NrOgU6iy6Z23bY9IWA8KM=.c36e6711-f2c1-447b-a9c8-4eb8d2e7516f@github.com>
Message-ID: <ZZfjrVx5ZQFBKjuIbhaaqGKs8GGDFSxAvfav3_gCAeY=.f7c112ec-757a-403f-b5b9-75908c232fb9@github.com>

On Fri, 24 Sep 2021 19:57:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> So the "sun.awt.noerasebackground" property may fix the problem? 

Yes. With `-Dsun.awt.noerasebackground=true`, original CopyAreaOOB.java is Passed. But it is just a workaround.

paint() is called twice with default settings on Windows, so my suggested fix is more realistic and reasonable than original code with `-Dsun.awt.noerasebackground=true`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5491


From github.com+36081106+savoptik at openjdk.java.net  Tue Sep 28 08:57:10 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 28 Sep 2021 08:57:10 GMT
Subject: RFR: 8274381 missing CAccessibility definitions in JNI code
Message-ID: <SojIsjOP6GZk4vBpIqfBN2DX9FjzosyntqF8Wb7quHg=.cca51fc6-c61d-4319-87b3-c2f7c083685c@github.com>

accessibilityHitTest in JavaComponentAccessibility and getAxComponentSize in JavaAccessibilityUtilities use but do not define sjc_CAccessibility. It works when sjc_CAccessibility is defined by other methods, otherwise it crashes.

-------------

Commit messages:
 - 8274381 missing CAccessibility definitions in JNI code

Changes: https://git.openjdk.java.net/jdk/pull/5732/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5732&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274381
  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5732.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5732/head:pull/5732

PR: https://git.openjdk.java.net/jdk/pull/5732


From github.com+36081106+savoptik at openjdk.java.net  Tue Sep 28 09:12:37 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 28 Sep 2021 09:12:37 GMT
Subject: RFR: 8274381 missing CAccessibility definitions in JNI code [v2]
In-Reply-To: <SojIsjOP6GZk4vBpIqfBN2DX9FjzosyntqF8Wb7quHg=.cca51fc6-c61d-4319-87b3-c2f7c083685c@github.com>
References: <SojIsjOP6GZk4vBpIqfBN2DX9FjzosyntqF8Wb7quHg=.cca51fc6-c61d-4319-87b3-c2f7c083685c@github.com>
Message-ID: <jeXczbDJWSPkXJ-xx2Y5_E1SgXsHhxCfVMBAijycl0k=.40f25444-37f2-4fe0-8295-44e099e5596b@github.com>

> accessibilityHitTest in JavaComponentAccessibility and getAxComponentSize in JavaAccessibilityUtilities use but do not define sjc_CAccessibility. It works when sjc_CAccessibility is defined by other methods, otherwise it crashes.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  8274381 missing CAccessibility definitions in JNI code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5732/files
  - new: https://git.openjdk.java.net/jdk/pull/5732/files/8af49145..afa62067

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5732&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5732&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5732.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5732/head:pull/5732

PR: https://git.openjdk.java.net/jdk/pull/5732


From pbansal at openjdk.java.net  Tue Sep 28 09:12:37 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 28 Sep 2021 09:12:37 GMT
Subject: RFR: 8274381 missing CAccessibility definitions in JNI code
In-Reply-To: <SojIsjOP6GZk4vBpIqfBN2DX9FjzosyntqF8Wb7quHg=.cca51fc6-c61d-4319-87b3-c2f7c083685c@github.com>
References: <SojIsjOP6GZk4vBpIqfBN2DX9FjzosyntqF8Wb7quHg=.cca51fc6-c61d-4319-87b3-c2f7c083685c@github.com>
Message-ID: <1EZL4AzPJnti85gasq_f0nE4F1lOdISr4KF95d0om6U=.003b4c09-d03f-4105-a815-f9ca93f26700@github.com>

On Tue, 28 Sep 2021 08:45:22 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> accessibilityHitTest in JavaComponentAccessibility and getAxComponentSize in JavaAccessibilityUtilities use but do not define sjc_CAccessibility. It works when sjc_CAccessibility is defined by other methods, otherwise it crashes.

Could you please look at https://github.com/openjdk/jdk/pull/5702. I see that Phil just fixed similar thing in JavaComponentAccessibility.m. Looks like we have same/similar function present in two classes doing exactly the same thing. Is it possible we can get rid of one of these two?

JavaComponentAccessibility.m has
- (id)accessibilityHitTest:(NSPoint)point withEnv:(JNIEnv *)env

CommonComponentAccessibility.m has
- (id)accessibilityHitTest:(NSPoint)point

-------------

PR: https://git.openjdk.java.net/jdk/pull/5732


From pbansal at openjdk.java.net  Tue Sep 28 09:18:52 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 28 Sep 2021 09:18:52 GMT
Subject: RFR: 8274381 missing CAccessibility definitions in JNI code [v2]
In-Reply-To: <jeXczbDJWSPkXJ-xx2Y5_E1SgXsHhxCfVMBAijycl0k=.40f25444-37f2-4fe0-8295-44e099e5596b@github.com>
References: <SojIsjOP6GZk4vBpIqfBN2DX9FjzosyntqF8Wb7quHg=.cca51fc6-c61d-4319-87b3-c2f7c083685c@github.com>
 <jeXczbDJWSPkXJ-xx2Y5_E1SgXsHhxCfVMBAijycl0k=.40f25444-37f2-4fe0-8295-44e099e5596b@github.com>
Message-ID: <I11ZGlv0c8ZlJ7l_LYouY_RdRZ6uqJ31jYXSa4q-ZB8=.eda502b2-f5f8-4ac7-a438-fb66ef1ab522@github.com>

On Tue, 28 Sep 2021 09:12:37 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> accessibilityHitTest in JavaComponentAccessibility and getAxComponentSize in JavaAccessibilityUtilities use but do not define sjc_CAccessibility. It works when sjc_CAccessibility is defined by other methods, otherwise it crashes.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274381 missing CAccessibility definitions in JNI code

looks fine to me

-------------

Marked as reviewed by pbansal (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5732


From github.com+36081106+savoptik at openjdk.java.net  Tue Sep 28 09:18:52 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 28 Sep 2021 09:18:52 GMT
Subject: RFR: 8274381 missing CAccessibility definitions in JNI code
In-Reply-To: <SojIsjOP6GZk4vBpIqfBN2DX9FjzosyntqF8Wb7quHg=.cca51fc6-c61d-4319-87b3-c2f7c083685c@github.com>
References: <SojIsjOP6GZk4vBpIqfBN2DX9FjzosyntqF8Wb7quHg=.cca51fc6-c61d-4319-87b3-c2f7c083685c@github.com>
Message-ID: <bFGUfoMJL70YtZyOL0FSOVBUSdfTVWnJbc7j2cXhJ-w=.96d0bcc4-539b-4aaf-b209-974919c05adc@github.com>

On Tue, 28 Sep 2021 08:45:22 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> accessibilityHitTest in JavaComponentAccessibility and getAxComponentSize in JavaAccessibilityUtilities use but do not define sjc_CAccessibility. It works when sjc_CAccessibility is defined by other methods, otherwise it crashes.

By agreement with Alexander Zuev, we do not touch JavaComponentAccessibility.
?????????? ? Mac



> 28 ????. 2021 ?., ? 12:07, Pankaj Bansal ***@***.***> ???????(?):
> 
> 
> Could you please look at #5702 <https://github.com/openjdk/jdk/pull/5702>. I see that Phil just fixed similar thing in JavaComponentAccessibility.m. Looks like we have same/similar function present in two classes doing exactly the same thing. Is it possible we can get rid of one of these two?
> 
> JavaComponentAccessibility.m has
> 
> (id)accessibilityHitTest:(NSPoint)point withEnv:(JNIEnv *)env
> CommonComponentAccessibility.m has
> 
> (id)accessibilityHitTest:(NSPoint)point
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <https://github.com/openjdk/jdk/pull/5732#issuecomment-929001621>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AITI3UVFBXR2JEGNGXOI2TDUEGAWBANCNFSM5E43LJZA>.
>

-------------

PR: https://git.openjdk.java.net/jdk/pull/5732


From alexsch at openjdk.java.net  Tue Sep 28 09:31:58 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Tue, 28 Sep 2021 09:31:58 GMT
Subject: Integrated: 8273581: Change the mechanism by which JDK loads the
 platform-specific FontManager class
In-Reply-To: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
References: <xauo0UGjdQPzFIGUo_e3iXbyqciEZq7Jh1Kjn6zyW6E=.bd282497-8ecd-4a43-b816-27ec730f1479@github.com>
Message-ID: <SZZh4xdrCihH0nLSb1LHDFb2rqJeVbHDwYacS1t4aeQ=.28ddd12b-5b92-42c9-8995-e7c1ffa75e66@github.com>

On Wed, 15 Sep 2021 05:52:54 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
> 
> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
> 
> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
> 
> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.

This pull request has now been integrated.

Changeset: 961dcffc
Author:    Alexander Scherbatiy <alexsch at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/961dcffc862a4830fbf26791835a98c12d4b513e
Stats:     238 lines in 6 files changed: 161 ins; 63 del; 14 mod

8273581: Change the mechanism by which JDK loads the platform-specific FontManager class

Reviewed-by: prr, psadhukhan, azvegint, aivanov, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5517


From github.com+36081106+savoptik at openjdk.java.net  Tue Sep 28 09:54:16 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 28 Sep 2021 09:54:16 GMT
Subject: RFR: 8274383 JNI call of getAccessibleSelection on a wrong thread
Message-ID: <T1ORlcjAAJz66P66eqb68Oo5pxmr70casobk6Z5vrFc=.6a26dfb0-9c30-4ce0-b5d5-ee77608d78a9@github.com>

[ComboBoxAccessibility accessibilityValue] defines the getAccessibleSelection method on the AccessibleContext class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

-------------

Commit messages:
 - 8274383 JNI call of getAccessibleSelection on a wrong thread

Changes: https://git.openjdk.java.net/jdk/pull/5735/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5735&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274383
  Stats: 16 lines in 1 file changed: 12 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5735.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5735/head:pull/5735

PR: https://git.openjdk.java.net/jdk/pull/5735


From ant at openjdk.java.net  Tue Sep 28 09:57:02 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Tue, 28 Sep 2021 09:57:02 GMT
Subject: RFR: 8274381 missing CAccessibility definitions in JNI code [v2]
In-Reply-To: <jeXczbDJWSPkXJ-xx2Y5_E1SgXsHhxCfVMBAijycl0k=.40f25444-37f2-4fe0-8295-44e099e5596b@github.com>
References: <SojIsjOP6GZk4vBpIqfBN2DX9FjzosyntqF8Wb7quHg=.cca51fc6-c61d-4319-87b3-c2f7c083685c@github.com>
 <jeXczbDJWSPkXJ-xx2Y5_E1SgXsHhxCfVMBAijycl0k=.40f25444-37f2-4fe0-8295-44e099e5596b@github.com>
Message-ID: <iZAsX1zW4XgfvirVs9xddN7s31N45Ft7SxXCx6JzWL0=.16d74b63-0fd0-47d4-9bd6-7773f2c94a9d@github.com>

On Tue, 28 Sep 2021 09:12:37 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> accessibilityHitTest in JavaComponentAccessibility and getAxComponentSize in JavaAccessibilityUtilities use but do not define sjc_CAccessibility. It works when sjc_CAccessibility is defined by other methods, otherwise it crashes.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274381 missing CAccessibility definitions in JNI code

Marked as reviewed by ant (Reviewer).

src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityUtilities.m line 54:

> 52: NSSize getAxComponentSize(JNIEnv *env, jobject axComponent, jobject component)
> 53: {
> 54:     GET_CACCESSIBILITY_CLASS_RETURN(nil);

Please, use `NSZeroSize` as the return value here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5732


From psadhukhan at openjdk.java.net  Tue Sep 28 10:02:52 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 28 Sep 2021 10:02:52 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out
 on macOS 12 [v2]
In-Reply-To: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
References: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
Message-ID: <m83G8HcxiSfHhmCCnxkQuqlg4LNke_u6f9e-hr9b0Fc=.469919a9-9e03-4bce-b584-b16751bfe0e0@github.com>

> java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java is timing out every time on macOS 12 even though the test passed.
> Looks like the the main process waits for child process created in the test forever, making it timeout after jtreg timeout of 2min.
> Modified to wait for childprocess for 30secs.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove thread blocking

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5647/files
  - new: https://git.openjdk.java.net/jdk/pull/5647/files/512ef797..cd32d096

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5647&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5647&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5647.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5647/head:pull/5647

PR: https://git.openjdk.java.net/jdk/pull/5647


From psadhukhan at openjdk.java.net  Tue Sep 28 10:02:52 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 28 Sep 2021 10:02:52 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out
 on macOS 12
In-Reply-To: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
References: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
Message-ID: <WsAI4DEg2_U4ut02FIDys08xOvqKWcwWvG8R9lpCsbY=.e17f04ff-6268-4823-a913-bf942117a7c8@github.com>

On Thu, 23 Sep 2021 06:47:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java is timing out every time on macOS 12 even though the test passed.
> Looks like the the main process waits for child process created in the test forever, making it timeout after jtreg timeout of 2min.
> Modified to wait for childprocess for 30secs.

Since CGCompleteDisplayConfiguration hangs if we ask the thread to wait, remove thread blocking allows the test to run on all CI macos version.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5647


From github.com+36081106+savoptik at openjdk.java.net  Tue Sep 28 10:10:58 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 28 Sep 2021 10:10:58 GMT
Subject: RFR: 8274381 missing CAccessibility definitions in JNI code [v2]
In-Reply-To: <iZAsX1zW4XgfvirVs9xddN7s31N45Ft7SxXCx6JzWL0=.16d74b63-0fd0-47d4-9bd6-7773f2c94a9d@github.com>
References: <SojIsjOP6GZk4vBpIqfBN2DX9FjzosyntqF8Wb7quHg=.cca51fc6-c61d-4319-87b3-c2f7c083685c@github.com>
 <jeXczbDJWSPkXJ-xx2Y5_E1SgXsHhxCfVMBAijycl0k=.40f25444-37f2-4fe0-8295-44e099e5596b@github.com>
 <iZAsX1zW4XgfvirVs9xddN7s31N45Ft7SxXCx6JzWL0=.16d74b63-0fd0-47d4-9bd6-7773f2c94a9d@github.com>
Message-ID: <0pHkcv__oSwluUE3zEq961HLD9I1_oYgzmEw63F9YEU=.6ef54452-5233-4f6e-b36b-fa75fe541cc4@github.com>

On Tue, 28 Sep 2021 09:09:09 GMT, Anton Tarasov <ant at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274381 missing CAccessibility definitions in JNI code
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityUtilities.m line 54:
> 
>> 52: NSSize getAxComponentSize(JNIEnv *env, jobject axComponent, jobject component)
>> 53: {
>> 54:     GET_CACCESSIBILITY_CLASS_RETURN(nil);
> 
> Please, use `NSZeroSize` as the return value here.

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/5732


From rriggs at openjdk.java.net  Tue Sep 28 14:27:47 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 28 Sep 2021 14:27:47 GMT
Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid>
 in launcher code [v2]
In-Reply-To: <AMl7TgFd_mZOlyM0B--qaI38SiM4Krzh_CmbIYqnvgw=.951f9021-5643-4fd6-92fe-5275a644ff2a@github.com>
References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
 <AMl7TgFd_mZOlyM0B--qaI38SiM4Krzh_CmbIYqnvgw=.951f9021-5643-4fd6-92fe-5275a644ff2a@github.com>
Message-ID: <0wQ3AZRHlfAHg6hZ7deEV7849Db3jxxUoK6NTZwIF9M=.abd0b563-50a5-4d53-99b9-d2bd7cd899cc@github.com>

On Mon, 27 Sep 2021 23:50:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> macOS launcher code sets JAVA_MAIN_CLASS_<pid> which is read by AWT to set the name of the application in the system menu bar.
>> 
>> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
>> 
>> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose,
>> we can set that instead of the env. var and avoid the threading issue.
>> 
>> This trades the JAVA_MAIN_CLASS_<pid> pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5724


From dnsimon at openjdk.java.net  Tue Sep 28 15:44:35 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Tue, 28 Sep 2021 15:44:35 GMT
Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid>
 in launcher code [v2]
In-Reply-To: <AMl7TgFd_mZOlyM0B--qaI38SiM4Krzh_CmbIYqnvgw=.951f9021-5643-4fd6-92fe-5275a644ff2a@github.com>
References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
 <AMl7TgFd_mZOlyM0B--qaI38SiM4Krzh_CmbIYqnvgw=.951f9021-5643-4fd6-92fe-5275a644ff2a@github.com>
Message-ID: <QFtZWAjof8raec4jG8tSVD8iR2xHNd3lwzZAkZ8wzMk=.a0eeb1f0-a31a-4d3b-a15e-89e6c605137e@github.com>

On Mon, 27 Sep 2021 23:50:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> macOS launcher code sets JAVA_MAIN_CLASS_<pid> which is read by AWT to set the name of the application in the system menu bar.
>> 
>> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
>> 
>> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose,
>> we can set that instead of the env. var and avoid the threading issue.
>> 
>> This trades the JAVA_MAIN_CLASS_<pid> pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code

src/java.base/macosx/native/libjli/java_md_macosx.m line 842:

> 840:      * of the app as it appears in the system menu bar.
> 841:      *
> 842:      * Not idea if how much external code ever sets it, but use it if set, else

"Not idea if" -> "No idea of"

-------------

PR: https://git.openjdk.java.net/jdk/pull/5724


From kizune at openjdk.java.net  Tue Sep 28 16:07:44 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 28 Sep 2021 16:07:44 GMT
Subject: RFR: 8274381 missing CAccessibility definitions in JNI code [v2]
In-Reply-To: <jeXczbDJWSPkXJ-xx2Y5_E1SgXsHhxCfVMBAijycl0k=.40f25444-37f2-4fe0-8295-44e099e5596b@github.com>
References: <SojIsjOP6GZk4vBpIqfBN2DX9FjzosyntqF8Wb7quHg=.cca51fc6-c61d-4319-87b3-c2f7c083685c@github.com>
 <jeXczbDJWSPkXJ-xx2Y5_E1SgXsHhxCfVMBAijycl0k=.40f25444-37f2-4fe0-8295-44e099e5596b@github.com>
Message-ID: <qG8wBj6HaPjnZLkG9QL6VWeLoo9a5vvMUZAGCVkIW2k=.481e1a1d-122c-40f4-b774-a9159aa8adb4@github.com>

On Tue, 28 Sep 2021 09:12:37 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> accessibilityHitTest in JavaComponentAccessibility and getAxComponentSize in JavaAccessibilityUtilities use but do not define sjc_CAccessibility. It works when sjc_CAccessibility is defined by other methods, otherwise it crashes.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274381 missing CAccessibility definitions in JNI code

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5732


From kizune at openjdk.java.net  Tue Sep 28 16:09:33 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 28 Sep 2021 16:09:33 GMT
Subject: RFR: 8274383 JNI call of getAccessibleSelection on a wrong thread
In-Reply-To: <T1ORlcjAAJz66P66eqb68Oo5pxmr70casobk6Z5vrFc=.6a26dfb0-9c30-4ce0-b5d5-ee77608d78a9@github.com>
References: <T1ORlcjAAJz66P66eqb68Oo5pxmr70casobk6Z5vrFc=.6a26dfb0-9c30-4ce0-b5d5-ee77608d78a9@github.com>
Message-ID: <E0OUcAPenWeOuLWeu12RvIk1CY4StOMFcZhYXu-zJfg=.5d4f87e4-6ea9-4e91-9712-ed41789416c9@github.com>

On Tue, 28 Sep 2021 09:47:02 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> [ComboBoxAccessibility accessibilityValue] defines the getAccessibleSelection method on the AccessibleContext class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5735


From github.com+36081106+savoptik at openjdk.java.net  Tue Sep 28 16:12:36 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 28 Sep 2021 16:12:36 GMT
Subject: Integrated: 8274381 missing CAccessibility definitions in JNI code
In-Reply-To: <SojIsjOP6GZk4vBpIqfBN2DX9FjzosyntqF8Wb7quHg=.cca51fc6-c61d-4319-87b3-c2f7c083685c@github.com>
References: <SojIsjOP6GZk4vBpIqfBN2DX9FjzosyntqF8Wb7quHg=.cca51fc6-c61d-4319-87b3-c2f7c083685c@github.com>
Message-ID: <LS2Xg0_dXlXkUkLNyVURYRl21IJgUwPTEBup2Qa1a5c=.d90cf9d2-a840-4c9c-acdc-bec3da356107@github.com>

On Tue, 28 Sep 2021 08:45:22 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> accessibilityHitTest in JavaComponentAccessibility and getAxComponentSize in JavaAccessibilityUtilities use but do not define sjc_CAccessibility. It works when sjc_CAccessibility is defined by other methods, otherwise it crashes.

This pull request has now been integrated.

Changeset: be403737
Author:    Artem Semenov <Artem.Semenov at jetbrains.com>
Committer: Anton Tarasov <ant at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/be4037374520917d5a0ed54eebb3d5d6d100d429
Stats:     2 lines in 2 files changed: 2 ins; 0 del; 0 mod

8274381: missing CAccessibility definitions in JNI code

Reviewed-by: pbansal, ant, kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/5732


From ant at openjdk.java.net  Tue Sep 28 16:23:31 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Tue, 28 Sep 2021 16:23:31 GMT
Subject: RFR: 8274383 JNI call of getAccessibleSelection on a wrong thread
In-Reply-To: <T1ORlcjAAJz66P66eqb68Oo5pxmr70casobk6Z5vrFc=.6a26dfb0-9c30-4ce0-b5d5-ee77608d78a9@github.com>
References: <T1ORlcjAAJz66P66eqb68Oo5pxmr70casobk6Z5vrFc=.6a26dfb0-9c30-4ce0-b5d5-ee77608d78a9@github.com>
Message-ID: <ISE_WmOZ2Thu1-QGcuSGlxbioPofHEqRPQ0ujmHaQkk=.241667b2-062c-4ff7-85d8-e1576cbf7e21@github.com>

On Tue, 28 Sep 2021 09:47:02 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> [ComboBoxAccessibility accessibilityValue] defines the getAccessibleSelection method on the AccessibleContext class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComboBoxAccessibility.m line 53:

> 51:     if (axContext == NULL) return nil;
> 52:     GET_ACCESSIBLESELECTION_METHOD_RETURN(nil);
> 53:     jobject axSelection = (*env)->CallStaticObjectMethod(env, sjc_CAccessibility, sjm_getAccessibleSelection, axContext, self->fComponent);

Please delete `axSelection` if you forgot.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5735


From github.com+36081106+savoptik at openjdk.java.net  Tue Sep 28 16:45:57 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 28 Sep 2021 16:45:57 GMT
Subject: RFR: 8274383 JNI call of getAccessibleSelection on a wrong thread
 [v2]
In-Reply-To: <T1ORlcjAAJz66P66eqb68Oo5pxmr70casobk6Z5vrFc=.6a26dfb0-9c30-4ce0-b5d5-ee77608d78a9@github.com>
References: <T1ORlcjAAJz66P66eqb68Oo5pxmr70casobk6Z5vrFc=.6a26dfb0-9c30-4ce0-b5d5-ee77608d78a9@github.com>
Message-ID: <6A6QhLHY18xbZWm5f2JVIC8gSgqIL39epG8iLT-dFO8=.18856dfa-9aa3-4583-9949-928745cad58d@github.com>

> [ComboBoxAccessibility accessibilityValue] defines the getAccessibleSelection method on the AccessibleContext class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8274383: JNI call of getAccessibleSelection on a wrong thread

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5735/files
  - new: https://git.openjdk.java.net/jdk/pull/5735/files/8adcb24f..bb514053

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5735&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5735&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5735.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5735/head:pull/5735

PR: https://git.openjdk.java.net/jdk/pull/5735


From ant at openjdk.java.net  Tue Sep 28 16:45:58 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Tue, 28 Sep 2021 16:45:58 GMT
Subject: RFR: 8274383 JNI call of getAccessibleSelection on a wrong thread
 [v2]
In-Reply-To: <6A6QhLHY18xbZWm5f2JVIC8gSgqIL39epG8iLT-dFO8=.18856dfa-9aa3-4583-9949-928745cad58d@github.com>
References: <T1ORlcjAAJz66P66eqb68Oo5pxmr70casobk6Z5vrFc=.6a26dfb0-9c30-4ce0-b5d5-ee77608d78a9@github.com>
 <6A6QhLHY18xbZWm5f2JVIC8gSgqIL39epG8iLT-dFO8=.18856dfa-9aa3-4583-9949-928745cad58d@github.com>
Message-ID: <QlF9OFpO4cvPgCRic3_fOK9VpUaWAbWnoicItuh93HA=.f65ae0ed-2ab2-4a4d-84ef-aa0a611b1883@github.com>

On Tue, 28 Sep 2021 16:42:24 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> [ComboBoxAccessibility accessibilityValue] defines the getAccessibleSelection method on the AccessibleContext class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8274383: JNI call of getAccessibleSelection on a wrong thread

Marked as reviewed by ant (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5735


From pbansal at openjdk.java.net  Tue Sep 28 16:46:02 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 28 Sep 2021 16:46:02 GMT
Subject: RFR: 8274383 JNI call of getAccessibleSelection on a wrong thread
 [v2]
In-Reply-To: <6A6QhLHY18xbZWm5f2JVIC8gSgqIL39epG8iLT-dFO8=.18856dfa-9aa3-4583-9949-928745cad58d@github.com>
References: <T1ORlcjAAJz66P66eqb68Oo5pxmr70casobk6Z5vrFc=.6a26dfb0-9c30-4ce0-b5d5-ee77608d78a9@github.com>
 <6A6QhLHY18xbZWm5f2JVIC8gSgqIL39epG8iLT-dFO8=.18856dfa-9aa3-4583-9949-928745cad58d@github.com>
Message-ID: <YWwnHlKCpm6fBtP62Lko75UwFG6h0Pds73Jf2B_OtCw=.e5d45d53-fcd1-4c94-a44f-a2e84eb0fdb1@github.com>

On Tue, 28 Sep 2021 16:42:24 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> [ComboBoxAccessibility accessibilityValue] defines the getAccessibleSelection method on the AccessibleContext class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8274383: JNI call of getAccessibleSelection on a wrong thread

Looks good to me

-------------

PR: https://git.openjdk.java.net/jdk/pull/5735


From github.com+36081106+savoptik at openjdk.java.net  Tue Sep 28 16:46:07 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 28 Sep 2021 16:46:07 GMT
Subject: RFR: 8274383 JNI call of getAccessibleSelection on a wrong thread
 [v2]
In-Reply-To: <ISE_WmOZ2Thu1-QGcuSGlxbioPofHEqRPQ0ujmHaQkk=.241667b2-062c-4ff7-85d8-e1576cbf7e21@github.com>
References: <T1ORlcjAAJz66P66eqb68Oo5pxmr70casobk6Z5vrFc=.6a26dfb0-9c30-4ce0-b5d5-ee77608d78a9@github.com>
 <ISE_WmOZ2Thu1-QGcuSGlxbioPofHEqRPQ0ujmHaQkk=.241667b2-062c-4ff7-85d8-e1576cbf7e21@github.com>
Message-ID: <osQMYWxpVywnXIuTQsneAgjoIMvst5yeGdyQhXWZZqw=.f0b204ca-fa5e-4ae6-b7c5-2ded73bdd5d9@github.com>

On Tue, 28 Sep 2021 11:22:58 GMT, Anton Tarasov <ant at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8274383: JNI call of getAccessibleSelection on a wrong thread
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComboBoxAccessibility.m line 53:
> 
>> 51:     if (axContext == NULL) return nil;
>> 52:     GET_ACCESSIBLESELECTION_METHOD_RETURN(nil);
>> 53:     jobject axSelection = (*env)->CallStaticObjectMethod(env, sjc_CAccessibility, sjm_getAccessibleSelection, axContext, self->fComponent);
> 
> Please delete `axSelection` if you forgot.

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/5735


From github.com+36081106+savoptik at openjdk.java.net  Tue Sep 28 16:46:08 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 28 Sep 2021 16:46:08 GMT
Subject: Integrated: 8274383 JNI call of getAccessibleSelection on a wrong
 thread
In-Reply-To: <T1ORlcjAAJz66P66eqb68Oo5pxmr70casobk6Z5vrFc=.6a26dfb0-9c30-4ce0-b5d5-ee77608d78a9@github.com>
References: <T1ORlcjAAJz66P66eqb68Oo5pxmr70casobk6Z5vrFc=.6a26dfb0-9c30-4ce0-b5d5-ee77608d78a9@github.com>
Message-ID: <oYOIu8LYcWFINQ1fkrCqq6RUcQsEAiYEftQ0QiIsQ-E=.fd999e95-0d7a-4324-8de5-028e2d45804b@github.com>

On Tue, 28 Sep 2021 09:47:02 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

> [ComboBoxAccessibility accessibilityValue] defines the getAccessibleSelection method on the AccessibleContext class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

This pull request has now been integrated.

Changeset: b36881fa
Author:    Artem Semenov <Artem.Semenov at jetbrains.com>
Committer: Anton Tarasov <ant at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b36881fa3b3f37400d4f2c0bca3192d88179f2ff
Stats:     17 lines in 1 file changed: 13 ins; 1 del; 3 mod

8274383: JNI call of getAccessibleSelection on a wrong thread

Reviewed-by: kizune, ant

-------------

PR: https://git.openjdk.java.net/jdk/pull/5735


From iris at openjdk.java.net  Tue Sep 28 16:49:39 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 28 Sep 2021 16:49:39 GMT
Subject: RFR: 8274396: Suppress more warnings on non-serializable
 non-transient intance fields in client libs [v2]
In-Reply-To: <TjAmogSCchLUCmS82lhXQIyjfY5mI1D-AbmjIuWiDLM=.6e56fa04-ccb3-4050-a296-c612e90ff7ff@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
 <TjAmogSCchLUCmS82lhXQIyjfY5mI1D-AbmjIuWiDLM=.6e56fa04-ccb3-4050-a296-c612e90ff7ff@github.com>
Message-ID: <ZzOlWQM5GpIOS60QEV8ThLdWVrZfsiB8You4ZhVC_TY=.3c992318-53ea-4b48-a1ec-e517bc2ea253@github.com>

On Mon, 27 Sep 2021 22:48:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.
>> 
>> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
>> 
>> I'll run a script to update the copyright year before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments requested in code review.

I like the comments indicating why the suppression is needed.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5723


From vdyakov at openjdk.java.net  Tue Sep 28 18:59:40 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Tue, 28 Sep 2021 18:59:40 GMT
Subject: RFR: 8262945: [macos] Regression Manual Test for Key Events Fails
 [v3]
In-Reply-To: <k-0hmzZ-NTF8KavFyuo1m4RxJZjfB4b2INfWOwXX6JQ=.f34b98cd-5708-4a0e-96e0-0f6276fdc8eb@github.com>
References: <LhSIteG6WssDHH2if3oeA-0qLZGhxfqb11JyTC4EPh8=.b8b62eb4-a50c-4eb2-98c7-6f122f87d08b@github.com>
 <k-0hmzZ-NTF8KavFyuo1m4RxJZjfB4b2INfWOwXX6JQ=.f34b98cd-5708-4a0e-96e0-0f6276fdc8eb@github.com>
Message-ID: <ArNUAN2mdlif6GjzYeJFzXcepWWvxgkNrNUGigECmZ0=.ac2b1693-7cc2-42cc-8f5f-ea06d1a357a0@github.com>

On Mon, 27 Sep 2021 16:19:21 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> 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.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding comment explaining offset numbers

@azuev-java @prrace  please review

-------------

PR: https://git.openjdk.java.net/jdk/pull/5617


From aivanov at openjdk.java.net  Tue Sep 28 19:20:08 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 28 Sep 2021 19:20:08 GMT
Subject: Integrated: 8239502: [TEST_BUG] Test
 javax/swing/text/FlowView/6318524/bug6318524.java never fails
In-Reply-To: <G6yZf1yEz84BFlJbn20yWxMZTseik7J1tJVlGYpZfXE=.1a2bb761-74f0-451a-9db9-f54e67867d2b@github.com>
References: <G6yZf1yEz84BFlJbn20yWxMZTseik7J1tJVlGYpZfXE=.1a2bb761-74f0-451a-9db9-f54e67867d2b@github.com>
Message-ID: <EOwcbeBio_Mmtv9LVVvBInDDHMxsikSnY80_DWXMGQI=.69e1247d-6846-4e6b-bd3d-a21061fc9ef4@github.com>

On Thu, 23 Sep 2021 18:41:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test is being moved from the closed to open. It's nearly a complete re-write of the original test.
> 
> I made the test headless by painting into image.
> 
> To detect failure, the test uses the position of the caret at the end of first line of the paragraph where the wrapping occurs.
> 
> I made sure that the updated test reproduces the original problem in [JDK-6318524](https://bugs.openjdk.java.net/browse/JDK-6318524). (There are some tweaks required to compile it with JDK 6.) The updated test fails when run with 6-b52. In fact, it also fails with 6-b53 up to 6-b76 where [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882) is fixed.
> 
> The behaviour in 6-b76 coincides with that in the latest JDK.
> 
> There are three parameters provided for debugging purposes:
> ? `-show`: Show frame for visual inspection
> ? `-save`: Save *the start image* after the first paragraph is justified, and *the last image* before it's checked that the first paragraph remains justified
> ? `-saveAll`: Save images for all the intermediate steps
> 
> [1] [JDK-6318524](https://bugs.openjdk.java.net/browse/JDK-6318524): Regression: views in paragraph are not children of Paragraph.Row is some cases
> [2] [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882): Last line of a paragraph should not be justified

This pull request has now been integrated.

Changeset: b7425b63
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b7425b63f6b69ba8709664377b4e037176ab6139
Stats:     194 lines in 1 file changed: 194 ins; 0 del; 0 mod

8239502: [TEST_BUG] Test javax/swing/text/FlowView/6318524/bug6318524.java never fails

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5660


From aivanov at openjdk.java.net  Tue Sep 28 19:20:48 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 28 Sep 2021 19:20:48 GMT
Subject: Integrated: 8273634: [TEST_BUG] Improve
 javax/swing/text/ParagraphView/6364882/bug6364882.java
In-Reply-To: <acWloNjzZyq31_HOlFJtQL-B7tVJE0PeAm-gXSUSa88=.79753fa2-d1b1-49b1-b972-d487be9011b4@github.com>
References: <acWloNjzZyq31_HOlFJtQL-B7tVJE0PeAm-gXSUSa88=.79753fa2-d1b1-49b1-b972-d487be9011b4@github.com>
Message-ID: <0aC9k0IduI-v8ZJIENFjyJ5-hc0MVthorq2cfa97Jks=.749bab47-cb6e-4a4a-a0ba-7577b10ce297@github.com>

On Thu, 23 Sep 2021 19:19:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test is being moved from the closed to open.
> 
> I updated the `bug6364882.java` test so that it's headless now. If it fails, the image of the `editorPane` is saved for analysis. I also added more asserts which verify:
> 
> ? the first three lines are aligned to the right edge;
> ? the fourth line isn't justified and its width is less than 3/4 of the width;
> ? the fifth and sixth lines have width less than that of the fourth line and have the same width.
> 
> There's an option to show the UI for visual inspection as well as to save the image even if the test passes; use `-show` and/or `-save` parameters to the test correspondingly.
> 
> [1] [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882): Last line of a paragraph should not be justified

This pull request has now been integrated.

Changeset: 67e52a30
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/67e52a3078b0e7e522297c6008f5ac3792937c6a
Stats:     239 lines in 1 file changed: 239 ins; 0 del; 0 mod

8273634: [TEST_BUG] Improve javax/swing/text/ParagraphView/6364882/bug6364882.java

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5661


From serb at openjdk.java.net  Tue Sep 28 21:42:47 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 28 Sep 2021 21:42:47 GMT
Subject: Integrated: 8273972: Multi-core choke point in CMM engine
 (LCMSTransform.doTransform)
In-Reply-To: <RhBRJTwa0ln5XW5QlVODQBWcWjD25PIeVq5n14b1P5A=.ab864a64-9368-43d1-8761-a8892acbc63f@github.com>
References: <RhBRJTwa0ln5XW5QlVODQBWcWjD25PIeVq5n14b1P5A=.ab864a64-9368-43d1-8761-a8892acbc63f@github.com>
Message-ID: <DRv8AAUT3gCpWYQ6snUvs2olX7c3zqFy5v2YE_hFDqI=.891ad9f7-5da2-4b0f-91df-6b0a06937a36@github.com>

On Fri, 24 Sep 2021 04:38:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Initially, the bug was discussed here:
> https://stackoverflow.com/questions/35264582/why-is-multithreading-slowing-down/35264813
> 
> The root cause is that if for some reason directly or indirectly the color transform object is shared across the threads it cannot be used for parallel color transformation because the method LCMSTransform.doTransform()  is synchronized.
> 
> This code seems to be created when the littlecms 1.x was used which was not thread-safe, but the latest version is thread safe (subject to bugs). I can check that by compiling lcms with #define CMS_NO_PTHREADS which will cause some of our tests fail here and there.
> 
> To check that transform can be used across the threads I created two quite heavyweight tests which tests different color transformations using different threads.
> 
> The fix moves the data for the native transform from the LCMSTransform object to the NativeTransform class just to simplify synchronization steps, so only one volatile read of "transform" is executed in the common path.
> 
> Result for the testcase attached to SO: https://stackoverflow.com/a/35264713
> |? threads|Before the fix|After the fix|
> |-------------|-------------|-------------|
> |1 |  693 ms | 699 ms|
> |8 | 6641 ms| 873 ms|
> |30 |34069 ms|1034 ms|

This pull request has now been integrated.

Changeset: e49e5b5a
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e49e5b5a7ed9e493380fb73100057898c707b31b
Stats:     358 lines in 5 files changed: 317 ins; 25 del; 16 mod

8273972: Multi-core choke point in CMM engine (LCMSTransform.doTransform)

Reviewed-by: prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/5671


From darcy at openjdk.java.net  Tue Sep 28 21:52:34 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 28 Sep 2021 21:52:34 GMT
Subject: Integrated: 8274396: Suppress more warnings on non-serializable
 non-transient instance fields in client libs
In-Reply-To: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
Message-ID: <37-3BkyxsYsQhemuIIOHxDakn_z4a-u_Kek_rZQ4Rao=.f168c9b5-e3cd-4c67-ad02-577cd629049f@github.com>

On Mon, 27 Sep 2021 20:21:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> I'll run a script to update the copyright year before pushing.

This pull request has now been integrated.

Changeset: d8a278f3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d8a278f3948e9a5c881e64cce0a588e31246a4b5
Stats:     7 lines in 5 files changed: 7 ins; 0 del; 0 mod

8274396: Suppress more warnings on non-serializable non-transient instance fields in client libs

Reviewed-by: bpb, naoto, serb, iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/5723


From serb at openjdk.java.net  Tue Sep 28 22:18:52 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 28 Sep 2021 22:18:52 GMT
Subject: RFR: 8264666: Reuse Math.multiplyExact/addExact in the
 LCMSImageLayout class
In-Reply-To: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
Message-ID: <XDYblVgZt2yMtwpOxVuBq9VC2gL-Yb7yaOlHJ_Yt0d0=.a14c3066-ad1b-4982-9577-a7a99ed8d06e@github.com>

On Fri, 2 Apr 2021 23:02:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions.
> - Cleanup: the usage of do/while(false) is removed

not now

-------------

PR: https://git.openjdk.java.net/jdk/pull/3333


From serb at openjdk.java.net  Tue Sep 28 22:52:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 28 Sep 2021 22:52:31 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out
 on macOS 12 [v2]
In-Reply-To: <m83G8HcxiSfHhmCCnxkQuqlg4LNke_u6f9e-hr9b0Fc=.469919a9-9e03-4bce-b584-b16751bfe0e0@github.com>
References: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
 <m83G8HcxiSfHhmCCnxkQuqlg4LNke_u6f9e-hr9b0Fc=.469919a9-9e03-4bce-b584-b16751bfe0e0@github.com>
Message-ID: <0jqPabwKEmglQrXxRBmVQWjPYJv_G4gk75lBunA4wvA=.5e5fae24-c35e-4146-88a8-0a2adcd855ec@github.com>

On Tue, 28 Sep 2021 10:02:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java is timing out every time on macOS 12 even though the test passed.
>> Looks like the the main process waits for child process created in the test forever, making it timeout after jtreg timeout of 2min.
>> Modified to wait for childprocess for 30secs.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove thread blocking

I am not sure that it is a good thing to add a workaround to the code just to pass the test. The appkit still will be locked and any call to it will hang as well.

You can achieve the same test result by commenting out the "gd.setFullScreenWindow(null)", no code no problems, but I do not think it is the right thing to do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5647


From github.com+741251+turbanoff at openjdk.java.net  Tue Sep 28 23:05:37 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 28 Sep 2021 23:05:37 GMT
Subject: Integrated: 8274016: Replace 'for' cycles with iterator with
 enhanced-for in java.desktop
In-Reply-To: <J_99QqIiSe6JHaUJP4vgaeN0GAA5Cebu0ycpQupFiJo=.bcb78736-629a-4ca8-8262-0fee90bbf06d@github.com>
References: <J_99QqIiSe6JHaUJP4vgaeN0GAA5Cebu0ycpQupFiJo=.bcb78736-629a-4ca8-8262-0fee90bbf06d@github.com>
Message-ID: <dNxmptcbFjWlsVD3Fk7SskjyLzXel_YFaRY5RfG0gg8=.0f7e4e43-1b95-45be-b9d0-ba803176404b@github.com>

On Sun, 19 Sep 2021 10:13:49 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are few places in code where manual `for` loop is used with Iterator to iterate over Collection.
> Instead of manual `for` cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle.
> This is continuation of [JDK-8258006](https://bugs.openjdk.java.net/browse/JDK-8258006)

This pull request has now been integrated.

Changeset: 1a29b1e9
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1a29b1e95e448bbef93373a25ba93a5591faed49
Stats:     102 lines in 13 files changed: 0 ins; 57 del; 45 mod

8274016: Replace 'for' cycles with iterator with enhanced-for in java.desktop

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5578


From jiefu at openjdk.java.net  Tue Sep 28 23:54:05 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 28 Sep 2021 23:54:05 GMT
Subject: RFR: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
Message-ID: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>

Hi all,

javax/swing/text/ParagraphView/6364882/bug6364882.java was observed failing on our non-GUI platforms.
So I guess it should be marked as headful.

Thanks.
Best regards,
Jie

-------------

Commit messages:
 - 8274465: Mark javax/swing/text/ParagraphView/6364882/bug6364882.java as headful

Changes: https://git.openjdk.java.net/jdk/pull/5744/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5744&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274465
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5744.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5744/head:pull/5744

PR: https://git.openjdk.java.net/jdk/pull/5744


From serb at openjdk.java.net  Wed Sep 29 00:45:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 29 Sep 2021 00:45:41 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <ZZfjrVx5ZQFBKjuIbhaaqGKs8GGDFSxAvfav3_gCAeY=.f7c112ec-757a-403f-b5b9-75908c232fb9@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <ACRHmQY8PTs2zOxEKTqpI3UP2P_OdWXHccoaHC3FrwM=.6bd5a2c9-b92e-4fbb-babe-005fa463a221@github.com>
 <G4VS1_zNJrOsdiajA3_BrSPWpxzSsRafaUs66mTXv4s=.9a7105b0-c946-4815-a118-00c9fd17cbe1@github.com>
 <YEhDJGgk1J8Ah3dE9amNf6NrOgU6iy6Z23bY9IWA8KM=.c36e6711-f2c1-447b-a9c8-4eb8d2e7516f@github.com>
 <ZZfjrVx5ZQFBKjuIbhaaqGKs8GGDFSxAvfav3_gCAeY=.f7c112ec-757a-403f-b5b9-75908c232fb9@github.com>
Message-ID: <POdns3iPgJRlh4vDuqFMSe5bl-AUKhd5lydHPLIpktI=.9aee1075-da2b-41c0-b4f3-35adca4c8091@github.com>

On Tue, 28 Sep 2021 07:15:44 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Yes. With `-Dsun.awt.noerasebackground=true`, original CopyAreaOOB.java is Passed. But it is just a workaround.

Yes, it is just a workaround that most probably will not work on other platforms. But EDT freeze for some time after copyarea will work.

> paint() is called twice with default settings on Windows, so my suggested fix is more realistic and reasonable than original code with `-Dsun.awt.noerasebackground=true`.

Do you know why we post it twice? It does not seem right, since we repaint all content in the apps like Netbeans/Idea and it is quite a heavyweight operation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5491


From serb at openjdk.java.net  Wed Sep 29 01:01:32 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 29 Sep 2021 01:01:32 GMT
Subject: RFR: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
In-Reply-To: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
References: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
Message-ID: <Qr4zkG4JQ6Q2xMrC2HmDhnCn0VJ-p-rgOpDqqQVuGGQ=.79511cf8-0277-4e79-90a0-873348ac4398@github.com>

On Tue, 28 Sep 2021 23:39:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> javax/swing/text/ParagraphView/6364882/bug6364882.java was observed failing on our non-GUI platforms.
> So I guess it should be marked as headful.
> 
> Thanks.
> Best regards,
> Jie

What exception is caused the test failure? This test was updated to be headless in the https://github.com/openjdk/jdk/pull/5661

-------------

PR: https://git.openjdk.java.net/jdk/pull/5744


From jiefu at openjdk.java.net  Wed Sep 29 01:14:45 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 29 Sep 2021 01:14:45 GMT
Subject: RFR: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
In-Reply-To: <Qr4zkG4JQ6Q2xMrC2HmDhnCn0VJ-p-rgOpDqqQVuGGQ=.79511cf8-0277-4e79-90a0-873348ac4398@github.com>
References: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
 <Qr4zkG4JQ6Q2xMrC2HmDhnCn0VJ-p-rgOpDqqQVuGGQ=.79511cf8-0277-4e79-90a0-873348ac4398@github.com>
Message-ID: <SAQkslmRNjxGG5zMkjwh4pr7DhnMEMedFRKiMF2ho4E=.16348015-58a4-45fb-832b-3f81a0006b4b@github.com>

On Wed, 29 Sep 2021 00:58:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> #5661

This test passed on our GUI platforms but failed without GUI.

STDERR:
java.lang.reflect.InvocationTargetException
        at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371)
        at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346)
        at java.desktop/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480)
        at bug6364882.main(bug6364882.java:83)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.AssertionError: paragraph doesn't have 6 rows of text
        at bug6364882.checkJustification(bug6364882.java:137)
        at bug6364882.lambda$main$0(bug6364882.java:87)
        at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:308)
        at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
        at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
        at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
        at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
        at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
        at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5744


From serb at openjdk.java.net  Wed Sep 29 01:24:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 29 Sep 2021 01:24:36 GMT
Subject: RFR: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
In-Reply-To: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
References: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
Message-ID: <DH2kZTA92hzg5ivyt22C0qAYOW7NtZqlGPCucexjI_o=.3fbb18a6-1603-4117-ab03-c3cacd2a51e5@github.com>

On Tue, 28 Sep 2021 23:39:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> javax/swing/text/ParagraphView/6364882/bug6364882.java was observed failing on our non-GUI platforms.
> So I guess it should be marked as headful.
> 
> Thanks.
> Best regards,
> Jie

This is a plain test failure, since exception is not a HeadlessException caused by some API required the desktop session.
headful key should not apply to it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5744


From jiefu at openjdk.java.net  Wed Sep 29 01:24:36 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 29 Sep 2021 01:24:36 GMT
Subject: RFR: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
In-Reply-To: <DH2kZTA92hzg5ivyt22C0qAYOW7NtZqlGPCucexjI_o=.3fbb18a6-1603-4117-ab03-c3cacd2a51e5@github.com>
References: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
 <DH2kZTA92hzg5ivyt22C0qAYOW7NtZqlGPCucexjI_o=.3fbb18a6-1603-4117-ab03-c3cacd2a51e5@github.com>
Message-ID: <PrM54OsQqeXGJxGSocE3ZtZ-mudy-iez7J4LuM-zook=.c9423e0d-fbd5-4eb9-850d-b6f5cff3e1c2@github.com>

On Wed, 29 Sep 2021 01:19:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is a plain test failure, since exception is not a HeadlessException caused by some API required the desktop session. headful key should not apply to it.

So any idea to fix it?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5744


From serb at openjdk.java.net  Wed Sep 29 01:36:29 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 29 Sep 2021 01:36:29 GMT
Subject: RFR: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
In-Reply-To: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
References: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
Message-ID: <f4VQLXrX69Y2aq7OpArI0Pid7nOKP0t8H8TD6egwzck=.907cbda4-5f7c-45de-9592-e929bddf640a@github.com>

On Tue, 28 Sep 2021 23:39:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> javax/swing/text/ParagraphView/6364882/bug6364882.java was observed failing on our non-GUI platforms.
> So I guess it should be marked as headful.
> 
> Thanks.
> Best regards,
> Jie

It is possible that the test is too strict or this is a jdk bug. But I am not sure it is possible to investigate this issue based on the bug description in the JBS.
@aivanov-jdk please take a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5744


From jiefu at openjdk.java.net  Wed Sep 29 01:43:33 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 29 Sep 2021 01:43:33 GMT
Subject: RFR: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
In-Reply-To: <f4VQLXrX69Y2aq7OpArI0Pid7nOKP0t8H8TD6egwzck=.907cbda4-5f7c-45de-9592-e929bddf640a@github.com>
References: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
 <f4VQLXrX69Y2aq7OpArI0Pid7nOKP0t8H8TD6egwzck=.907cbda4-5f7c-45de-9592-e929bddf640a@github.com>
Message-ID: <zCEWuiPFEQjCPyMOTwbml_Vrizt_rru2Dxbz2Tvo1-w=.2854d3e0-d4cb-4fe5-b537-0f06a60d9061@github.com>

On Wed, 29 Sep 2021 01:33:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> It is possible that the test is too strict or this is a jdk bug. But I am not sure it is possible to investigate this issue based on the bug description in the JBS. @aivanov-jdk please take a look.

Can I problemlist this test?
Then we'll have enough time to investigate the root cause.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5744


From serb at openjdk.java.net  Wed Sep 29 01:49:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 29 Sep 2021 01:49:37 GMT
Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid>
 in launcher code [v2]
In-Reply-To: <AMl7TgFd_mZOlyM0B--qaI38SiM4Krzh_CmbIYqnvgw=.951f9021-5643-4fd6-92fe-5275a644ff2a@github.com>
References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
 <AMl7TgFd_mZOlyM0B--qaI38SiM4Krzh_CmbIYqnvgw=.951f9021-5643-4fd6-92fe-5275a644ff2a@github.com>
Message-ID: <Ggym6OKr8ljiLYk3SraghfnmJWRAPVjKno7KwdVlG6o=.a4d6a034-e861-416a-ac4f-5f8c51c26416@github.com>

On Mon, 27 Sep 2021 23:50:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> macOS launcher code sets JAVA_MAIN_CLASS_<pid> which is read by AWT to set the name of the application in the system menu bar.
>> 
>> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
>> 
>> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose,
>> we can set that instead of the env. var and avoid the threading issue.
>> 
>> This trades the JAVA_MAIN_CLASS_<pid> pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code

src/java.base/macosx/native/libjli/java_md_macosx.m line 879:

> 877:     }
> 878: 
> 879:     (*env)->DeleteLocalRef(env, jKey);

I am not sure about error handling, the jkey is not removed when NULL_CHECK is used. Also an exceptions are not cleared in case of NULL_CHECK like in other cases, is it intentional?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5724


From prr at openjdk.java.net  Wed Sep 29 03:12:39 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 29 Sep 2021 03:12:39 GMT
Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid>
 in launcher code [v2]
In-Reply-To: <Ggym6OKr8ljiLYk3SraghfnmJWRAPVjKno7KwdVlG6o=.a4d6a034-e861-416a-ac4f-5f8c51c26416@github.com>
References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
 <AMl7TgFd_mZOlyM0B--qaI38SiM4Krzh_CmbIYqnvgw=.951f9021-5643-4fd6-92fe-5275a644ff2a@github.com>
 <Ggym6OKr8ljiLYk3SraghfnmJWRAPVjKno7KwdVlG6o=.a4d6a034-e861-416a-ac4f-5f8c51c26416@github.com>
Message-ID: <mqJ0TAhH4R35mzn_STJy1cXbgdncFu3Sw1OMGkFU4Ac=.a9c7bc0d-cab2-4ef1-b159-483988dabe21@github.com>

On Wed, 29 Sep 2021 01:46:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code
>
> src/java.base/macosx/native/libjli/java_md_macosx.m line 879:
> 
>> 877:     }
>> 878: 
>> 879:     (*env)->DeleteLocalRef(env, jKey);
> 
> I am not sure about error handling, the jkey is not removed when NULL_CHECK is used. Also an exceptions are not cleared in case of NULL_CHECK like in other cases, is it intentional?

Well .. they aren't removed by the existing code either. And this is the launcher.
So far as I can tell if we error out of here (as I found when I made a typo in a method signature) the
VM exits very rapidly. So if I do anything here, it would be to remove DeleteLocalRef since it really doesn't matter to clean up local refs when you are either bailing from native .. or the entire process .. cleaning up when you are continuing on (as the code does) is perhaps more important since you might need more local refs before you are done.
Or file a separate bug against the launcher and JNI clean up after error handling.
java.base/share/native/libjli/java.c is a good example of where the same pattern exists.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5724


From prr at openjdk.java.net  Wed Sep 29 03:35:34 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 29 Sep 2021 03:35:34 GMT
Subject: RFR: 8273634: [TEST_BUG] Improve
 javax/swing/text/ParagraphView/6364882/bug6364882.java
In-Reply-To: <acWloNjzZyq31_HOlFJtQL-B7tVJE0PeAm-gXSUSa88=.79753fa2-d1b1-49b1-b972-d487be9011b4@github.com>
References: <acWloNjzZyq31_HOlFJtQL-B7tVJE0PeAm-gXSUSa88=.79753fa2-d1b1-49b1-b972-d487be9011b4@github.com>
Message-ID: <QWB7fI6EPHBqGch-rq7DsfiseQWcjXuiwV3hDvRtrfE=.753598f6-6755-48e5-802b-7dc91e12b978@github.com>

On Thu, 23 Sep 2021 19:19:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test is being moved from the closed to open.
> 
> I updated the `bug6364882.java` test so that it's headless now. If it fails, the image of the `editorPane` is saved for analysis. I also added more asserts which verify:
> 
> ? the first three lines are aligned to the right edge;
> ? the fourth line isn't justified and its width is less than 3/4 of the width;
> ? the fifth and sixth lines have width less than that of the fourth line and have the same width.
> 
> There's an option to show the UI for visual inspection as well as to save the image even if the test passes; use `-show` and/or `-save` parameters to the test correspondingly.
> 
> [1] [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882): Last line of a paragraph should not be justified

This test looks headless.
It uses frame only if an arg is passed clearly for manual debugging and the test config doesn't use it.
"Our GUI platforms" being what ?
And the information being pasted in here should be in the bug report.
Even then there's nothing to help someone figure out why it passed for others and not you.
What font was in use ? Why do you think headful made a difference ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5661


From prr at openjdk.java.net  Wed Sep 29 03:39:09 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 29 Sep 2021 03:39:09 GMT
Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid>
 in launcher code [v3]
In-Reply-To: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
Message-ID: <rWjRxqEvSuEXDQJX6DLXGebarexgC9IO3Lq3fUxKeVY=.f3e4e040-a269-4300-a85c-d48bd2cb7f56@github.com>

> macOS launcher code sets JAVA_MAIN_CLASS_<pid> which is read by AWT to set the name of the application in the system menu bar.
> 
> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
> 
> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose,
> we can set that instead of the env. var and avoid the threading issue.
> 
> This trades the JAVA_MAIN_CLASS_<pid> pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8274397: Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5724/files
  - new: https://git.openjdk.java.net/jdk/pull/5724/files/93108c59..96a5590c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=01-02

  Stats: 24 lines in 1 file changed: 23 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5724.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5724/head:pull/5724

PR: https://git.openjdk.java.net/jdk/pull/5724


From prr at openjdk.java.net  Wed Sep 29 03:41:40 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 29 Sep 2021 03:41:40 GMT
Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid>
 in launcher code [v2]
In-Reply-To: <AMl7TgFd_mZOlyM0B--qaI38SiM4Krzh_CmbIYqnvgw=.951f9021-5643-4fd6-92fe-5275a644ff2a@github.com>
References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
 <AMl7TgFd_mZOlyM0B--qaI38SiM4Krzh_CmbIYqnvgw=.951f9021-5643-4fd6-92fe-5275a644ff2a@github.com>
Message-ID: <dGcEMGzhrUs1tErvlW28oXsshZqaZpLTVlNAWLxs8p4=.808174cf-da3b-479e-b1ed-cd4eec757cf1@github.com>

On Mon, 27 Sep 2021 23:50:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> macOS launcher code sets JAVA_MAIN_CLASS_<pid> which is read by AWT to set the name of the application in the system menu bar.
>> 
>> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
>> 
>> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose,
>> we can set that instead of the env. var and avoid the threading issue.
>> 
>> This trades the JAVA_MAIN_CLASS_<pid> pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code

I've added code in the launcher part that strips the package name from what is seen.
This was previously done in the AWT code for MAIN_CLASS_<pid> since it was presumably the only code setting that but I didn't do it because before because I didn't want to interfere with what an app might have set as the system property .. but .. if the app didn't set it and we derived it, then I realised we probably should be consistent with what happened before and only the launcher code knows whether it was set by itself or the app

-------------

PR: https://git.openjdk.java.net/jdk/pull/5724


From prr at openjdk.java.net  Wed Sep 29 03:50:32 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 29 Sep 2021 03:50:32 GMT
Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid>
 in launcher code [v3]
In-Reply-To: <rWjRxqEvSuEXDQJX6DLXGebarexgC9IO3Lq3fUxKeVY=.f3e4e040-a269-4300-a85c-d48bd2cb7f56@github.com>
References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
 <rWjRxqEvSuEXDQJX6DLXGebarexgC9IO3Lq3fUxKeVY=.f3e4e040-a269-4300-a85c-d48bd2cb7f56@github.com>
Message-ID: <CwYnLdq61-xkNGg4XZG7V6vnOEOIHtIhYmMoqhjylNE=.f7c0c9dc-936f-45f3-b41c-7fd9307746ac@github.com>

On Wed, 29 Sep 2021 03:39:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> macOS launcher code sets JAVA_MAIN_CLASS_<pid> which is read by AWT to set the name of the application in the system menu bar.
>> 
>> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
>> 
>> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose,
>> we can set that instead of the env. var and avoid the threading issue.
>> 
>> This trades the JAVA_MAIN_CLASS_<pid> pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274397: Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code

And, oh, the env. var test code I needed to delete was checking not for a useful value but just that the env var was there.
I wrote a simple jtreg test or the new code that set the system property and tested the expected value (default or set)
but it seems jtreg makes MainWrapper the main class that is found regardless of main/othervm so I am currently grumbling quietly to myself about whether to add a test which is equivalent to the previous one which just tests the property has a value, 
or to (I suppose) write a more sophisticated test that has to exec another VM where it *should* be able to properly verify it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5724


From psadhukhan at openjdk.java.net  Wed Sep 29 04:16:35 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 29 Sep 2021 04:16:35 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out
 on macOS 12 [v2]
In-Reply-To: <m83G8HcxiSfHhmCCnxkQuqlg4LNke_u6f9e-hr9b0Fc=.469919a9-9e03-4bce-b584-b16751bfe0e0@github.com>
References: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
 <m83G8HcxiSfHhmCCnxkQuqlg4LNke_u6f9e-hr9b0Fc=.469919a9-9e03-4bce-b584-b16751bfe0e0@github.com>
Message-ID: <wYNqShxAuLP97J8xOr-yiKaXolCiQjjWr3jbEQZ2uiI=.6d739fe1-1cda-43b7-8f29-10679acb8883@github.com>

On Tue, 28 Sep 2021 10:02:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java is timing out every time on macOS 12 even though the test passed.
>> Looks like the the main process waits for child process created in the test forever, making it timeout after jtreg timeout of 2min.
>> Modified to wait for childprocess for 30secs.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove thread blocking

Why it is considered a workaround? There are many instances where we use [ThreadUtilities performOnMainThreadWaiting:NO block:^() 
and it seems CGCompleteDisplayConfiguration might have a tendancy to take time 
https://github.com/jakehilborn/displayplacer/pull/72/files
https://github.com/jakehilborn/displayplacer/issues/28
so it might be good to place the call not in blocking thread

-------------

PR: https://git.openjdk.java.net/jdk/pull/5647


From serb at openjdk.java.net  Wed Sep 29 08:09:34 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 29 Sep 2021 08:09:34 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out
 on macOS 12 [v2]
In-Reply-To: <wYNqShxAuLP97J8xOr-yiKaXolCiQjjWr3jbEQZ2uiI=.6d739fe1-1cda-43b7-8f29-10679acb8883@github.com>
References: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
 <m83G8HcxiSfHhmCCnxkQuqlg4LNke_u6f9e-hr9b0Fc=.469919a9-9e03-4bce-b584-b16751bfe0e0@github.com>
 <wYNqShxAuLP97J8xOr-yiKaXolCiQjjWr3jbEQZ2uiI=.6d739fe1-1cda-43b7-8f29-10679acb8883@github.com>
Message-ID: <FxsXXB_Kffa9O5lAF9bHzL3SooAFJhgYYBn2f4bYVOA=.76a8a465-912f-4176-9254-cfcc39a85e65@github.com>

On Wed, 29 Sep 2021 04:13:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Why it is considered a workaround? There are many instances where we use [ThreadUtilities performOnMainThreadWaiting:NO block:^()

It is a workaround because it does not fix the hang, but just skips part of the functionality. Since appkit hangs any UI operations will be blocked, and the app become broken

-------------

PR: https://git.openjdk.java.net/jdk/pull/5647


From github.com+741251+turbanoff at openjdk.java.net  Wed Sep 29 08:39:09 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 29 Sep 2021 08:39:09 GMT
Subject: RFR: 8274496: Use String.contains() instead of String.indexOf() in
 java.desktop
Message-ID: <xfGt9s0_ZLvwVgCEAj8sF4tCvQqNztpHBMlih_9CtS8=.b3b0ed70-d010-4153-814b-1af900f53ee1@github.com>

String.contains was introduced in Java 5.
Some code in java.desktop still uses old approach with String.indexOf to check if String contains specified substring.
I propose to migrate such usages. Makes code shorter and easier to read.

-------------

Commit messages:
 - [PATCH] Use String.contains() instead of String.indexOf() in java.desktop

Changes: https://git.openjdk.java.net/jdk/pull/5565/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5565&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274496
  Stats: 59 lines in 10 files changed: 0 ins; 6 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5565.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5565/head:pull/5565

PR: https://git.openjdk.java.net/jdk/pull/5565


From serb at openjdk.java.net  Wed Sep 29 08:39:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 29 Sep 2021 08:39:09 GMT
Subject: RFR: 8274496: Use String.contains() instead of String.indexOf()
 in java.desktop
In-Reply-To: <xfGt9s0_ZLvwVgCEAj8sF4tCvQqNztpHBMlih_9CtS8=.b3b0ed70-d010-4153-814b-1af900f53ee1@github.com>
References: <xfGt9s0_ZLvwVgCEAj8sF4tCvQqNztpHBMlih_9CtS8=.b3b0ed70-d010-4153-814b-1af900f53ee1@github.com>
Message-ID: <2rQ3pzaQg4QcaLU--w4uZz7Xy9avRAywDTjhqHTveSw=.58e710b5-cf68-4aa6-a6b4-facaa70413a5@github.com>

On Fri, 17 Sep 2021 15:46:51 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.desktop still uses old approach with String.indexOf to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

Looks fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5565


From pbansal at openjdk.java.net  Wed Sep 29 08:46:33 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 29 Sep 2021 08:46:33 GMT
Subject: RFR: 8274496: Use String.contains() instead of String.indexOf()
 in java.desktop
In-Reply-To: <xfGt9s0_ZLvwVgCEAj8sF4tCvQqNztpHBMlih_9CtS8=.b3b0ed70-d010-4153-814b-1af900f53ee1@github.com>
References: <xfGt9s0_ZLvwVgCEAj8sF4tCvQqNztpHBMlih_9CtS8=.b3b0ed70-d010-4153-814b-1af900f53ee1@github.com>
Message-ID: <J3MuTrT1prU1yiWO0Za3GNoJMhx12poOXkgB4uW68eI=.5cdc1888-82ef-4954-ae03-e78785d10bb6@github.com>

On Fri, 17 Sep 2021 15:46:51 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.desktop still uses old approach with String.indexOf to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

looks good to me

-------------

Marked as reviewed by pbansal (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5565


From github.com+741251+turbanoff at openjdk.java.net  Wed Sep 29 08:49:03 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 29 Sep 2021 08:49:03 GMT
Subject: RFR: 8274497: Unnecessary Vector usage in AquaFileSystemModel
Message-ID: <RynQ8VCkYlanv_kRkwdAOM3__VTfXj8gQA-Q8Pyz1XA=.cb960c01-46fa-4cba-87d3-83a3033e19fc@github.com>

Fields AquaFileSystemModel.fileCache and AquaFileSystemModel.FilesLoader.queuedTasks are accessed only under synchronized(fileCacheLock).
It means extract synchronization by Vector is not needed.

-------------

Commit messages:
 - [PATCH] Unnecessary Vector usage in AquaFileSystemModel
 - [PATCH] Unnecessary Vector usage in AquaFileSystemModel

Changes: https://git.openjdk.java.net/jdk/pull/5568/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5568&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274497
  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5568.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5568/head:pull/5568

PR: https://git.openjdk.java.net/jdk/pull/5568


From serb at openjdk.java.net  Wed Sep 29 08:49:04 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 29 Sep 2021 08:49:04 GMT
Subject: RFR: 8274497: Unnecessary Vector usage in AquaFileSystemModel
In-Reply-To: <RynQ8VCkYlanv_kRkwdAOM3__VTfXj8gQA-Q8Pyz1XA=.cb960c01-46fa-4cba-87d3-83a3033e19fc@github.com>
References: <RynQ8VCkYlanv_kRkwdAOM3__VTfXj8gQA-Q8Pyz1XA=.cb960c01-46fa-4cba-87d3-83a3033e19fc@github.com>
Message-ID: <duin5m_vFrDYsKidu4esXsSdAzEy0Z4-xqSWJ-vh7BU=.9b91af8c-4f54-4cc9-9ff5-2fd1630f40e5@github.com>

On Fri, 17 Sep 2021 20:32:00 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Fields AquaFileSystemModel.fileCache and AquaFileSystemModel.FilesLoader.queuedTasks are accessed only under synchronized(fileCacheLock).
> It means extract synchronization by Vector is not needed.

Looks fine, please update the copyright year.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5568


From github.com+741251+turbanoff at openjdk.java.net  Wed Sep 29 11:17:47 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 29 Sep 2021 11:17:47 GMT
Subject: RFR: 8274505: Too weak variable type leads to unnecessary cast in
 java.desktop
Message-ID: <6cJslwsJnRSY_LscZNkLV6zo3yLRh2TYkTUTY6qx-Kw=.a6d0d551-6c0a-40af-af26-1fbd70b9b319@github.com>

Such casts are actually redundant, but they are inserted, because variable is declared with too weak type.

-------------

Commit messages:
 - [PATCH] Too weak variable type leads to unnecessary cast in java.desktop
 - [PATCH] Too weak variable type leads to unnecessary cast in java.desktop

Changes: https://git.openjdk.java.net/jdk/pull/5731/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5731&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274505
  Stats: 78 lines in 11 files changed: 0 ins; 22 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5731/head:pull/5731

PR: https://git.openjdk.java.net/jdk/pull/5731


From serb at openjdk.java.net  Wed Sep 29 11:17:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 29 Sep 2021 11:17:48 GMT
Subject: RFR: 8274505: Too weak variable type leads to unnecessary cast in
 java.desktop
In-Reply-To: <6cJslwsJnRSY_LscZNkLV6zo3yLRh2TYkTUTY6qx-Kw=.a6d0d551-6c0a-40af-af26-1fbd70b9b319@github.com>
References: <6cJslwsJnRSY_LscZNkLV6zo3yLRh2TYkTUTY6qx-Kw=.a6d0d551-6c0a-40af-af26-1fbd70b9b319@github.com>
Message-ID: <OvNeeUk9iVbxZfEiYZHG93cQaNekcb5t-m2fxMX5bVM=.c7fc1326-9f83-4bd9-9b86-c30f442203da@github.com>

On Tue, 28 Sep 2021 08:02:12 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Such casts are actually redundant, but they are inserted, because variable is declared with too weak type.

src/java.desktop/share/classes/javax/swing/JTree.java line 2046:

> 2044:                 // expensive!
> 2045:                 if(path != parent && value != null &&
> 2046:                    value.booleanValue() &&

here and bellow, unboxing is not needed as well?

src/java.desktop/share/classes/javax/swing/text/html/AccessibleHTML.java line 745:

> 743:             JTextComponent comp = getTextComponent();
> 744:             if (comp != null) {
> 745:                 if (comp.isEditable()) {

is it possible to merge two "if"? or even "return comp != null && comp.isEditable();"?

src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java line 4233:

> 4231:                             newAttrs = new SimpleAttributeSet();
> 4232:                             newAttrs.addAttribute
> 4233:                                               (StyleConstants.NameAttribute,

Looks like this parameter can be moved one line above?

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 857:

> 855:                         bounds = lBounds.getBounds();
> 856:                         bounds.add((rBounds instanceof Rectangle) ?
> 857:                                     (Rectangle)rBounds : rBounds.getBounds());

You can eliminate the "lBounds.getBounds()" as well.

src/java.desktop/share/classes/javax/swing/text/rtf/RTFGenerator.java line 523:

> 521:             }
> 522:             if (newStyle != null) {
> 523:                 writeControlWord("ds", newStyle.intValue());

unboxing can be removed as well?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5731


From aivanov at openjdk.java.net  Wed Sep 29 11:47:44 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 29 Sep 2021 11:47:44 GMT
Subject: RFR: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
In-Reply-To: <zCEWuiPFEQjCPyMOTwbml_Vrizt_rru2Dxbz2Tvo1-w=.2854d3e0-d4cb-4fe5-b537-0f06a60d9061@github.com>
References: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
 <f4VQLXrX69Y2aq7OpArI0Pid7nOKP0t8H8TD6egwzck=.907cbda4-5f7c-45de-9592-e929bddf640a@github.com>
 <zCEWuiPFEQjCPyMOTwbml_Vrizt_rru2Dxbz2Tvo1-w=.2854d3e0-d4cb-4fe5-b537-0f06a60d9061@github.com>
Message-ID: <sqrFNNTmN_O2vQq6ZP8rDXg9ncCQ-b9LODh_mK1Jy6U=.6b5c89ed-f918-4c27-b483-69d16648757f@github.com>

On Wed, 29 Sep 2021 01:40:24 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> It is possible that the test is too strict or this is a jdk bug. But I am not sure it is possible to investigate this issue based on the bug description in the JBS.
>> @aivanov-jdk please take a look.
>
>> It is possible that the test is too strict or this is a jdk bug. But I am not sure it is possible to investigate this issue based on the bug description in the JBS. @aivanov-jdk please take a look.
> 
> Can I problemlist this test?
> Then we'll have enough time to investigate the root cause.
> Thanks.

@DamonFool could you attach the image to the bug report?

The image `editorPane.png` is automatically saved for analysis if the test fails, you should find in it the test artefacts along with the jtreg test log.

Could you elaborate on what *our non-GUI platforms* are? What is the OS? What is the CPU?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5744


From aivanov at openjdk.java.net  Wed Sep 29 11:54:36 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 29 Sep 2021 11:54:36 GMT
Subject: RFR: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
In-Reply-To: <sqrFNNTmN_O2vQq6ZP8rDXg9ncCQ-b9LODh_mK1Jy6U=.6b5c89ed-f918-4c27-b483-69d16648757f@github.com>
References: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
 <f4VQLXrX69Y2aq7OpArI0Pid7nOKP0t8H8TD6egwzck=.907cbda4-5f7c-45de-9592-e929bddf640a@github.com>
 <zCEWuiPFEQjCPyMOTwbml_Vrizt_rru2Dxbz2Tvo1-w=.2854d3e0-d4cb-4fe5-b537-0f06a60d9061@github.com>
 <sqrFNNTmN_O2vQq6ZP8rDXg9ncCQ-b9LODh_mK1Jy6U=.6b5c89ed-f918-4c27-b483-69d16648757f@github.com>
Message-ID: <hzHnQPfkSt3-DGYOVftuUcUHOcnr1yGRyjcmnW7n39s=.09fc5fcf-d4e7-41e4-afd7-4b30aa8444f7@github.com>

On Wed, 29 Sep 2021 11:44:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> It is possible that the test is too strict or this is a jdk bug. But I am not sure it is possible to investigate this issue based on the bug description in the JBS. @aivanov-jdk please take a look.
>> 
>> Can I problemlist this test?
>> Then we'll have enough time to investigate the root cause.
>> Thanks.
>
> @DamonFool could you attach the image to the bug report?
> 
> The image `editorPane.png` is automatically saved for analysis if the test fails, you should find in it the test artefacts along with the jtreg test log.
> 
> Could you elaborate on what *our non-GUI platforms* are? What is the OS? What is the CPU?

> It is possible that the test is too strict or this is a jdk bug. But I am not sure it is possible to investigate this issue based on the bug description in the JBS. @aivanov-jdk please take a look.

It could be too strict to the width of the fourth line of text. Yet it's not the case here. If the font size is tiny, it could be possible that the long text fits in less lines than four.

The image is required for analysis. And it looks the image isn't saved if assertion error is thrown.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5744


From mwallace at ccmtrading.com  Wed Sep 29 12:23:32 2021
From: mwallace at ccmtrading.com (Matthew Wallace)
Date: Wed, 29 Sep 2021 07:23:32 -0500
Subject: HiDPI Fractional Scaling on Linux/GTK
Message-ID: <CAFJNjUeOVgr8Nmuwddh4faO2Wv3Q+s7s0P+dAUMyGBnRXAsCAA@mail.gmail.com>

I'd like to use fractional scaling in my swing application on Linux (GTK).
My application already works perfectly with fractional scaling on Windows
(Java seems to abide by the system settings) but on Linux the system
settings are ignored and setting GDK_SCALE only works for integer values.
Could anyone familiar with this outline for me the work needed to support
fractional scaling on Linux?  I'm willing to do some hacking to make this
work, but I really have no idea where to start or if it's even feasible.
Any help is greatly appreciated.


From aivanov at openjdk.java.net  Wed Sep 29 12:29:36 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 29 Sep 2021 12:29:36 GMT
Subject: RFR: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
In-Reply-To: <sqrFNNTmN_O2vQq6ZP8rDXg9ncCQ-b9LODh_mK1Jy6U=.6b5c89ed-f918-4c27-b483-69d16648757f@github.com>
References: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
 <f4VQLXrX69Y2aq7OpArI0Pid7nOKP0t8H8TD6egwzck=.907cbda4-5f7c-45de-9592-e929bddf640a@github.com>
 <zCEWuiPFEQjCPyMOTwbml_Vrizt_rru2Dxbz2Tvo1-w=.2854d3e0-d4cb-4fe5-b537-0f06a60d9061@github.com>
 <sqrFNNTmN_O2vQq6ZP8rDXg9ncCQ-b9LODh_mK1Jy6U=.6b5c89ed-f918-4c27-b483-69d16648757f@github.com>
Message-ID: <wyU6zMHeItvm_ui5azfeF-c5Dvrovk6hNXTned-Z5CE=.d4a153de-0980-4002-8a93-c81b17000c00@github.com>

On Wed, 29 Sep 2021 11:44:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The image `editorPane.png` is automatically saved for analysis if the test fails, you should find in it the test artefacts along with the jtreg test log.

It is not saved on `AssertionError` ? my bad.  
I updated the test so that it saves the `editorPane.png` image if any exception occurs.

Could you please take the updated version of `bug6364882.java` from my [JDK-8274465 branch](https://github.com/openjdk/jdk/compare/master...aivanov-jdk:JDK-8274465) or [copy the `bug6364882.java` file](https://raw.githubusercontent.com/aivanov-jdk/jdk/15f0bbf89dcd9c3e2cb4116b9059cc506f9d937b/test/jdk/javax/swing/text/ParagraphView/6364882/bug6364882.java)? Then re-run the test and attach the image. Please also provide the console output of the test, it will contain the view dumps as well as the font used.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5744


From jiefu at openjdk.java.net  Wed Sep 29 13:57:40 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 29 Sep 2021 13:57:40 GMT
Subject: RFR: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
In-Reply-To: <wyU6zMHeItvm_ui5azfeF-c5Dvrovk6hNXTned-Z5CE=.d4a153de-0980-4002-8a93-c81b17000c00@github.com>
References: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
 <f4VQLXrX69Y2aq7OpArI0Pid7nOKP0t8H8TD6egwzck=.907cbda4-5f7c-45de-9592-e929bddf640a@github.com>
 <zCEWuiPFEQjCPyMOTwbml_Vrizt_rru2Dxbz2Tvo1-w=.2854d3e0-d4cb-4fe5-b537-0f06a60d9061@github.com>
 <sqrFNNTmN_O2vQq6ZP8rDXg9ncCQ-b9LODh_mK1Jy6U=.6b5c89ed-f918-4c27-b483-69d16648757f@github.com>
 <wyU6zMHeItvm_ui5azfeF-c5Dvrovk6hNXTned-Z5CE=.d4a153de-0980-4002-8a93-c81b17000c00@github.com>
Message-ID: <4ZAUOHFKlPfKigk7Vb56ea3thUiJTThzOcA1NsoTuXU=.1706e383-364b-4366-8df6-2211ea80ccc8@github.com>

On Wed, 29 Sep 2021 12:25:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > The image `editorPane.png` is automatically saved for analysis if the test fails, you should find in it the test artefacts along with the jtreg test log.
> 
> It is not saved on `AssertionError` ? my bad. I updated the test so that it saves the `editorPane.png` image if any exception occurs.
> 
> Could you please take the updated version of `bug6364882.java` from my [JDK-8274465 branch](https://github.com/openjdk/jdk/compare/master...aivanov-jdk:JDK-8274465) or [copy the `bug6364882.java` file](https://raw.githubusercontent.com/aivanov-jdk/jdk/15f0bbf89dcd9c3e2cb4116b9059cc506f9d937b/test/jdk/javax/swing/text/ParagraphView/6364882/bug6364882.java)? Then re-run the test and attach the image. Please also provide the console output of the test, it will contain the view dumps as well as the font used.

Good!
Thanks @aivanov-jdk for your help.

My colleague @xpbob would like to follow this issue.
We agree with you that the test shouldn't be headful.

Since it's near our National Day, many of us would go on vacation.
He may reply your questions either tonight or the day after tomorrow.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5744


From prr at openjdk.java.net  Wed Sep 29 16:12:37 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 29 Sep 2021 16:12:37 GMT
Subject: RFR: 8273634: [TEST_BUG] Improve
 javax/swing/text/ParagraphView/6364882/bug6364882.java
In-Reply-To: <acWloNjzZyq31_HOlFJtQL-B7tVJE0PeAm-gXSUSa88=.79753fa2-d1b1-49b1-b972-d487be9011b4@github.com>
References: <acWloNjzZyq31_HOlFJtQL-B7tVJE0PeAm-gXSUSa88=.79753fa2-d1b1-49b1-b972-d487be9011b4@github.com>
Message-ID: <H342HKQm0evdFxlySLIDnsMtAkWCSCLp53pPN9ORkhY=.55605af3-ea30-419f-a5e6-74ddf132d578@github.com>

On Thu, 23 Sep 2021 19:19:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test is being moved from the closed to open.
> 
> I updated the `bug6364882.java` test so that it's headless now. If it fails, the image of the `editorPane` is saved for analysis. I also added more asserts which verify:
> 
> ? the first three lines are aligned to the right edge;
> ? the fourth line isn't justified and its width is less than 3/4 of the width;
> ? the fifth and sixth lines have width less than that of the fourth line and have the same width.
> 
> There's an option to show the UI for visual inspection as well as to save the image even if the test passes; use `-show` and/or `-save` parameters to the test correspondingly.
> 
> [1] [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882): Last line of a paragraph should not be justified

I've looked at the test a tad more and two comments
1) if it fails, it dumps an image. You can provide that image
2) It is sensitive to the actual font. If your default font for whatever reason is of a size thatonemore or one less word will fit on a line, then it will fail. This does look like a test problem to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5661


From aivanov at openjdk.java.net  Wed Sep 29 16:44:07 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 29 Sep 2021 16:44:07 GMT
Subject: RFR: 8273634: [TEST_BUG] Improve
 javax/swing/text/ParagraphView/6364882/bug6364882.java
In-Reply-To: <H342HKQm0evdFxlySLIDnsMtAkWCSCLp53pPN9ORkhY=.55605af3-ea30-419f-a5e6-74ddf132d578@github.com>
References: <acWloNjzZyq31_HOlFJtQL-B7tVJE0PeAm-gXSUSa88=.79753fa2-d1b1-49b1-b972-d487be9011b4@github.com>
 <H342HKQm0evdFxlySLIDnsMtAkWCSCLp53pPN9ORkhY=.55605af3-ea30-419f-a5e6-74ddf132d578@github.com>
Message-ID: <1mGO5O1r20DbY_5PGEXxcTkNQkiiwCWYVAQw_13XryQ=.d00126fd-4665-43b8-9d0f-671d2e2a089f@github.com>

On Wed, 29 Sep 2021 16:09:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> The test is being moved from the closed to open.
>> 
>> I updated the `bug6364882.java` test so that it's headless now. If it fails, the image of the `editorPane` is saved for analysis. I also added more asserts which verify:
>> 
>> ? the first three lines are aligned to the right edge;
>> ? the fourth line isn't justified and its width is less than 3/4 of the width;
>> ? the fifth and sixth lines have width less than that of the fourth line and have the same width.
>> 
>> There's an option to show the UI for visual inspection as well as to save the image even if the test passes; use `-show` and/or `-save` parameters to the test correspondingly.
>> 
>> [1] [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882): Last line of a paragraph should not be justified
>
> I've looked at the test a tad more and two comments
> 1) if it fails, it dumps an image. You can provide that image
> 2) It is sensitive to the actual font. If your default font for whatever reason is of a size thatonemore or one less word will fit on a line, then it will fail. This does look like a test problem to me.

Thank you, @prrace, for your comments.

1. Unfortunately, it [doesn't save the image](https://github.com/openjdk/jdk/pull/5744#issuecomment-930127270) if an exception is thrown. I overlooked this fact.
2. I agree I should've made it more flexible to accommodate for possible font size differences.

I'll fix these issues and create my own PR for [JDK-8274465](https://bugs.openjdk.java.net/browse/JDK-8274465).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5661


From aivanov at openjdk.java.net  Wed Sep 29 16:51:37 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 29 Sep 2021 16:51:37 GMT
Subject: RFR: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
In-Reply-To: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
References: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
Message-ID: <New6iSSK5P6CMWdajIne5hkFGYNVaNiO4s7uFCjLSOQ=.42a1d825-ad33-4978-9a08-6f4335d3292b@github.com>

On Tue, 28 Sep 2021 23:39:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> javax/swing/text/ParagraphView/6364882/bug6364882.java was observed failing on our non-GUI platforms.
> So I guess it should be marked as headful.
> 
> Thanks.
> Best regards,
> Jie

There are relevant comments raised by @prrace in #5661.

For convenience, I'm posting them here:

[@prrace said](https://github.com/openjdk/jdk/pull/5661#issuecomment-930321371):
I've looked at the test a tad more and two comments

1. if it fails, it dumps an image. You can provide that image
2. It is sensitive to the actual font. If your default font for whatever reason is of a size thatonemore or one less word will fit on a line, then it will fail. This does look like a test problem to me.

[@aivanov-jdk replied](https://github.com/openjdk/jdk/pull/5661#issuecomment-930346301):

Thank you, @prrace, for your comments.

1. Unfortunately, [it doesn't save the image](https://github.com/openjdk/jdk/pull/5744#issuecomment-930127270) if an exception is thrown. I overlooked this fact.
2. I agree I should've made it more flexible to accommodate for possible font size differences.

I'll fix these issues and create my own PR for [JDK-8274465](https://bugs.openjdk.java.net/browse/JDK-8274465).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5744


From prr at openjdk.java.net  Wed Sep 29 16:53:38 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 29 Sep 2021 16:53:38 GMT
Subject: RFR: 8273634: [TEST_BUG] Improve
 javax/swing/text/ParagraphView/6364882/bug6364882.java
In-Reply-To: <acWloNjzZyq31_HOlFJtQL-B7tVJE0PeAm-gXSUSa88=.79753fa2-d1b1-49b1-b972-d487be9011b4@github.com>
References: <acWloNjzZyq31_HOlFJtQL-B7tVJE0PeAm-gXSUSa88=.79753fa2-d1b1-49b1-b972-d487be9011b4@github.com>
Message-ID: <L3hiC2K1aKN0AIR6MC3mycMbLsiD7zdhefVNpgbKFJg=.e8044d93-7b3a-4fbb-8e2c-1ac4cf917fdc@github.com>

On Thu, 23 Sep 2021 19:19:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test is being moved from the closed to open.
> 
> I updated the `bug6364882.java` test so that it's headless now. If it fails, the image of the `editorPane` is saved for analysis. I also added more asserts which verify:
> 
> ? the first three lines are aligned to the right edge;
> ? the fourth line isn't justified and its width is less than 3/4 of the width;
> ? the fifth and sixth lines have width less than that of the fourth line and have the same width.
> 
> There's an option to show the UI for visual inspection as well as to save the image even if the test passes; use `-show` and/or `-save` parameters to the test correspondingly.
> 
> [1] [JDK-6364882](https://bugs.openjdk.java.net/browse/JDK-6364882): Last line of a paragraph should not be justified

"Unfortunately, it doesn't save the image if an exception is thrown. I overlooked this fact."

oops :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5661


From serb at openjdk.java.net  Wed Sep 29 19:44:42 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 29 Sep 2021 19:44:42 GMT
Subject: RFR: 8274496: Use String.contains() instead of String.indexOf()
 in java.desktop
In-Reply-To: <xfGt9s0_ZLvwVgCEAj8sF4tCvQqNztpHBMlih_9CtS8=.b3b0ed70-d010-4153-814b-1af900f53ee1@github.com>
References: <xfGt9s0_ZLvwVgCEAj8sF4tCvQqNztpHBMlih_9CtS8=.b3b0ed70-d010-4153-814b-1af900f53ee1@github.com>
Message-ID: <E4jjKQYzaku119inaPT-OybSlStMssjCWAEWx84Kaik=.b1ac9952-5c25-48ab-a675-798342610f45@github.com>

On Fri, 17 Sep 2021 15:46:51 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.desktop still uses old approach with String.indexOf to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5565


From aivanov at openjdk.java.net  Wed Sep 29 19:56:32 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 29 Sep 2021 19:56:32 GMT
Subject: RFR: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
In-Reply-To: <4ZAUOHFKlPfKigk7Vb56ea3thUiJTThzOcA1NsoTuXU=.1706e383-364b-4366-8df6-2211ea80ccc8@github.com>
References: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
 <f4VQLXrX69Y2aq7OpArI0Pid7nOKP0t8H8TD6egwzck=.907cbda4-5f7c-45de-9592-e929bddf640a@github.com>
 <zCEWuiPFEQjCPyMOTwbml_Vrizt_rru2Dxbz2Tvo1-w=.2854d3e0-d4cb-4fe5-b537-0f06a60d9061@github.com>
 <sqrFNNTmN_O2vQq6ZP8rDXg9ncCQ-b9LODh_mK1Jy6U=.6b5c89ed-f918-4c27-b483-69d16648757f@github.com>
 <wyU6zMHeItvm_ui5azfeF-c5Dvrovk6hNXTned-Z5CE=.d4a153de-0980-4002-8a93-c81b17000c00@github.com>
 <4ZAUOHFKlPfKigk7Vb56ea3thUiJTThzOcA1NsoTuXU=.1706e383-364b-4366-8df6-2211ea80ccc8@github.com>
Message-ID: <H2g1w8NQ81Sj_iSyY2PbblEv2kxLZ_jQmg20sgRHfDQ=.b8a4b24c-232f-46e9-aff2-be0517c36560@github.com>

On Wed, 29 Sep 2021 13:54:25 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>>> The image `editorPane.png` is automatically saved for analysis if the test fails, you should find in it the test artefacts along with the jtreg test log.
>> 
>> It is not saved on `AssertionError` ? my bad.  
>> I updated the test so that it saves the `editorPane.png` image if any exception occurs.
>> 
>> Could you please take the updated version of `bug6364882.java` from my [JDK-8274465 branch](https://github.com/openjdk/jdk/compare/master...aivanov-jdk:JDK-8274465) or [copy the `bug6364882.java` file](https://raw.githubusercontent.com/aivanov-jdk/jdk/15f0bbf89dcd9c3e2cb4116b9059cc506f9d937b/test/jdk/javax/swing/text/ParagraphView/6364882/bug6364882.java)? Then re-run the test and attach the image. Please also provide the console output of the test, it will contain the view dumps as well as the font used.
>
>> > The image `editorPane.png` is automatically saved for analysis if the test fails, you should find in it the test artefacts along with the jtreg test log.
>> 
>> It is not saved on `AssertionError` ? my bad. I updated the test so that it saves the `editorPane.png` image if any exception occurs.
>> 
>> Could you please take the updated version of `bug6364882.java` from my [JDK-8274465 branch](https://github.com/openjdk/jdk/compare/master...aivanov-jdk:JDK-8274465) or [copy the `bug6364882.java` file](https://raw.githubusercontent.com/aivanov-jdk/jdk/15f0bbf89dcd9c3e2cb4116b9059cc506f9d937b/test/jdk/javax/swing/text/ParagraphView/6364882/bug6364882.java)? Then re-run the test and attach the image. Please also provide the console output of the test, it will contain the view dumps as well as the font used.
> 
> Good!
> Thanks @aivanov-jdk for your help.
> 
> My colleague @xpbob would like to follow this issue.
> We agree with you that the test shouldn't be headful.
> 
> Since it's near our National Day, many of us would go on vacation.
> He may reply your questions either tonight or the day after tomorrow.
> Thanks.

@DamonFool, I have created a new PR #5761 which should fix the test failure.

Could you please test whether it fixes the failure?

Please, also perform the [previous experiment](#issuecomment-930127270) first and attach the image of the failure to JBS.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5744


From aivanov at openjdk.java.net  Wed Sep 29 19:56:45 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 29 Sep 2021 19:56:45 GMT
Subject: RFR: 8274465: Fix
 javax/swing/text/ParagraphView/6364882/bug6364882.java failures
Message-ID: <8-ZdjnyUa7I3IOqegK8TOviOQVx0O3rrKppceY_71R0=.aa20230f-bc96-413d-91f1-2731c62a9639@github.com>

I made the test and its assertions more flexible in regards to the font size and to the number of lines.

The test still requires there are at least four lines so that the text is wrapped before the first hard line break; thus at least one line of text is justified. This pre-requisite gets broken if `font-size: 4pt` property is added to the `style` attribute in my local environment. I also ran the test with a few larger font sizes, the updated test passes successfully.

I made sure the image is saved if any exception gets thrown from `checkJustification`, which wasn't the case.

This PR replaces #5744.

-------------

Commit messages:
 - 8274465: Some cleanup
 - 8274465: Make the test more flexible to the number of lines and font-size
 - 8274465: Save the image of editorPane on any exception

Changes: https://git.openjdk.java.net/jdk/pull/5761/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5761&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274465
  Stats: 64 lines in 1 file changed: 20 ins; 7 del; 37 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5761.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5761/head:pull/5761

PR: https://git.openjdk.java.net/jdk/pull/5761


From serb at openjdk.java.net  Wed Sep 29 20:09:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 29 Sep 2021 20:09:36 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in
 the java.util.logging
In-Reply-To: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
Message-ID: <0CGQo0Xsjz8WEKH4AonQJMAhYK3Bhc4wqrIQCSawfJk=.f414c9ed-bf36-4eae-bc37-372ccc8bcee1@github.com>

On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> At the time Java supported applets and webstart, a special mechanism for launching various applications in one JVM was used to reduce memory usage and each application was isolated from each other.
> 
> This isolation was implemented via ThreadGroups where each application created its own thread group and all data for the application was stored in the context of its own group.
> 
> Some parts of the JDK used ThreadGroups directly, others used special classes like sun.awt.AppContext.
> 
> Such sandboxing became useless since the plugin and webstart are no longer supported and were removed in jdk11.
> 
> Note that this is just a first step for the overall cleanup, here is my plan:
> 1. Cleanup the usage of AppContext in the ?java.util.logging.LogManager" class in the java.base module.
> 2. Cleanup the usage of TheadGroup in the JavaSound
> 3. Cleanup the usage of TheadGroup in the JavaBeans
> 4. Cleanup the usage of AppContext in the Swing
> 5. Cleanup the usage of AppContext in the AWT
> 6. Delete the AppContext class.
> 
> The current PR is for the first step. So this is the request to delete the usage of AppContext in the LogManager and related tests.
> 
> Tested by tier1/tier2/tier3 and jdk_desktop tests.

Does anybody have any other suggestions?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5326


From serb at openjdk.java.net  Wed Sep 29 20:29:44 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 29 Sep 2021 20:29:44 GMT
Subject: RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged()
 returns leftButton and rightButton as null with GTKLookAndFeel [v3]
In-Reply-To: <gn3LMUUrEY_c2nN80EtPV17dp4EngVkxIRghNQPmfkE=.37d5ff5e-2dd1-406c-995d-b40e3bb9c0bc@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
 <gn3LMUUrEY_c2nN80EtPV17dp4EngVkxIRghNQPmfkE=.37d5ff5e-2dd1-406c-995d-b40e3bb9c0bc@github.com>
Message-ID: <woNWSpl9Qi62Ch76LZfPYgcubS_VUNIn-g40xRe37F4=.a3a41169-369d-4ed5-9d61-506d8da402f1@github.com>

On Mon, 27 Sep 2021 13:34:44 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> The function documentation for oneTouchExpandableChanged states that the function does couple of things, but in reality  it only does those things if the Look and Feel supports the supportsOneTouchButtons. In case the Look and Feel does not support supportsOneTouchButtons, this functions just returns in beginning and does not do anything.
>> This change clarifies the above in function documentation.
>
> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes according to JBS discussion

Not sure that we need a CSR for such change.

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5263


From github.com+90066231+alisenchung at openjdk.java.net  Wed Sep 29 22:29:19 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Wed, 29 Sep 2021 22:29:19 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v8]
In-Reply-To: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
Message-ID: <zsJFJUWvjsJU0y0oAZnwYSsP4ohFybmjpc3zLCUbBFk=.b3f71931-d4a7-46b4-95e6-d00a1bd74e51@github.com>

> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  added check for fullscreen mode to synthesize mouseEntered event

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5497/files
  - new: https://git.openjdk.java.net/jdk/pull/5497/files/024f15cf..fc14e5bf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5497&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5497&range=06-07

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5497.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5497/head:pull/5497

PR: https://git.openjdk.java.net/jdk/pull/5497


From github.com+90066231+alisenchung at openjdk.java.net  Wed Sep 29 22:29:21 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Wed, 29 Sep 2021 22:29:21 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v5]
In-Reply-To: <0yD747f6JnEANPofJGjHIQ9pcbwfhEvM1IzJ9SDYZH4=.cc859447-00fd-4254-8946-452b25f89be1@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <H78jcij8_hr0xKEufLCpKh7vo2ZaTQosTs4rYvBaMNk=.22515bc6-d84c-42c1-967a-c42ec8197f18@github.com>
 <57_CpBYrvFjr586rGPWjeDbbLfUqqVcwDm4pbT2neO8=.e09a2e78-3d44-41c7-b2d0-8add8fcf8c2f@github.com>
 <GqCIC4UlNdfmK4fi5OtgVZGPc1br6JXZB_IqDCivIxg=.51b1bbe0-e8e0-4f47-a6bf-08322d610487@github.com>
 <mboe3-va-xCqCw-3V6v8dZCS3qKY6XCo1s-11A5SJT0=.6b82f148-0608-44be-bed9-c43178523d91@github.com>
 <hL97MSSd0FzPLyjpYA69aVKPYaBHiwUWosienSYYXx0=.ae293cff-8a54-4608-9094-81be55a19b83@github.com>
 <u5gbtUqadhb2mBqdqZy-Okek_5_hLLpMzQBuBCoL-6M=.05e4698c-dc77-44d7-8386-c5769f01841f@github.com>
 <g-Aa0w-ayHdF9wpwBtrKQ2qxxy-djWQllojs1YFpIEg=.64f0e4a3-95ce-4e17-b567-236c45576979@github.com>
 <QItelGXQ3wfHIrIdt_PL1ocquQzWVjB4Ox6xvXRtwUY=.ba15cc5f-cb2e-4b88-b352-db90f91216a9@github.com>
 <0yD747f6JnEANPofJGjHIQ9pcbwfhEvM1IzJ9SDYZH4=.cc859447-00fd-4254-8946-452b25f89be1@github.com>
Message-ID: <Fyl_feuOYZLG8MksDbCN5vORM3747KytEmQ4KqKeiVs=.ef5aa96e-6d60-4398-b683-1293ca8714ee@github.com>

On Fri, 24 Sep 2021 19:49:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I guess the only test which makes sense here is the test for JDK-8013468 and it is "problem listed" due to a reflection issue. I suggest checking how it works.

This test fails both before and after the change. However, before the change if I'm constantly moving the mouse the test will pass whereas after the change it won't pass even if I'm moving my mouse. I re-added the synthesizeMouseEnteredExitedEventsForAllWindows with a check for in fullscreen mode which should only be true if its in true fullscreen mode (without title bar). This keeps the behavior from before the change, but the test won't pass if the mouse isn't moving during the fullscreen.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From serb at openjdk.java.net  Wed Sep 29 23:02:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 29 Sep 2021 23:02:37 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v8]
In-Reply-To: <zsJFJUWvjsJU0y0oAZnwYSsP4ohFybmjpc3zLCUbBFk=.b3f71931-d4a7-46b4-95e6-d00a1bd74e51@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <zsJFJUWvjsJU0y0oAZnwYSsP4ohFybmjpc3zLCUbBFk=.b3f71931-d4a7-46b4-95e6-d00a1bd74e51@github.com>
Message-ID: <IkLXCri7K15PKo47WW73qa5x5kz3_TrDxhd7kiqvnAw=.f09030d9-8663-4425-8ba4-a3aaf2571dd6@github.com>

On Wed, 29 Sep 2021 22:29:19 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added check for fullscreen mode to synthesize mouseEntered event

It sound strange, isn't the "_deliverMoveResizeEvent" should be called on the resize only, why it affect the mouse move events which posted later? the new flag NSWindowStyleMaskFullScreen will work when the window was moved to the full screen, what about the case when the window will moved from the full screen -> the mouse will appier outside of the window?

BTW we also have a call to synthesizeMouseEnteredExitedEventsForAllWindows in the windowDidEnterFullScreen which should do what you tried to achieve in the latest patch, why it does not work?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From jiefu at openjdk.java.net  Wed Sep 29 23:17:35 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 29 Sep 2021 23:17:35 GMT
Subject: RFR: 8274465: Fix
 javax/swing/text/ParagraphView/6364882/bug6364882.java failures
In-Reply-To: <8-ZdjnyUa7I3IOqegK8TOviOQVx0O3rrKppceY_71R0=.aa20230f-bc96-413d-91f1-2731c62a9639@github.com>
References: <8-ZdjnyUa7I3IOqegK8TOviOQVx0O3rrKppceY_71R0=.aa20230f-bc96-413d-91f1-2731c62a9639@github.com>
Message-ID: <c5rEW8SLCnm2Lz5_ruK8tplI-2MB5Zg-XIwVQIUb_2o=.7f282cd3-bee8-45da-ad70-3297d68e5032@github.com>

On Wed, 29 Sep 2021 19:48:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I made the test and its assertions more flexible in regards to the font size and to the number of lines.
> 
> The test still requires there are at least four lines so that the text is wrapped before the first hard line break; thus at least one line of text is justified. This pre-requisite gets broken if `font-size: 4pt` property is added to the `style` attribute in my local environment. I also ran the test with a few larger font sizes, the updated test passes successfully.
> 
> I made sure the image is saved if any exception gets thrown from `checkJustification`, which wasn't the case.
> 
> This PR replaces #5744.

Good.
I'll spend some time testing this fix and will let you know in this pr.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5761


From jiefu at openjdk.java.net  Wed Sep 29 23:19:40 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 29 Sep 2021 23:19:40 GMT
Subject: RFR: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
In-Reply-To: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
References: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
Message-ID: <QSQ4zYL4FrAjK9Ato-efweC2QQo31N8V3NU-_XceH84=.aff9d25c-52f0-426c-aa7d-a785b724b16a@github.com>

On Tue, 28 Sep 2021 23:39:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> javax/swing/text/ParagraphView/6364882/bug6364882.java was observed failing on our non-GUI platforms.
> So I guess it should be marked as headful.
> 
> Thanks.
> Best regards,
> Jie

Will discuss it in https://github.com/openjdk/jdk/pull/5761 .
So close this one.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5744


From jiefu at openjdk.java.net  Wed Sep 29 23:19:40 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 29 Sep 2021 23:19:40 GMT
Subject: Withdrawn: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
In-Reply-To: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
References: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
Message-ID: <JmJVSjySDi0JgqXpZKU3XZEYPjEeSeOSAv1t_KgopqQ=.e8765c17-8fe6-4d0e-803d-74425c216186@github.com>

On Tue, 28 Sep 2021 23:39:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> javax/swing/text/ParagraphView/6364882/bug6364882.java was observed failing on our non-GUI platforms.
> So I guess it should be marked as headful.
> 
> Thanks.
> Best regards,
> Jie

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5744


From serb at openjdk.java.net  Thu Sep 30 04:52:42 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 30 Sep 2021 04:52:42 GMT
Subject: RFR: 8274505: Too weak variable type leads to unnecessary cast in
 java.desktop
In-Reply-To: <6cJslwsJnRSY_LscZNkLV6zo3yLRh2TYkTUTY6qx-Kw=.a6d0d551-6c0a-40af-af26-1fbd70b9b319@github.com>
References: <6cJslwsJnRSY_LscZNkLV6zo3yLRh2TYkTUTY6qx-Kw=.a6d0d551-6c0a-40af-af26-1fbd70b9b319@github.com>
Message-ID: <QudoCl9CKPP7WsFk8iKXzCPpaLDHBRJwA3J6Zl89qNg=.8b8beef5-d58a-4a47-b4b9-72c80a706d07@github.com>

On Tue, 28 Sep 2021 08:02:12 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Such casts are actually redundant, but they are inserted, because variable is declared with too weak type.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5731


From kizune at openjdk.java.net  Thu Sep 30 06:12:30 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 30 Sep 2021 06:12:30 GMT
Subject: RFR: 8274505: Too weak variable type leads to unnecessary cast in
 java.desktop
In-Reply-To: <6cJslwsJnRSY_LscZNkLV6zo3yLRh2TYkTUTY6qx-Kw=.a6d0d551-6c0a-40af-af26-1fbd70b9b319@github.com>
References: <6cJslwsJnRSY_LscZNkLV6zo3yLRh2TYkTUTY6qx-Kw=.a6d0d551-6c0a-40af-af26-1fbd70b9b319@github.com>
Message-ID: <3-0YcYMeLXfrKkfp_aAeWJzf-ZueFFxbYspbWx2cvAU=.7f46a1e9-f5b3-46e4-a536-bcc02f331ec8@github.com>

On Tue, 28 Sep 2021 08:02:12 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Such casts are actually redundant, but they are inserted, because variable is declared with too weak type.

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5731


From jiefu at openjdk.java.net  Thu Sep 30 06:13:35 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 30 Sep 2021 06:13:35 GMT
Subject: RFR: 8274465: Mark
 javax/swing/text/ParagraphView/6364882/bug6364882.java as headful
In-Reply-To: <QSQ4zYL4FrAjK9Ato-efweC2QQo31N8V3NU-_XceH84=.aff9d25c-52f0-426c-aa7d-a785b724b16a@github.com>
References: <kIrLDGRk3Xzv0rOJOEn2VWojfyy_s5JYdmeV5m5iM6w=.0638a461-6bf3-4fe2-ae3f-0540b5ac714a@github.com>
 <QSQ4zYL4FrAjK9Ato-efweC2QQo31N8V3NU-_XceH84=.aff9d25c-52f0-426c-aa7d-a785b724b16a@github.com>
Message-ID: <eJx6yhtcjIwROvv-sijdFqVSKDQi-aDzQ4gxobG8s74=.4e364ee6-fee8-4461-a260-3b5538bee5d2@github.com>

On Wed, 29 Sep 2021 23:16:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> javax/swing/text/ParagraphView/6364882/bug6364882.java was observed failing on our non-GUI platforms.
>> So I guess it should be marked as headful.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Will discuss it in https://github.com/openjdk/jdk/pull/5761 .
> So close this one.

> @DamonFool, I have created a new PR #5761 which should fix the test failure.
> 
> Could you please test whether it fixes the failure?
> 
> Please, also perform the [previous experiment](#issuecomment-930127270) first and attach the image of the failure to JBS.

The png has been uploaded in the JBS.
Now I am testing your new patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5744


From pbansal at openjdk.java.net  Thu Sep 30 06:16:38 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 30 Sep 2021 06:16:38 GMT
Subject: RFR: 8274505: Too weak variable type leads to unnecessary cast in
 java.desktop
In-Reply-To: <6cJslwsJnRSY_LscZNkLV6zo3yLRh2TYkTUTY6qx-Kw=.a6d0d551-6c0a-40af-af26-1fbd70b9b319@github.com>
References: <6cJslwsJnRSY_LscZNkLV6zo3yLRh2TYkTUTY6qx-Kw=.a6d0d551-6c0a-40af-af26-1fbd70b9b319@github.com>
Message-ID: <L45JhcB-8V0z1QH0amddeT0s6qG67ZV2YWO3SQp3bu8=.628868ba-6230-4157-804c-963aa3ea0053@github.com>

On Tue, 28 Sep 2021 08:02:12 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Such casts are actually redundant, but they are inserted, because variable is declared with too weak type.

Marked as reviewed by pbansal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5731


From jiefu at openjdk.java.net  Thu Sep 30 06:38:37 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 30 Sep 2021 06:38:37 GMT
Subject: RFR: 8274465: Fix
 javax/swing/text/ParagraphView/6364882/bug6364882.java failures
In-Reply-To: <8-ZdjnyUa7I3IOqegK8TOviOQVx0O3rrKppceY_71R0=.aa20230f-bc96-413d-91f1-2731c62a9639@github.com>
References: <8-ZdjnyUa7I3IOqegK8TOviOQVx0O3rrKppceY_71R0=.aa20230f-bc96-413d-91f1-2731c62a9639@github.com>
Message-ID: <KrXA86gn5FKwe7aHtbknCFqnmeLpy1rrTJ22lqcheoQ=.bb99f6ad-c05b-49ae-a006-4419407af4b5@github.com>

On Wed, 29 Sep 2021 19:48:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I made the test and its assertions more flexible in regards to the font size and to the number of lines.
> 
> The test still requires there are at least four lines so that the text is wrapped before the first hard line break; thus at least one line of text is justified. This pre-requisite gets broken if `font-size: 4pt` property is added to the `style` attribute in my local environment. I also ran the test with a few larger font sizes, the updated test passes successfully.
> 
> I made sure the image is saved if any exception gets thrown from `checkJustification`, which wasn't the case.
> 
> This PR replaces #5744.

Marked as reviewed by jiefu (Reviewer).

I've tested this fix on two of our cloud hosts.
Both of them passed.

Although I'm not sure whether it will pass on all our platforms, it's much better now.
So I'm fine with it.

You still need at least one more review since I'm not familiar with this part.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5761


From myano at openjdk.java.net  Thu Sep 30 08:43:30 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 30 Sep 2021 08:43:30 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <POdns3iPgJRlh4vDuqFMSe5bl-AUKhd5lydHPLIpktI=.9aee1075-da2b-41c0-b4f3-35adca4c8091@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <ACRHmQY8PTs2zOxEKTqpI3UP2P_OdWXHccoaHC3FrwM=.6bd5a2c9-b92e-4fbb-babe-005fa463a221@github.com>
 <G4VS1_zNJrOsdiajA3_BrSPWpxzSsRafaUs66mTXv4s=.9a7105b0-c946-4815-a118-00c9fd17cbe1@github.com>
 <YEhDJGgk1J8Ah3dE9amNf6NrOgU6iy6Z23bY9IWA8KM=.c36e6711-f2c1-447b-a9c8-4eb8d2e7516f@github.com>
 <ZZfjrVx5ZQFBKjuIbhaaqGKs8GGDFSxAvfav3_gCAeY=.f7c112ec-757a-403f-b5b9-75908c232fb9@github.com>
 <POdns3iPgJRlh4vDuqFMSe5bl-AUKhd5lydHPLIpktI=.9aee1075-da2b-41c0-b4f3-35adca4c8091@github.com>
Message-ID: <5Cz27HBZADRf75BlHEr0SD89JFLQqlt3mpqQ3qk0cUA=.adb31201-4b61-4bbd-bb12-3a94bb848aa4@github.com>

On Wed, 29 Sep 2021 00:42:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Do you know why we post it twice? It does not seem right, since we repaint all content in the apps like Netbeans/Idea and it is quite a heavyweight operation.

Because SurfaceData is judged to be lost when 1st getGraphics() is called on 1st PaintEvent processing.

https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java#L478

I traced PaintEvent, then I got following stacktrace.


breakpoint hit: "Thread=AWT-EventQueue-0", java.awt.event.PaintEvent.<init>()?line=106 bci=0

  [1] java.awt.event.PaintEvent.<init> (PaintEvent.java:106)
  [2] sun.awt.PaintEventDispatcher.createPaintEvent (PaintEventDispatcher.java:80)
  [3] sun.awt.windows.WComponentPeer.postPaintIfNecessary (WComponentPeer.java:892)
  [4] sun.awt.windows.WComponentPeer.handlePaint (WComponentPeer.java:886)
  [5] sun.java2d.d3d.D3DScreenUpdateManager.repaintPeerTarget (D3DScreenUpdateManager.java:283)
  [6] sun.java2d.d3d.D3DScreenUpdateManager.validate (D3DScreenUpdateManager.java:492)
  [7] sun.java2d.d3d.D3DScreenUpdateManager.createGraphics (D3DScreenUpdateManager.java:260)
  [8] sun.awt.windows.WComponentPeer.getGraphics (WComponentPeer.java:646)
  [9] java.awt.Component.getGraphics (Component.java:3,128)
  [10] sun.awt.RepaintArea.paint (RepaintArea.java:227)
  [11] sun.awt.windows.WComponentPeer.handleEvent (WComponentPeer.java:371)
  [12] java.awt.Component.dispatchEventImpl (Component.java:5,056)
  [13] java.awt.Container.dispatchEventImpl (Container.java:2,325)
  [14] java.awt.Window.dispatchEventImpl (Window.java:2,775)
  [15] java.awt.Component.dispatchEvent (Component.java:4,827)
  [16] java.awt.EventQueue.dispatchEventImpl (EventQueue.java:772)
  [17] java.awt.EventQueue$4.run (EventQueue.java:721)
  [18] java.awt.EventQueue$4.run (EventQueue.java:715)
  [19] java.security.AccessController.executePrivileged (AccessController.java:753)
  [20] java.security.AccessController.doPrivileged (AccessController.java:391)
  [21] java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege (ProtectionDomain.java:85)
  [22] java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege (ProtectionDomain.java:95)
  [23] java.awt.EventQueue$5.run (EventQueue.java:745)
  [24] java.awt.EventQueue$5.run (EventQueue.java:743)
  [25] java.security.AccessController.executePrivileged (AccessController.java:753)
  [26] java.security.AccessController.doPrivileged (AccessController.java:391)
  [27] java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege (ProtectionDomain.java:85)
  [28] java.awt.EventQueue.dispatchEvent (EventQueue.java:742)
  [29] java.awt.EventDispatchThread.pumpOneEventForFilters (EventDispatchThread.java:203)
  [30] java.awt.EventDispatchThread.pumpEventsForFilter (EventDispatchThread.java:124)
  [31] java.awt.EventDispatchThread.pumpEventsForHierarchy (EventDispatchThread.java:113)
  [32] java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:109)
  [33] java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:101)
  [34] java.awt.EventDispatchThread.run (EventDispatchThread.java:90)
AWT-EventQueue-0[1] > >


At 1st PaintEvent is processing, RepaintArea calls getGraphics(), then D3DScreenUpdateManager finally calls new PaintEvent().
So, 2nd PaintEvent is posted and invoked later on EDT.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5491


From github.com+36081106+savoptik at openjdk.java.net  Thu Sep 30 11:25:29 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Thu, 30 Sep 2021 11:25:29 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation [v4]
In-Reply-To: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
Message-ID: <uBWloihxAf_jUKGUdzb8bbMqRklZVoP5jd-SukhRS0k=.15c4bf5a-c65b-4b78-9a7e-67f6af068bb3@github.com>

> We've extended the current implementation of TableAccessibility to make sure that individual cells are voiced when navigating with the keyboard.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  The biggest problem i have is that the new logic reverts the mechanic of the selection mode of the table - when no selection mode set it announces the content of all the cells in the current row and when either row or column selection mode is set it only announces the content of a single cell. Also when only cell selection is allowed it announces row as dimmed which is strange.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5466/files
  - new: https://git.openjdk.java.net/jdk/pull/5466/files/c462fefa..110f4f1a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5466&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5466&range=02-03

  Stats: 768 lines in 13 files changed: 132 ins; 504 del; 132 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5466.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5466/head:pull/5466

PR: https://git.openjdk.java.net/jdk/pull/5466


From github.com+36081106+savoptik at openjdk.java.net  Thu Sep 30 12:02:08 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Thu, 30 Sep 2021 12:02:08 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation [v5]
In-Reply-To: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
Message-ID: <CRrvnV9hDhLkjGogdXZbBbBw3oiYR0NYJWVfINBBNRU=.1f615936-0df8-4cb9-9071-9eb565b8a7df@github.com>

> We've extended the current implementation of TableAccessibility to make sure that individual cells are voiced when navigating with the keyboard.

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. The pull request contains one new commit since the last revision:

  The biggest problem i have is that the new logic reverts the mechanic of the selection mode of the table - when no selection mode set it announces the content of all the cells in the current row and when either row or column selection mode is set it only announces the content of a single cell. Also when only cell selection is allowed it announces row as dimmed which is strange.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5466/files
  - new: https://git.openjdk.java.net/jdk/pull/5466/files/110f4f1a..248e2c64

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5466&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5466&range=03-04

  Stats: 774 lines in 14 files changed: 508 ins; 136 del; 130 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5466.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5466/head:pull/5466

PR: https://git.openjdk.java.net/jdk/pull/5466


From mvs at openjdk.java.net  Thu Sep 30 14:32:46 2021
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 30 Sep 2021 14:32:46 GMT
Subject: RFR: 8274597: [TESTBUG] Two of the dnd tests times out and fails
Message-ID: <0ISZ7X0xu1zN3SLn-p1XkZm8Brkb-Ozu_nTe3RF8xXg=.f3b3c6ed-3719-4347-8f13-a8b89bc1d836@github.com>

These two dnd tests fails most of the time with a time out, mostly noticed in windows 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.

-------------

Commit messages:
 - 8274597: [TESTBUG] Two of the dnd tests times out and fails

Changes: https://git.openjdk.java.net/jdk/pull/5777/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5777&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274597
  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5777.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5777/head:pull/5777

PR: https://git.openjdk.java.net/jdk/pull/5777


From serb at openjdk.java.net  Thu Sep 30 20:21:35 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 30 Sep 2021 20:21:35 GMT
Subject: RFR: 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: <bPoUm64FEMN2fC6sJm80cFX0JmHBrObu_IiaJn0M3zA=.61f066b3-426c-4a62-a399-5ba5d0b110ac@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.

Looks like the hang occurs in some of the hook executed at the "exit" step. DId you check which ShutdownHook is executed and hang? Is it possible it is some of the AWT toolkit related?

	at java.lang.Object.wait(java.base at 11.0.14-ea/Native Method)
	- waiting on <0x00000000ff504d78> (a java.lang.Thread)
	at java.lang.Thread.join(java.base at 11.0.14-ea/Thread.java:1305)
	- waiting to re-lock in wait() <0x00000000ff504d78> (a java.lang.Thread)
	at java.lang.Thread.join(java.base at 11.0.14-ea/Thread.java:1379)
	at java.lang.ApplicationShutdownHooks.runHooks(java.base at 11.0.14-ea/ApplicationShutdownHooks.java:107)
	at java.lang.ApplicationShutdownHooks$1.run(java.base at 11.0.14-ea/ApplicationShutdownHooks.java:46)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5777


From serb at openjdk.java.net  Thu Sep 30 20:38:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 30 Sep 2021 20:38:48 GMT
Subject: RFR: 8274304: Update or Problem List tests which may fail with
 uiScale=2 on macOS
Message-ID: <j-ULwTmOaaJyAo9uzLv-mI9OLjIvpEVoE1iY52j_vv0=.98b2f37f-d11d-49fb-a2ab-dd6472829db7@github.com>

The fix for 8274296 added uiScale=1 to some of the tests to fix the problem of incorrect pixel color capture by the robot.
In both cases uiScale=1 or uiScale=2 the same call should be made to the macOS. But if uiScale=1 is set we just read one pixel on the screen, but if uiScale=2 is set we prepare the data in some clumsy way(at the end we should also read just one pixel).

Since uiScale=1 affects the test case execution means that we probably have some bugs in the coordinate/size calculation of the area. Note that none of these tests have dependencies on the precise rendering, so it is quite a common use-case and may affect any external applications.

This is a request to update the https://github.com/openjdk/jdk/pull/5687/files
and move all tests to the problem list.

-------------

Commit messages:
 - Initial version JDK-8274304

Changes: https://git.openjdk.java.net/jdk/pull/5766/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5766&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274304
  Stats: 16 lines in 9 files changed: 8 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5766.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5766/head:pull/5766

PR: https://git.openjdk.java.net/jdk/pull/5766


From philip.race at oracle.com  Thu Sep 30 22:35:35 2021
From: philip.race at oracle.com (Philip Race)
Date: Thu, 30 Sep 2021 15:35:35 -0700
Subject: HiDPI Fractional Scaling on Linux/GTK
In-Reply-To: <CAFJNjUeOVgr8Nmuwddh4faO2Wv3Q+s7s0P+dAUMyGBnRXAsCAA@mail.gmail.com>
References: <CAFJNjUeOVgr8Nmuwddh4faO2Wv3Q+s7s0P+dAUMyGBnRXAsCAA@mail.gmail.com>
Message-ID: <3f8bc376-d5de-441d-0cbf-900358ed3df2@oracle.com>

I don't have a succinct answer to your question without doing a bunch of 
research.
Probably start by just updating the code that forces it to be an int and 
see what breaks :-)
Maybe one of the folks who worked on it for windows could say what is 
missing but
I'd guess shared Swing code is probably going to be mostly OK since we 
do it for Windows
So it comes down to how much platform-specific code is needed and what 
are the difficult problems.
I think if it had been easy it would have been done, but possibly folks 
also ran out of
time and needed to focus on trying to finish most of Windows.

-phil.

On 9/29/21 5:23 AM, Matthew Wallace wrote:
> I'd like to use fractional scaling in my swing application on Linux (GTK).
> My application already works perfectly with fractional scaling on Windows
> (Java seems to abide by the system settings) but on Linux the system
> settings are ignored and setting GDK_SCALE only works for integer values.
> Could anyone familiar with this outline for me the work needed to support
> fractional scaling on Linux?  I'm willing to do some hacking to make this
> work, but I really have no idea where to start or if it's even feasible.
> Any help is greatly appreciated.



From serb at openjdk.java.net  Thu Sep 30 22:36:49 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 30 Sep 2021 22:36:49 GMT
Subject: RFR: 8225122: Test AncestorResized.java fails when Windows desktop is
 scaled.
Message-ID: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>

This test depends on the next windows UI performance option:
?Show window contents while dragging?, see https://answers.microsoft.com/en-us/windows/forum/all/in-windows-7-how-do-i-show-window-contents-while/18e3aee2-bcc7-4005-a45d-c5613cf6eb3c

In the default configuration, the windows may decide that the system is slow and this option should be disabled. I have found that this usually happens in the virtual environment.

When that option is disabled the resize events have come when the user completes the resize, before that the only border "rectangle" is moved.

This fix changes the test to release the mouse and complete the resize, and only after that checks the result.

Also, some old machinery is removed.

-------------

Commit messages:
 - Update AncestorResized.java

Changes: https://git.openjdk.java.net/jdk/pull/5711/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5711&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8225122
  Stats: 206 lines in 1 file changed: 5 ins; 178 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5711/head:pull/5711

PR: https://git.openjdk.java.net/jdk/pull/5711


From serb at openjdk.java.net  Thu Sep 30 22:36:50 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 30 Sep 2021 22:36:50 GMT
Subject: RFR: 8225122: Test AncestorResized.java fails when Windows
 desktop is scaled.
In-Reply-To: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
References: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
Message-ID: <hIEcJzrC1woTLGcUAc715JgVii_aZ17A4VVS3t3mcEU=.03e95295-f66c-4b27-aa7f-aac4025deaef@github.com>

On Mon, 27 Sep 2021 03:33:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This test depends on the next windows UI performance option:
> ?Show window contents while dragging?, see https://answers.microsoft.com/en-us/windows/forum/all/in-windows-7-how-do-i-show-window-contents-while/18e3aee2-bcc7-4005-a45d-c5613cf6eb3c
> 
> In the default configuration, the windows may decide that the system is slow and this option should be disabled. I have found that this usually happens in the virtual environment.
> 
> When that option is disabled the resize events have come when the user completes the resize, before that the only border "rectangle" is moved.
> 
> This fix changes the test to release the mouse and complete the resize, and only after that checks the result.
> 
> Also, some old machinery is removed.

test/jdk/java/awt/event/HierarchyEvent/AncestorResized/AncestorResized.java line 107:

> 105:         robot.mousePress( InputEvent.BUTTON1_MASK );
> 106:         robot.mouseMove(bounds.x + bounds.width + 20, bounds.y + bounds.height + 15);
> 107:         robot.mouseRelease(InputEvent.BUTTON1_MASK);

This is the actual change, mouseRelease is moved from the end of the test to the line above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5711


From philip.race at oracle.com  Thu Sep 30 22:39:52 2021
From: philip.race at oracle.com (Philip Race)
Date: Thu, 30 Sep 2021 15:39:52 -0700
Subject: One (client) list to rule them all
Message-ID: <5c5b7ca0-29a5-05e7-f0fe-86960b6c919d@oracle.com>

As per previous notice to this list [1],? the old 2d, awt, swing, beans 
and sound list
have been retired as of 12pm PDT today, 30th September. Their archives 
will remain available indefinitely.

All client-libs related discussions, notices, etc should be here from 
now on.

-Phil.

[1] 
https://mail.openjdk.java.net/pipermail/client-libs-dev/2021-September/000182.html


From philip.race at oracle.com  Thu Sep 30 23:03:39 2021
From: philip.race at oracle.com (Philip Race)
Date: Thu, 30 Sep 2021 16:03:39 -0700
Subject: CFV: New Client Libraries Group Member : Prasanta Sadhukhan
 (psadhukhan)
Message-ID: <37846e8d-9c3d-5050-bcf4-c8d096b19287@oracle.com>

I hereby nominate Prasanta Sadhukhan (psadhukhan) to Membership in the 
Client Libraries Group.

Prasanta has worked in the client team at Oracle since 2015 and in that 
time has contributed approximately 460 fixes [1], [2].
He has been active on the old client lists, awt-dev [3], swing-dev[4] 
and 2d-dev [5] mailing list over that time,
He is also a JDK committer and reviewer [6].

Votes are due by 5pm PDT Thursday 14th October 2021

//Only current Members of the Client Libraries Group [7] are eligible to 
vote on this nomination. ||
Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [8].

-Phil.

[1] git log --author psadhukhan --format='%h %s'
[2] 
https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Prasanta+Sadhukhan%22&type=commits
[3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
[4] https://mail.openjdk.java.net/mailman/listinfo/swing-dev
[5] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
[6] https://openjdk.java.net/census#psadhukhan
[7] https://openjdk.java.net/census#client-libs
[8] http://openjdk.java.net/groups/#member-vote 
<http://openjdk.java.net/groups/#member-vote%7C>


From philip.race at oracle.com  Thu Sep 30 23:03:42 2021
From: philip.race at oracle.com (Philip Race)
Date: Thu, 30 Sep 2021 16:03:42 -0700
Subject: CFV: New Client Libraries Group Member : Pankaj Bansal (pbansal)
Message-ID: <9bc8698b-35cc-1faa-4dac-e4c97f43254c@oracle.com>

I hereby nominate Pankaj Bansal (pbansal) to Membership in the Client 
Libraries Group.

Pankaj has worked in the client team at Oracle since 2017 and in that 
time has contributed approximately 70-80 fixes [1], [2].
He has been active on the old client lists, awt-dev [3], swing-dev[4] 
and 2d-dev [5] mailing list over that time,
He is also a JDK committer and reviewer [6].

Votes are due by 5pm PDT Thursday 14th October 2021

//Only current Members of the Client Libraries Group [7] are eligible to 
vote on this nomination. ||
Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [8].

[1] git log --author pbansal --format='%h %s'
[2] 
https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Pankaj+Bansal%22&type=commits
[3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
[4] https://mail.openjdk.java.net/mailman/listinfo/swing-dev
[5] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
[6] https://openjdk.java.net/census#pbansal
[7] https://openjdk.java.net/census#client-libs
[8] http://openjdk.java.net/groups/#member-vote 
<http://openjdk.java.net/groups/#member-vote%7C>