From github.com+28651297+mkartashev at openjdk.java.net  Thu Jul  1 09:57:05 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Thu, 1 Jul 2021 09:57:05 GMT
Subject: <AWT Dev> Integrated: 8267307: Introduce new client property for
 XAWT: xawt.mwm_decor_title
In-Reply-To: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
References: <j41NeS60bK0v2i5V016iYrUpjnfKYE2sOjbnelTlg0g=.7d62a29a-91c9-49b8-8e4d-9875c3e0b24b@github.com>
Message-ID: <U6wz-ymenUK4q5S-sxaW_8-ZQ7fowuGZJg2MARNdjc0=.4d200784-614c-4e61-b66f-813724d1a9d6@github.com>

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

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

This pull request has now been integrated.

Changeset: 18f356a3
Author:    Maxim Kartashev <maxim.kartashev at jetbrains.com>
Committer: Alexey Ushakov <avu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/18f356a38e834fc1a4b8f817a1f0b1b0cd66c915
Stats:     268 lines in 3 files changed: 262 ins; 4 del; 2 mod

8267307: Introduce new client property for XAWT: xawt.mwm_decor_title

Reviewed-by: azvegint, serb

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

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

From jdv at openjdk.java.net  Thu Jul  1 10:14:00 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 1 Jul 2021 10:14:00 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL [v2]
In-Reply-To: <uLTCX_HaIt0PVRv4psEvWUaVD6JevtuQ4puSuQaA8Q8=.df26bb2b-18bb-4952-8465-d7ec21aa8dd2@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <uLTCX_HaIt0PVRv4psEvWUaVD6JevtuQ4puSuQaA8Q8=.df26bb2b-18bb-4952-8465-d7ec21aa8dd2@github.com>
Message-ID: <ZjyWELQOiuuAxIIl3xcCTC2EzCPs_TnxT9yuenql7aQ=.7e88e00e-931c-4fba-aac5-ff710a30e481@github.com>

On Wed, 23 Jun 2021 12:15:03 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Keep MTLLayer opacity in sync with window content view

All test run is green with latest commit.

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

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

From serb at openjdk.java.net  Fri Jul  2 04:10:02 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 2 Jul 2021 04:10:02 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility
In-Reply-To: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
Message-ID: <fKS9tLd-Uvmo2iL6pE66BEEAHcpfS3whkPOv3kxOEtw=.c50b4863-66bd-4d3c-bda4-19e7e67a0adb@github.com>

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

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

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 260:

> 258:         (*env)->ExceptionClear(env); // in case of OOME
> 259:         jobject jcomponent = [(AWTView *)fView awtComponent:env];
> 260:         fComponent = (*env)->NewWeakGlobalRef(env, jcomponent);

What happens if "fAccessible" and "fComponent" will be null due to OOM, should we rethrow this exception, or ignoring it is fine?

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

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

From github.com+36081106+savoptik at openjdk.java.net  Fri Jul  2 12:45:25 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Fri, 2 Jul 2021 12:45:25 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility [v2]
In-Reply-To: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
Message-ID: <6j0d_4-6BRHlcDoGqYi5GwaCgbi3C7mF3a_R8u22644=.68bb35b5-8b69-4cfb-98ae-daf60d3bc353@github.com>

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

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

  Even on Linux? I meant if the test will be run on the platform where a11y is not implemented then this will be

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4412/files
  - new: https://git.openjdk.java.net/jdk/pull/4412/files/280ee5fe..e9b966b5

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

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

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

From github.com+36081106+savoptik at openjdk.java.net  Fri Jul  2 14:08:15 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Fri, 2 Jul 2021 14:08:15 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility [v2]
In-Reply-To: <dYKZksvBLTkm7S7Qos_6Hvq_CjRgJ92x3fBmgIXI980=.17c698f5-0643-4f6a-99f1-ae4c30785624@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
 <dYKZksvBLTkm7S7Qos_6Hvq_CjRgJ92x3fBmgIXI980=.17c698f5-0643-4f6a-99f1-ae4c30785624@github.com>
Message-ID: <otrg8vhXSycHYK0Ja98J90nWfPutDAp8oW7bPVOxAtg=.d1413cfd-3835-4292-86c5-2b3b67fa13a0@github.com>

On Wed, 16 Jun 2021 21:21:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Even on Linux? I meant if the test will be run on the platform where a11y is not implemented then this will be
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 130:
> 
>> 128:         if (c != null) {
>> 129:             try {
>> 130:                 value = EventQueue.isDispatchThread() ? callable.call() : LWCToolkit.invokeAndWait(callable, c);
> 
> When this method is called on EDT?

In the same class there is a getChildrenAndRolesRecursive () method that calls invokeAndWait (), inside it it calls itself and getChildrenAndRoles (), which also call invokeAndWait ().

> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.m line 79:
> 
>> 77:     if (values == NULL) {
>> 78:         // Note: Java will not be on the stack here so a java exception can't happen and no need to call ExceptionCheck.
>> 79:         NSLog(@"%s failed calling GetDoubleArrayElements", __FUNCTION__);
> 
> Please clarify the comment above.

This comment has been carried over from the legacy code. it is still relevant.

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

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

From avu at openjdk.java.net  Fri Jul  2 17:49:17 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 2 Jul 2021 17:49:17 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL [v3]
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <usmOxzkj1CF0pC-5Ow29otKIN83h0QWLtjJDbuA14x4=.f5f34034-7126-46c4-b73e-988aaa164bd6@github.com>

> Implemented blit via compute kernel

Alexey Ushakov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
  
  Keep MTLLayer opacity in sync with window content view

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/62/files
  - new: https://git.openjdk.java.net/jdk17/pull/62/files/3eef431e..361407b1

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

  Stats: 34 lines in 6 files changed: 28 ins; 5 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/62.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/62/head:pull/62

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

From serb at openjdk.java.net  Fri Jul  2 20:58:50 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 2 Jul 2021 20:58:50 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility [v2]
In-Reply-To: <otrg8vhXSycHYK0Ja98J90nWfPutDAp8oW7bPVOxAtg=.d1413cfd-3835-4292-86c5-2b3b67fa13a0@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
 <dYKZksvBLTkm7S7Qos_6Hvq_CjRgJ92x3fBmgIXI980=.17c698f5-0643-4f6a-99f1-ae4c30785624@github.com>
 <otrg8vhXSycHYK0Ja98J90nWfPutDAp8oW7bPVOxAtg=.d1413cfd-3835-4292-86c5-2b3b67fa13a0@github.com>
Message-ID: <trm-sT-m7ro2hrVACkQsHzDD81ndAF8EBsj9AwazbPc=.9619dec4-d79e-4300-973b-5dbaded684b1@github.com>

On Fri, 2 Jul 2021 14:05:40 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 130:
>> 
>>> 128:         if (c != null) {
>>> 129:             try {
>>> 130:                 value = EventQueue.isDispatchThread() ? callable.call() : LWCToolkit.invokeAndWait(callable, c);
>> 
>> When this method is called on EDT?
>
> In the same class there is a getChildrenAndRolesRecursive () method that calls invokeAndWait (), inside it it calls itself and getChildrenAndRoles (), which also call invokeAndWait ().

ok, so this is in the new code, how hard it will be to reimplement these methods to call invokeAndWait only once per callback from the native, as it usually was done before?

>> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.m line 79:
>> 
>>> 77:     if (values == NULL) {
>>> 78:         // Note: Java will not be on the stack here so a java exception can't happen and no need to call ExceptionCheck.
>>> 79:         NSLog(@"%s failed calling GetDoubleArrayElements", __FUNCTION__);
>> 
>> Please clarify the comment above.
>
> This comment has been carried over from the legacy code. it is still relevant.

The comment states that it is not necessary to call ExceptionCheck, but it will be done before by the CHECK_EXCEPTION. The macro also will log it when necessary.

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

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

From pbansal at openjdk.java.net  Sun Jul  4 14:08:01 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sun, 4 Jul 2021 14:08:01 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility [v2]
In-Reply-To: <6j0d_4-6BRHlcDoGqYi5GwaCgbi3C7mF3a_R8u22644=.68bb35b5-8b69-4cfb-98ae-daf60d3bc353@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
 <6j0d_4-6BRHlcDoGqYi5GwaCgbi3C7mF3a_R8u22644=.68bb35b5-8b69-4cfb-98ae-daf60d3bc353@github.com>
Message-ID: <WgWO8f_n5i7XofCXlkYIDnGpy_hgUEvZXnR9ST3Of84=.5a8204f8-ea74-4f31-a337-8c90f6045483@github.com>

On Fri, 2 Jul 2021 12:45:25 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility
>> This pull request contains solutions for the following tickets:
>> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility;
>> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol;
>> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer;
>> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer;
>> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer;
>> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol;
>> * JDK-8267388 Create implementation for NSAccessibilityTable protocol.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Even on Linux? I meant if the test will be run on the platform where a11y is not implemented then this will be

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

> 26:  * @test
> 27:  * @bug 8264287
> 28:  * @summary Create implementation for NSAccessibilityComboBox protocol peer

Summary should be something like "Test implementation of NSAccessibilityComboBox protocol peer" or "Test Combobox accessibility"

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

> 33: 
> 34: import javax.swing.*;
> 35: import java.awt.*;

Wildcard imports are avoided in new tests

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

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

From aghaisas at openjdk.java.net  Mon Jul  5 05:56:52 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 5 Jul 2021 05:56:52 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL [v3]
In-Reply-To: <usmOxzkj1CF0pC-5Ow29otKIN83h0QWLtjJDbuA14x4=.f5f34034-7126-46c4-b73e-988aaa164bd6@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <usmOxzkj1CF0pC-5Ow29otKIN83h0QWLtjJDbuA14x4=.f5f34034-7126-46c4-b73e-988aaa164bd6@github.com>
Message-ID: <2l3cbAuO_7J82qboQR3gs_mK7Q80KT5Cc14iyB864kY=.d1986bad-1d4e-4de7-8589-7c1c4989cf3b@github.com>

On Fri, 2 Jul 2021 17:49:17 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Keep MTLLayer opacity in sync with window content view

The latest version of this PR re-introduces [JDK-8243547](https://bugs.openjdk.java.net/browse/JDK-8243547)

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

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

From avu at openjdk.java.net  Mon Jul  5 08:08:52 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 5 Jul 2021 08:08:52 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL [v3]
In-Reply-To: <2l3cbAuO_7J82qboQR3gs_mK7Q80KT5Cc14iyB864kY=.d1986bad-1d4e-4de7-8589-7c1c4989cf3b@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <usmOxzkj1CF0pC-5Ow29otKIN83h0QWLtjJDbuA14x4=.f5f34034-7126-46c4-b73e-988aaa164bd6@github.com>
 <2l3cbAuO_7J82qboQR3gs_mK7Q80KT5Cc14iyB864kY=.d1986bad-1d4e-4de7-8589-7c1c4989cf3b@github.com>
Message-ID: <9kKVMXqbcVL_cDr0cVZJEg8Nykpm-criK7deO-goUzo=.8d66ee8c-2a1c-4c20-8e90-277c494f7aa8@github.com>

On Mon, 5 Jul 2021 05:54:07 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> The latest version of this PR re-introduces JDK-8243547

 rechecked with the previous version, still reproducible.

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

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

From avu at openjdk.java.net  Mon Jul  5 15:41:34 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 5 Jul 2021 15:41:34 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL [v4]
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <MqoXmj-zcOvIRpirWTm9m4PkT03unpRNO1zXHIlKG-0=.b4974fd7-0e6a-40e0-aeba-954616e02297@github.com>

> Implemented blit via compute kernel

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

  8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
  
  Keep layer translucent for translucent windows

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/62/files
  - new: https://git.openjdk.java.net/jdk17/pull/62/files/361407b1..e61914d3

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

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

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

From avu at openjdk.java.net  Mon Jul  5 15:55:20 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 5 Jul 2021 15:55:20 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL [v4]
In-Reply-To: <MqoXmj-zcOvIRpirWTm9m4PkT03unpRNO1zXHIlKG-0=.b4974fd7-0e6a-40e0-aeba-954616e02297@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <MqoXmj-zcOvIRpirWTm9m4PkT03unpRNO1zXHIlKG-0=.b4974fd7-0e6a-40e0-aeba-954616e02297@github.com>
Message-ID: <oa7B9Y9uBU8nFB43O2jy_xpL9kBWD9H9VCYp38zOZ8Q=.6dcce6dc-a267-438f-973f-1b93e0e83356@github.com>

On Mon, 5 Jul 2021 15:41:34 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Keep layer translucent for translucent windows

> don't we need to do something like [mtlLayer setOpaque:(opaque == JNI_TRUE)]?

Done

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

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

From avu at openjdk.java.net  Mon Jul  5 15:55:20 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 5 Jul 2021 15:55:20 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL [v5]
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <pppqA2YSjwiNvZPnUOul1cXtmDA_w0kgxkfv6rvV87A=.18e56cea-d453-4e6d-b87b-15fd696c3ea0@github.com>

> Implemented blit via compute kernel

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

  8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
  
  Minor cleanup

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/62/files
  - new: https://git.openjdk.java.net/jdk17/pull/62/files/e61914d3..cb4cf04c

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

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

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

From avu at openjdk.java.net  Mon Jul  5 15:55:21 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 5 Jul 2021 15:55:21 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL [v3]
In-Reply-To: <2l3cbAuO_7J82qboQR3gs_mK7Q80KT5Cc14iyB864kY=.d1986bad-1d4e-4de7-8589-7c1c4989cf3b@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <usmOxzkj1CF0pC-5Ow29otKIN83h0QWLtjJDbuA14x4=.f5f34034-7126-46c4-b73e-988aaa164bd6@github.com>
 <2l3cbAuO_7J82qboQR3gs_mK7Q80KT5Cc14iyB864kY=.d1986bad-1d4e-4de7-8589-7c1c4989cf3b@github.com>
Message-ID: <8vWOzbaaoF3324zsU95c3yLDWF_stflCN9wuK3438Fo=.c4cb5afd-b7f1-41bc-b478-bf300ccc5856@github.com>

On Mon, 5 Jul 2021 05:54:07 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> The latest version of this PR re-introduces [JDK-8243547](https://bugs.openjdk.java.net/browse/JDK-8243547)

Fixed

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

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

From avu at openjdk.java.net  Mon Jul  5 15:55:27 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 5 Jul 2021 15:55:27 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL [v2]
In-Reply-To: <_ckINhzlkfObwA0ncLZCaoFzWItgZUyR-4Bg3evQYME=.890f1ed7-d977-4f2a-9125-3a0fef580440@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <uLTCX_HaIt0PVRv4psEvWUaVD6JevtuQ4puSuQaA8Q8=.df26bb2b-18bb-4952-8465-d7ec21aa8dd2@github.com>
 <_ckINhzlkfObwA0ncLZCaoFzWItgZUyR-4Bg3evQYME=.890f1ed7-d977-4f2a-9125-3a0fef580440@github.com>
Message-ID: <rB8FFOVtzZUczob8DQVH-HVe3W69QjSYbTj3yUAZBds=.33505856-59c6-421d-bb6f-703556c19ce9@github.com>

On Mon, 28 Jun 2021 22:45:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexey Ushakov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/CWrapper.m line 349:
> 
>> 347:         if ([window.contentView.layer isKindOfClass:[CAMetalLayer class]]) {
>> 348:             [window.contentView.layer setOpaque:(BOOL)opaque];
>> 349:         }
> 
> This class "CWrapper" is intended to be a simple wrapper on top of cocoa methods, the changed method above is expected to call the "NSWindow#setOpaque" only. So you need to place "window.contentView.layer setOpaque" in some other place(native or java).

Done

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

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

From serb at openjdk.java.net  Mon Jul  5 17:57:49 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 5 Jul 2021 17:57:49 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL [v5]
In-Reply-To: <pppqA2YSjwiNvZPnUOul1cXtmDA_w0kgxkfv6rvV87A=.18e56cea-d453-4e6d-b87b-15fd696c3ea0@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <pppqA2YSjwiNvZPnUOul1cXtmDA_w0kgxkfv6rvV87A=.18e56cea-d453-4e6d-b87b-15fd696c3ea0@github.com>
Message-ID: <7wK3b4pEuQEqbhbfOVbuev54tk0GrPG0x-wbGlFLQeo=.23d33a05-7b43-49f1-947b-463a68d29918@github.com>

On Mon, 5 Jul 2021 15:55:20 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Minor cleanup

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

> 338:         if (!isTranslucent) {
> 339:             contentView.setWindowLayerOpaque(true);
> 340:         }

I think windowLayer should be always in sync with NSWindowOpaque state. And both should be changed together via setOpaque() method.

The change above will call the "setWindowLayerOpaque" twice:
 - LWWindowPeer()->platformWindow.initialize()->contentView.setWindowLayerOpaque(true)
 - LWWindowPeer()->initializeImpl()->setOpaque()->contentView.setWindowLayerOpaque()

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

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

From pbansal at openjdk.java.net  Tue Jul  6 10:46:52 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 6 Jul 2021 10:46:52 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility [v2]
In-Reply-To: <6j0d_4-6BRHlcDoGqYi5GwaCgbi3C7mF3a_R8u22644=.68bb35b5-8b69-4cfb-98ae-daf60d3bc353@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
 <6j0d_4-6BRHlcDoGqYi5GwaCgbi3C7mF3a_R8u22644=.68bb35b5-8b69-4cfb-98ae-daf60d3bc353@github.com>
Message-ID: <zAyRGs5iWyx-JdPSzO-qPpRYQ5PnPPETeqgdAP1fz5Q=.602c6b10-fa5e-4d31-9018-b6817e2054f2@github.com>

On Fri, 2 Jul 2021 12:45:25 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility
>> This pull request contains solutions for the following tickets:
>> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility;
>> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol;
>> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer;
>> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer;
>> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer;
>> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol;
>> * JDK-8267388 Create implementation for NSAccessibilityTable protocol.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Even on Linux? I meant if the test will be run on the platform where a11y is not implemented then this will be

I tested the NavigableStaticTextAccessibility functionality for TextFields, TaxtPane and PasswordField.  It works fine and I don't see any issue in VO output with this change.

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

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

From aghaisas at openjdk.java.net  Wed Jul  7 10:49:55 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 7 Jul 2021 10:49:55 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL [v5]
In-Reply-To: <pppqA2YSjwiNvZPnUOul1cXtmDA_w0kgxkfv6rvV87A=.18e56cea-d453-4e6d-b87b-15fd696c3ea0@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <pppqA2YSjwiNvZPnUOul1cXtmDA_w0kgxkfv6rvV87A=.18e56cea-d453-4e6d-b87b-15fd696c3ea0@github.com>
Message-ID: <vccLw8XMJDmnAzWHwcOBI98x9BeBY81E0ifPo5nrhtI=.517bdafa-1c7e-40d8-8b61-d80fcf7ad374@github.com>

On Mon, 5 Jul 2021 15:55:20 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Minor cleanup

I verified that the latest version does not re-introduce JDK-8243547.
All automated test run is also green with this version.

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

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

From pbansal at openjdk.java.net  Wed Jul  7 11:25:52 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 7 Jul 2021 11:25:52 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility [v2]
In-Reply-To: <DFe4h-ztl4BnHaItVfvImpBeDItCLgKDl5OMYNJSlYM=.86889536-35ad-41e3-94a5-0c9ec7578336@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
 <4CZCGYIDcZlVhckVi87sZpwUATr3w9yT_7o5eBD1s5U=.1b564e7b-7861-486a-a53e-7ff04084e994@github.com>
 <DFe4h-ztl4BnHaItVfvImpBeDItCLgKDl5OMYNJSlYM=.86889536-35ad-41e3-94a5-0c9ec7578336@github.com>
Message-ID: <tvJ7Xmb4ubHIAor5vwa9GsP0RYq5OatCuVrfmtYATkY=.36b22b34-b48e-413c-9ee6-26083f79875e@github.com>

On Tue, 29 Jun 2021 15:00:41 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m line 372:
>> 
>>> 370:     if ([javaRole isEqualToString:@"pagetablist"]) {
>>> 371:         newChild = [TabGroupLegacyAccessibility alloc];
>>> 372:     } else if ([javaRole isEqualToString:@"table"]) {
>> 
>> Do we even need legacy peer implementation in the new classes?
>
> The new TabGroup is also named TabGroupAccessibility, so as not to get out of the naming, the old class is renamed for this, otherwise the building will fail.

But when are these Legacy classes used? The "pagetablist" and "table" roles are being handled in commonComponentAccessibility and new implementation classes will be used there. Why can't we just remove these legacy classes and any references to them, instead of renaming them

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

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

From philip.race at oracle.com  Wed Jul  7 13:58:01 2021
From: philip.race at oracle.com (Philip Race)
Date: Wed, 7 Jul 2021 06:58:01 -0700
Subject: <AWT Dev> FYI: A CFD for a Wayland project has been posted to
 discuss@openjdk.java.net
Message-ID: <e3beaf45-3034-438c-cf45-6e22d2527a5f@oracle.com>

https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html

-phil.

From alexander.zvegintsev at oracle.com  Wed Jul  7 21:52:21 2021
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 7 Jul 2021 23:52:21 +0200
Subject: <AWT Dev> Call for Discussion : New Project to support the
 Wayland display server on Linux
In-Reply-To: <da2fb186-7315-226a-a47a-10ecee46bf65@oracle.com>
References: <31d8ebcf-6c63-fdb9-e8e8-88573975dd2f@oracle.com>
 <da2fb186-7315-226a-a47a-10ecee46bf65@oracle.com>
Message-ID: <ea31b482-b0d9-ef65-3f70-5cae6e3852cf@oracle.com>

(adding awt-dev)

Let me add a few comments.

> already Wayland is the default on RHEL 8, OL 8, Ubuntu 21.04 and I am 
> sure others too. 
It is the default, but not in every case. Wayland may be turned off 
deliberately if you are using a Nvidia graphics card, so you need to 
take extra steps to get it working 
<https://askubuntu.com/questions/1334825/what-are-the-steps-to-run-wayland-on-21-04-with-optimus-nvidia>.

I faced this issue on Ubuntu 21.04.

However things getting better 
<https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-470-Wayland-Friendly>with 
Nvidia 470 drivers, its beta released 
<https://www.nvidia.com/download/driverResults.aspx/176525/en-us> on 
2021.6.22. So probably it won't be a problem in the near future.

> Consequently we expect quite shortly to propose an OpenJDK project 
> that will consider the goals of
> - a short to medium term solution for JDK running on Wayland in X11 
> compatibility mode
> - a medium to long term solution for JDK running as a native Wayland 
> client. 

Both goals having a common task: we will need to implement 
java.awt.Robot functionality for Wayland(at least).

So it makes sense to make XToolkit's java.awt.Robot work under Wayland 
first, and then reuse this code for native Wayland client.

I see two major tasks here: taking screenshots and mouse/keyboard 
control. As far as I know there is no standard way to implement they 
across all display servers yet.

Possible ways to implement this:

  * taking screenshot:
      o open issue against Wayland, may be resolved
        someday:https://gitlab.freedesktop.org/wayland/wayland/-/issues/32
        <https://gitlab.freedesktop.org/wayland/wayland/-/issues/32>
      o https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot
        <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot>
      o via DBUS interface(display server dependent),
        e.g.https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43
        <https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43>
  * generating key/mouse events:
      o https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.RemoteDesktop
        <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.RemoteDesktop>
      o generating new virtual input device, uinput, superuser
        privileges required, looks too flaky
        https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse
        <https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse>

This still need more investigation, butxdg-desktop-portal 
<https://github.com/flatpak/xdg-desktop-portal>looks more preferable way 
for now.


Please see below some caveats for OpenJDK native Wayland client:

You can't control a position for a top-level window. 
<https://gitlab.freedesktop.org/wayland/wayland/-/issues/183>

This will also affect a splashscreen windows. It is still possible to 
control position under XWayland though.

Looks like we will just accept it.


Top-level window decorations.

Initially Wayland had only client-side decorations(you have to draw it 
by yourself).

As of now server-side decorations are available by XDG-Decoration 
protocol <https://gitlab.gnome.org/GNOME/mutter/-/issues/217>.

However server-side window decorations are not mandatory and not all 
compositors are supporting it, e.g. Mutter(Gnome Shell's compositor).

Gnome Shell is the default on Ubuntu, so we will need to provide window 
decorations somehow. One of possible solutions is to use Gtk to create a 
window for us.


--
Thanks,
Alexander.

On 7/7/21 6:24 AM, Philip Race wrote:
>
> For a number of years the Linux community has been working on a 
> complete replacement for the 1980's era X11 desktop display server 
> protocol
> with new protocols and libraries that support client-side rendering 
> and a compositing desktop windowing system.
> This work is being done under the auspices of the Wayland project [1] 
> and there is a reference
> implementation of a Wayland compositor called "Weston".
>
> A new client written for? the Wayland desktop has no dependency at all 
> on X11, but Wayland also provides a compatibility
> mode where the X.org X11 server runs along side Wayland, so that 
> thousands of X11 applications can continue to run.
>
> Presently all distros that ship the Wayland server, also still ship 
> the pure X11 server and the user can select
> which one to use on the login screen. However there will come a time 
> when Wayland is the only choice and
> already Wayland is the default on RHEL 8, OL 8, Ubuntu 21.04 and I am 
> sure others too.
>
> At that time Java for Linux will "mostly" run via the X11 
> compatibility layer, but would not pass the JCK,
> since some important APIs,? notably those of the java.awt.Robot class 
> [2] will fail with Wayland.
> We need to solve this so that pure Java and applications which mix 
> Java and X11 APis can work.
>
> But even then this would mean Java on Linux is not a first class 
> desktop citizen, which is not desirable for
> the long term, given the importance of Linux to many Java developers 
> as well as to active
> individual and corporate contributors to the JDK project.
>
> Indeed there have already been informal discussions for some time with 
> various parties that have expressed
> interest in helping towards the outcome of supporting Wayland
>
> Consequently we expect quite shortly to propose an OpenJDK project 
> that will consider the goals of
> - a short to medium term solution for JDK running on Wayland in X11 
> compatibility mode
> - a medium to long term solution for JDK running as a native Wayland 
> client.
>
> There are some unknowns and questions, such as what are the options 
> for supporting Robot ?
> What other support is missing ? What platform APIs should the 
> implementation? use ?
> How does a native Wayland solution interoperate with OpenJFX ?
>
>
> Comments, expressions of interest etc are welcome.
>
>
> -Phil Race, for the Java client groups.
>
>
> [1] : https://wayland.freedesktop.org/
> [2] : 
> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Robot.html 

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

From alexey.ushakov at jetbrains.com  Thu Jul  8 06:29:44 2021
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Thu, 8 Jul 2021 09:29:44 +0300
Subject: <AWT Dev> Call for Discussion : New Project to support the
 Wayland display server on Linux
In-Reply-To: <ea31b482-b0d9-ef65-3f70-5cae6e3852cf@oracle.com>
References: <31d8ebcf-6c63-fdb9-e8e8-88573975dd2f@oracle.com>
 <da2fb186-7315-226a-a47a-10ecee46bf65@oracle.com>
 <ea31b482-b0d9-ef65-3f70-5cae6e3852cf@oracle.com>
Message-ID: <90520246-196C-4ADA-AB73-1C3B5C9606E9@jetbrains.com>

Hi,

> Possible ways to implement this:
> 
> taking screenshot:
> open issue against Wayland, may be resolved someday: https://gitlab.freedesktop.org/wayland/wayland/-/issues/32 <https://gitlab.freedesktop.org/wayland/wayland/-/issues/32>
> https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot>
> via DBUS interface(display server dependent), e.g. https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43 <https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43>

I?ve already did an implementation of AWT Robot via DBUS interface. It works well for single snapshot but if you need to implement something like color picker (you need to obtain Color many times per second) this approach severely slows things down.

Best Regards,
Alexey 

> On 8 Jul 2021, at 00:52, Alexander Zvegintsev <alexander.zvegintsev at oracle.com> wrote:
> 
> (adding awt-dev)
> 
> Let me add a few comments.
> 
>> already Wayland is the default on RHEL 8, OL 8, Ubuntu 21.04 and I am sure others too.
> It is the default, but not in every case. Wayland may be turned off deliberately if you are using a Nvidia graphics card, so you need to take extra steps to get it working <https://askubuntu.com/questions/1334825/what-are-the-steps-to-run-wayland-on-21-04-with-optimus-nvidia>.
> 
> I faced this issue on Ubuntu 21.04. 
> 
> However things getting better  <https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-470-Wayland-Friendly>with Nvidia 470 drivers, its beta released <https://www.nvidia.com/download/driverResults.aspx/176525/en-us> on 2021.6.22. So probably it won't be a problem in the near future.
> 
>> Consequently we expect quite shortly to propose an OpenJDK project that will consider the goals of 
>> - a short to medium term solution for JDK running on Wayland in X11 compatibility mode 
>> - a medium to long term solution for JDK running as a native Wayland client.
> 
> Both goals having a common task: we will need to implement java.awt.Robot functionality for Wayland(at least).
> 
> So it makes sense to make XToolkit's java.awt.Robot work under Wayland first, and then reuse this code for native Wayland client.
> 
> I see two major tasks here: taking screenshots and mouse/keyboard control. As far as I know there is no standard way to implement they across all display servers yet.
> 
> Possible ways to implement this:
> 
> taking screenshot:
> open issue against Wayland, may be resolved someday: https://gitlab.freedesktop.org/wayland/wayland/-/issues/32 <https://gitlab.freedesktop.org/wayland/wayland/-/issues/32>
> https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot>
> via DBUS interface(display server dependent), e.g. https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43 <https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43>
> generating key/mouse events:
> https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.RemoteDesktop <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.RemoteDesktop>
> generating new virtual input device, uinput, superuser privileges required, looks too flaky https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse <https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse>
> This still need more investigation, but xdg-desktop-portal <https://github.com/flatpak/xdg-desktop-portal> looks more preferable way for now.
> 
> 
> 
> Please see below some caveats for OpenJDK native Wayland client:
> 
> You can't control a position for a top-level window. <https://gitlab.freedesktop.org/wayland/wayland/-/issues/183> 
> 
> This will also affect a splashscreen windows. It is still possible to control position under XWayland though.
> 
> Looks like we will just accept it.
> 
> 
> 
> Top-level window decorations. 
> 
> Initially Wayland had only client-side decorations(you have to draw it by yourself).
> 
> As of now server-side decorations are available by XDG-Decoration protocol <https://gitlab.gnome.org/GNOME/mutter/-/issues/217>.
> 
> However server-side window decorations are not mandatory and not all compositors are supporting it, e.g. Mutter(Gnome Shell's compositor).
> 
> Gnome Shell is the default on Ubuntu, so we will need to provide window decorations somehow. One of possible solutions is to use Gtk to create a window for us.
> 
> 
> 
> --
> Thanks,
> Alexander.
> On 7/7/21 6:24 AM, Philip Race wrote: 
>> 
>> For a number of years the Linux community has been working on a complete replacement for the 1980's era X11 desktop display server protocol 
>> with new protocols and libraries that support client-side rendering and a compositing desktop windowing system. 
>> This work is being done under the auspices of the Wayland project [1] and there is a reference 
>> implementation of a Wayland compositor called "Weston". 
>> 
>> A new client written for  the Wayland desktop has no dependency at all on X11, but Wayland also provides a compatibility 
>> mode where the X.org X11 server runs along side Wayland, so that thousands of X11 applications can continue to run. 
>> 
>> Presently all distros that ship the Wayland server, also still ship the pure X11 server and the user can select 
>> which one to use on the login screen. However there will come a time when Wayland is the only choice and 
>> already Wayland is the default on RHEL 8, OL 8, Ubuntu 21.04 and I am sure others too. 
>> 
>> At that time Java for Linux will "mostly" run via the X11 compatibility layer, but would not pass the JCK, 
>> since some important APIs,  notably those of the java.awt.Robot class [2] will fail with Wayland. 
>> We need to solve this so that pure Java and applications which mix Java and X11 APis can work. 
>> 
>> But even then this would mean Java on Linux is not a first class desktop citizen, which is not desirable for 
>> the long term, given the importance of Linux to many Java developers as well as to active 
>> individual and corporate contributors to the JDK project. 
>> 
>> Indeed there have already been informal discussions for some time with various parties that have expressed 
>> interest in helping towards the outcome of supporting Wayland 
>> 
>> Consequently we expect quite shortly to propose an OpenJDK project that will consider the goals of 
>> - a short to medium term solution for JDK running on Wayland in X11 compatibility mode 
>> - a medium to long term solution for JDK running as a native Wayland client. 
>> 
>> There are some unknowns and questions, such as what are the options for supporting Robot ? 
>> What other support is missing ? What platform APIs should the implementation  use ? 
>> How does a native Wayland solution interoperate with OpenJFX ? 
>> 
>> 
>> Comments, expressions of interest etc are welcome. 
>> 
>> 
>> -Phil Race, for the Java client groups. 
>> 
>> 
>> [1] : https://wayland.freedesktop.org/ <https://wayland.freedesktop.org/> 
>> [2] : https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Robot.html <https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Robot.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210708/3ce70e16/attachment.htm>

From yyang at openjdk.java.net  Thu Jul  8 08:41:02 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 8 Jul 2021 08:41:02 GMT
Subject: <AWT Dev> RFR: 8270058: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.desktop
Message-ID: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>

After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

As Mandy suggested, I create this PR for changes involving client code:

src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java
src/java.desktop/share/classes/javax/swing/JTabbedPane.java
test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
test/jdk/javax/imageio/AppletResourceTest.java
test/jdk/javax/imageio/ImageReaderReadAll.java
test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java

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

Commit messages:
 - replace

Changes: https://git.openjdk.java.net/jdk/pull/4718/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4718&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270058
  Stats: 43 lines in 6 files changed: 7 ins; 21 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4718.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4718/head:pull/4718

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  8 09:37:18 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, 8 Jul 2021 09:37:18 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v9]
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <hwghF042fNQbpp7FJQGcySNsRa_koP8n9gsndheJ0Ys=.d6e86f3f-1170-47fb-aa98-46feb1f3e61a@github.com>

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

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

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

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4309/files
  - new: https://git.openjdk.java.net/jdk/pull/4309/files/4ec7c829..a72a09b6

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

  Stats: 23569 lines in 424 files changed: 8574 ins; 13030 del; 1965 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309

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

From alexey.ushakov at jetbrains.com  Thu Jul  8 12:36:04 2021
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Thu, 8 Jul 2021 15:36:04 +0300
Subject: <AWT Dev> FYI: A CFD for a Wayland project has been posted to
 discuss@openjdk.java.net
In-Reply-To: <e3beaf45-3034-438c-cf45-6e22d2527a5f@oracle.com>
References: <e3beaf45-3034-438c-cf45-6e22d2527a5f@oracle.com>
Message-ID: <49067D2A-A1F4-4D14-8330-7030810DC722@jetbrains.com>

> What other support is missing ? What platform APIs should the 
implementation  use ?
Currently we use XRender extension for many advanced operations in Java2D. Obviously it?s not available for pure Wayland apps. The only alternative for the moment is to use OpenGL pipeline. We can use it as mid term solution but for the long term we need to replace this outdated pipeline with something new. For example, we can use Vulkan api for more advanced rendering. Our recent effort to support Metal on Mac shows that current 2d architecture capable to support pipelines based on such advanced low level apis as Metal. Metal is quite similar to Vulkan.

Best Regards,
Alexey

> On 7 Jul 2021, at 16:58, Philip Race <philip.race at oracle.com> wrote:
> 
> https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> 
> -phil.

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

From pbansal at openjdk.java.net  Thu Jul  8 15:16:56 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 8 Jul 2021 15:16:56 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility [v2]
In-Reply-To: <6j0d_4-6BRHlcDoGqYi5GwaCgbi3C7mF3a_R8u22644=.68bb35b5-8b69-4cfb-98ae-daf60d3bc353@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
 <6j0d_4-6BRHlcDoGqYi5GwaCgbi3C7mF3a_R8u22644=.68bb35b5-8b69-4cfb-98ae-daf60d3bc353@github.com>
Message-ID: <y_0kZnyE9ducQvKNqUrge1JA9kp27Vqdhm9g0LTLIFc=.8f8b1706-63c4-4c20-8ee7-617685f8fa01@github.com>

On Fri, 2 Jul 2021 12:45:25 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility
>> This pull request contains solutions for the following tickets:
>> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility;
>> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol;
>> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer;
>> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer;
>> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer;
>> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol;
>> * JDK-8267388 Create implementation for NSAccessibilityTable protocol.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Even on Linux? I meant if the test will be run on the platform where a11y is not implemented then this will be

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 796:

> 794:     CHECK_EXCEPTION();
> 795:     if (!value) {
> 796:         NSLog(@"WARNING: %s called on component that has no accessible component: %@", __FUNCTION__, self);

I see this warning being thrown when trying to use the disabled slider. If we run SwingSet2 and go to Slider demo. Try to navigate to disabled sliders using the VO keys. This warning is thrown when the VO focus is shifted to disabled sliders. I don't see similar warning before this change. This is the warning I see

" WARNING: -[CommonComponentAccessibility isAccessibilityEnabled] called on component that has no accessible component: <SliderAccessibility: 0x7fc938147c00>"

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

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

From neugens at redhat.com  Thu Jul  8 16:11:01 2021
From: neugens at redhat.com (Mario Torre)
Date: Thu, 8 Jul 2021 18:11:01 +0200
Subject: <AWT Dev> Call for Discussion : New Project to support the
 Wayland display server on Linux
In-Reply-To: <ea31b482-b0d9-ef65-3f70-5cae6e3852cf@oracle.com>
References: <31d8ebcf-6c63-fdb9-e8e8-88573975dd2f@oracle.com>
 <da2fb186-7315-226a-a47a-10ecee46bf65@oracle.com>
 <ea31b482-b0d9-ef65-3f70-5cae6e3852cf@oracle.com>
Message-ID: <CAJwKKmYT8i1d28csxRJ1oCn4RAX3JJHnNY4p1ZQBpyfUE5BbUg@mail.gmail.com>

[resending with hopefully the correct email address as I have
completely lost which mailing list I'm subscribed to with which
email!!!]

I tend to agree with this, we certainly need to identify the
underlying APIs that are problematic (screenshot and mouse/keyboard
control as far as I am aware), then see what we can do from there, and
I would like to first address the XWayland use case before turning
into a fully fledged new toolkit implementation (but I agree with Phil
that this is the long term necessity).

What I would like to do however is to see if it makes sense to create
a GTK toolkit rather than a Wayland one, and let GTK deal with every
abstraction. We can be pretty confident that GTK will always be there,
and will work on X11 and Wayland transparently, so even a user on a
pure KDE desktop won?t really need to deal directly with Wayland.

Ideally, users with pure KDE distributions (OpenSuSE maybe?) may help
here analyse what the requirements are. One problem that comes to mind
when using GTK as a toolkit is the interaction with other GTK based
applications that may be embedded, i.e. Swing views in Eclipse,
Firefox based web views, etc.. etc? But I think this is already today
an issue and is dealt with in the current 2d and JFX code already.

Cheers,
Mario

On Wed, Jul 7, 2021 at 11:56 PM Alexander Zvegintsev
<alexander.zvegintsev at oracle.com> wrote:
>
> (adding awt-dev)
>
> Let me add a few comments.
>
> > already Wayland is the default on RHEL 8, OL 8, Ubuntu 21.04 and I am
> > sure others too.
> It is the default, but not in every case. Wayland may be turned off
> deliberately if you are using a Nvidia graphics card, so you need to
> take extra steps to get it working
> <https://askubuntu.com/questions/1334825/what-are-the-steps-to-run-wayland-on-21-04-with-optimus-nvidia>.
>
> I faced this issue on Ubuntu 21.04.
>
> However things getting better
> <https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-470-Wayland-Friendly>with
> Nvidia 470 drivers, its beta released
> <https://www.nvidia.com/download/driverResults.aspx/176525/en-us> on
> 2021.6.22. So probably it won't be a problem in the near future.
>
> > Consequently we expect quite shortly to propose an OpenJDK project
> > that will consider the goals of
> > - a short to medium term solution for JDK running on Wayland in X11
> > compatibility mode
> > - a medium to long term solution for JDK running as a native Wayland
> > client.
>
> Both goals having a common task: we will need to implement
> java.awt.Robot functionality for Wayland(at least).
>
> So it makes sense to make XToolkit's java.awt.Robot work under Wayland
> first, and then reuse this code for native Wayland client.
>
> I see two major tasks here: taking screenshots and mouse/keyboard
> control. As far as I know there is no standard way to implement they
> across all display servers yet.
>
> Possible ways to implement this:
>
>   * taking screenshot:
>       o open issue against Wayland, may be resolved
>         someday:https://gitlab.freedesktop.org/wayland/wayland/-/issues/32
>         <https://gitlab.freedesktop.org/wayland/wayland/-/issues/32>
>       o https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot
>         <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot>
>       o via DBUS interface(display server dependent),
>         e.g.https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43
>         <https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43>
>   * generating key/mouse events:
>       o https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.RemoteDesktop
>         <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.RemoteDesktop>
>       o generating new virtual input device, uinput, superuser
>         privileges required, looks too flaky
>         https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse
>         <https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse>
>
> This still need more investigation, butxdg-desktop-portal
> <https://github.com/flatpak/xdg-desktop-portal>looks more preferable way
> for now.
>
>
> Please see below some caveats for OpenJDK native Wayland client:
>
> You can't control a position for a top-level window.
> <https://gitlab.freedesktop.org/wayland/wayland/-/issues/183>
>
> This will also affect a splashscreen windows. It is still possible to
> control position under XWayland though.
>
> Looks like we will just accept it.
>
>
> Top-level window decorations.
>
> Initially Wayland had only client-side decorations(you have to draw it
> by yourself).
>
> As of now server-side decorations are available by XDG-Decoration
> protocol <https://gitlab.gnome.org/GNOME/mutter/-/issues/217>.
>
> However server-side window decorations are not mandatory and not all
> compositors are supporting it, e.g. Mutter(Gnome Shell's compositor).
>
> Gnome Shell is the default on Ubuntu, so we will need to provide window
> decorations somehow. One of possible solutions is to use Gtk to create a
> window for us.
>
>
> --
> Thanks,
> Alexander.
>
> On 7/7/21 6:24 AM, Philip Race wrote:
> >
> > For a number of years the Linux community has been working on a
> > complete replacement for the 1980's era X11 desktop display server
> > protocol
> > with new protocols and libraries that support client-side rendering
> > and a compositing desktop windowing system.
> > This work is being done under the auspices of the Wayland project [1]
> > and there is a reference
> > implementation of a Wayland compositor called "Weston".
> >
> > A new client written for  the Wayland desktop has no dependency at all
> > on X11, but Wayland also provides a compatibility
> > mode where the X.org X11 server runs along side Wayland, so that
> > thousands of X11 applications can continue to run.
> >
> > Presently all distros that ship the Wayland server, also still ship
> > the pure X11 server and the user can select
> > which one to use on the login screen. However there will come a time
> > when Wayland is the only choice and
> > already Wayland is the default on RHEL 8, OL 8, Ubuntu 21.04 and I am
> > sure others too.
> >
> > At that time Java for Linux will "mostly" run via the X11
> > compatibility layer, but would not pass the JCK,
> > since some important APIs,  notably those of the java.awt.Robot class
> > [2] will fail with Wayland.
> > We need to solve this so that pure Java and applications which mix
> > Java and X11 APis can work.
> >
> > But even then this would mean Java on Linux is not a first class
> > desktop citizen, which is not desirable for
> > the long term, given the importance of Linux to many Java developers
> > as well as to active
> > individual and corporate contributors to the JDK project.
> >
> > Indeed there have already been informal discussions for some time with
> > various parties that have expressed
> > interest in helping towards the outcome of supporting Wayland
> >
> > Consequently we expect quite shortly to propose an OpenJDK project
> > that will consider the goals of
> > - a short to medium term solution for JDK running on Wayland in X11
> > compatibility mode
> > - a medium to long term solution for JDK running as a native Wayland
> > client.
> >
> > There are some unknowns and questions, such as what are the options
> > for supporting Robot ?
> > What other support is missing ? What platform APIs should the
> > implementation  use ?
> > How does a native Wayland solution interoperate with OpenJFX ?
> >
> >
> > Comments, expressions of interest etc are welcome.
> >
> >
> > -Phil Race, for the Java client groups.
> >
> >
> > [1] : https://wayland.freedesktop.org/
> > [2] :
> > https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Robot.html
>


-- 
Mario Torre
Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From philip.race at oracle.com  Thu Jul  8 21:39:13 2021
From: philip.race at oracle.com (Philip Race)
Date: Thu, 8 Jul 2021 14:39:13 -0700
Subject: <AWT Dev> deadlock between AppKit main thread and AWT event
 thread in JDK 17
In-Reply-To: <6AD2C4C4-F1C1-4ACA-BBB8-B0F6A98C5930@cbfiddle.com>
References: <391E8AA7-2DF8-48B9-89AC-47D710C12554@cbfiddle.com>
 <6AD2C4C4-F1C1-4ACA-BBB8-B0F6A98C5930@cbfiddle.com>
Message-ID: <5b3e7e32-284f-55a8-61e9-4da4cdf05db6@oracle.com>


Changing the name seems to have at least been useful to find cases such 
as this which I suspect are very, very rare.

 > My Java code sets up a secondary run loop.

But JDK only enters that mode if *it* creates a secondary run loop.

 >? The AppKit implementation of the file dialog calls Java to get 
accessibility information.

Why would Appkit call Java to ask about A11y info for a platform native 
dialog ?

I suppose the situation isn't as clear to me as it should be.

I might be asking a lot but is there a test case you can provide ?

As to making something like this part of a "public API" it seems to me 
that Java setting up this
mode in a 2ndary run loop in some situations is really an implementation 
choice and I wouldn't
know where to expose it even if it were something appropriate to do.
I'd sooner find a way to dispense with it entirely.
In fact there is some provision when doing FX interop to not use this 
mode at all.

-phil.


On 6/28/21 5:51 AM, Alan Snyder wrote:
> Hmm? it appears that in removing JavaNativeFoundation from the JDK the name of the run loop was changed from AWTRunLoopMode to javaRunLoopMode.
>
> If that is correct, it is an incompatible change that breaks third party use of JavaNativeFoundation for running code on the main thread.
>
> It also sounds like a gratuitous change.
>
>
>
>> On Jun 27, 2021, at 10:24 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
>>
>> I have a program that reliably deadlocks when run on JDK 17, but not on JDK 16 (although that may be due to timing differences, so it may not imply a new bug).
>>
>> It?s a fairly complicated situation.
>>
>> On the AWT thread, my program calls native code that displays a native file dialog. My Java code sets up a secondary run loop. The native code blocks on JNFRunLoop performOnMainThread to create the native file dialog.
>>
>> The AppKit implementation of the file dialog calls Java to get accessibility information. This sets up a run loop on the main thread and upcalls to Java. I presume this posts an AWT event.
>>
>> Before the AWT secondary run loop can process the request for accessibility information, it runs an invocation event (previously posted by a timer) that calls native code. This native code blocks attempting to perform code on the main thread using JNFRunLoop. Apparently, this request is never processed and the AWT thread remains blocked forever.
>>
>> If I change this latter native code to perform the main thread operation without blocking, there is no deadlock and all is fine.
>>
>> But I have encountered other deadlocks (not reliably repeatable) where this option is not available. Therefore, I would like to understand why this deadlock is happening.
>>
>> With run loops on both threads, what would cause the deadlock?
>>
>> [Question: does JDK 17 and JNFRunLoop use the same NSString to identify the java run loop mode? If not, might that matter?]
>>
>> I would appreciate any suggestions of what might be going wrong or how to track it down.
>>
>>   Alan
>>


From javalists at cbfiddle.com  Thu Jul  8 23:02:56 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 8 Jul 2021 16:02:56 -0700
Subject: <AWT Dev> deadlock between AppKit main thread and AWT event
 thread in JDK 17
In-Reply-To: <5b3e7e32-284f-55a8-61e9-4da4cdf05db6@oracle.com>
References: <391E8AA7-2DF8-48B9-89AC-47D710C12554@cbfiddle.com>
 <6AD2C4C4-F1C1-4ACA-BBB8-B0F6A98C5930@cbfiddle.com>
 <5b3e7e32-284f-55a8-61e9-4da4cdf05db6@oracle.com>
Message-ID: <F9EB84BE-C832-4A45-AA19-40677A352E78@cbfiddle.com>

The only thing that needs to be part of the API is the run loop mode *name*. If for some reason in the future the JDK stops using a native run loop when the AppKit main thread calls Java, there is no harm if a native (JNI) library calls performOnMainThread and passes that name as one of the run loop modes. The obsolete run loop mode name will have no effect if no native run loop uses that name.

A problem arises only if the run loop mode name is *changed* and the run loop mode is still important, which is the case now.

I don?t think it matters how rare the problem is. There was no reason to change the name of the run loop mode, so even *one* new deadlock is a regression. I have two examples, but only one is repeatable. That doesn?t mean the other one isn?t important.

To be clear about my repeatable example, my Java code running on the AWT thread starts a secondary Java run loop because it wants to block on the result of the native file dialog. AppKit is calling Java because the native file dialog contains an accessory view that is implemented using a Swing component. This works fine before your change.

Although this example deadlocks reliably, I don?t see how it would help you. I think the problem is obvious. Using JavaNativeFoundation to perform code on the main thread (which is how third party JNI libraries have been told to do it), the old run loop mode name is used, so the code is not performed while the AppKit main thread is blocked in a JDK-implemented native run loop. If the JNI library was called on the AWT thread and the AppKit main thread is waiting for its code to be performed on the AWT thread, deadlock results.

The second example uses a native file dialog (no accessory) and deadlocks when a key shortcut is used causing AppKit to inquire about the application menus. It is more timing sensitive and has happened only once.

>> Changing the name seems to have at least been useful to find cases such as this which I suspect are very, very rare.


I trust you are being sarcastic. I have yet to see a CSR that says an incompatible change is being made solely to find out what breaks.

  Alan



> On Jul 8, 2021, at 2:39 PM, Philip Race <philip.race at oracle.com> wrote:
> 
> 
> Changing the name seems to have at least been useful to find cases such as this which I suspect are very, very rare.
> 
> > My Java code sets up a secondary run loop.
> 
> But JDK only enters that mode if *it* creates a secondary run loop.
> 
> >  The AppKit implementation of the file dialog calls Java to get accessibility information.
> 
> Why would Appkit call Java to ask about A11y info for a platform native dialog ?
> 
> I suppose the situation isn't as clear to me as it should be.
> 
> I might be asking a lot but is there a test case you can provide ?
> 
> As to making something like this part of a "public API" it seems to me that Java setting up this
> mode in a 2ndary run loop in some situations is really an implementation choice and I wouldn't
> know where to expose it even if it were something appropriate to do.
> I'd sooner find a way to dispense with it entirely.
> In fact there is some provision when doing FX interop to not use this mode at all.
> 
> -phil.
> 
> 
> On 6/28/21 5:51 AM, Alan Snyder wrote:
>> Hmm? it appears that in removing JavaNativeFoundation from the JDK the name of the run loop was changed from AWTRunLoopMode to javaRunLoopMode.
>> 
>> If that is correct, it is an incompatible change that breaks third party use of JavaNativeFoundation for running code on the main thread.
>> 
>> It also sounds like a gratuitous change.
>> 
>> 
>> 
>>> On Jun 27, 2021, at 10:24 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
>>> 
>>> I have a program that reliably deadlocks when run on JDK 17, but not on JDK 16 (although that may be due to timing differences, so it may not imply a new bug).
>>> 
>>> It?s a fairly complicated situation.
>>> 
>>> On the AWT thread, my program calls native code that displays a native file dialog. My Java code sets up a secondary run loop. The native code blocks on JNFRunLoop performOnMainThread to create the native file dialog.
>>> 
>>> The AppKit implementation of the file dialog calls Java to get accessibility information. This sets up a run loop on the main thread and upcalls to Java. I presume this posts an AWT event.
>>> 
>>> Before the AWT secondary run loop can process the request for accessibility information, it runs an invocation event (previously posted by a timer) that calls native code. This native code blocks attempting to perform code on the main thread using JNFRunLoop. Apparently, this request is never processed and the AWT thread remains blocked forever.
>>> 
>>> If I change this latter native code to perform the main thread operation without blocking, there is no deadlock and all is fine.
>>> 
>>> But I have encountered other deadlocks (not reliably repeatable) where this option is not available. Therefore, I would like to understand why this deadlock is happening.
>>> 
>>> With run loops on both threads, what would cause the deadlock?
>>> 
>>> [Question: does JDK 17 and JNFRunLoop use the same NSString to identify the java run loop mode? If not, might that matter?]
>>> 
>>> I would appreciate any suggestions of what might be going wrong or how to track it down.
>>> 
>>>  Alan
>>> 
> 


From philip.race at oracle.com  Fri Jul  9 00:18:37 2021
From: philip.race at oracle.com (Philip Race)
Date: Thu, 8 Jul 2021 17:18:37 -0700
Subject: <AWT Dev> deadlock between AppKit main thread and AWT event
 thread in JDK 17
In-Reply-To: <F9EB84BE-C832-4A45-AA19-40677A352E78@cbfiddle.com>
References: <391E8AA7-2DF8-48B9-89AC-47D710C12554@cbfiddle.com>
 <6AD2C4C4-F1C1-4ACA-BBB8-B0F6A98C5930@cbfiddle.com>
 <5b3e7e32-284f-55a8-61e9-4da4cdf05db6@oracle.com>
 <F9EB84BE-C832-4A45-AA19-40677A352E78@cbfiddle.com>
Message-ID: <31dba0cf-2c8f-2fa4-2c7a-acc2cc662e68@oracle.com>

There has never been any contract that JDK would use JNF or specify a 
value for a run loop.
I'd be interested to know where this was documented. I can't even find 
any Apple docs.
There's no way we would ever consider something like this name a 
supported interface without lots
of thought and consideration of the implications.

It is clear that you are interested only in changing the value but I 
still need to understand the use case better
since even reverting it is implying some level of contract which does 
not exist.
I suppose you *must* somewhere be using JNF directly but it is not clear 
where.
And since JNF is going away you are going to have to re-write this code 
to use something else besides use JNF.
And whereas I presume today you are getting the value from JNF you'll 
have to hard-code it in the future
So there won't be any more "at run time get the string from JNF". 
Everyone would need to know it which
makes it a de facto API which makes me very uncomfortable. But I've not 
heard anyone else who is
"broken" by this change so no sarcasm meant, it could mean no one else 
is affected.

So a test case might have helped more than the words.

"My Java code running on the AWT thread starts a secondary Java run loop"

I presume you mean using standard API? Doing something like calling
https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/EventQueue.html#createSecondaryLoop() 
?

-phil.

On 7/8/21 4:02 PM, Alan Snyder wrote:
> The only thing that needs to be part of the API is the run loop mode *name*. If for some reason in the future the JDK stops using a native run loop when the AppKit main thread calls Java, there is no harm if a native (JNI) library calls performOnMainThread and passes that name as one of the run loop modes. The obsolete run loop mode name will have no effect if no native run loop uses that name.
>
> A problem arises only if the run loop mode name is *changed* and the run loop mode is still important, which is the case now.
>
> I don?t think it matters how rare the problem is. There was no reason to change the name of the run loop mode, so even *one* new deadlock is a regression. I have two examples, but only one is repeatable. That doesn?t mean the other one isn?t important.
>
> To be clear about my repeatable example, my Java code running on the AWT thread starts a secondary Java run loop because it wants to block on the result of the native file dialog. AppKit is calling Java because the native file dialog contains an accessory view that is implemented using a Swing component. This works fine before your change.
>
> Although this example deadlocks reliably, I don?t see how it would help you. I think the problem is obvious. Using JavaNativeFoundation to perform code on the main thread (which is how third party JNI libraries have been told to do it), the old run loop mode name is used, so the code is not performed while the AppKit main thread is blocked in a JDK-implemented native run loop. If the JNI library was called on the AWT thread and the AppKit main thread is waiting for its code to be performed on the AWT thread, deadlock results.
>
> The second example uses a native file dialog (no accessory) and deadlocks when a key shortcut is used causing AppKit to inquire about the application menus. It is more timing sensitive and has happened only once.
>
>>> Changing the name seems to have at least been useful to find cases such as this which I suspect are very, very rare.
>
> I trust you are being sarcastic. I have yet to see a CSR that says an incompatible change is being made solely to find out what breaks.
>
>    Alan
>
>
>
>> On Jul 8, 2021, at 2:39 PM, Philip Race <philip.race at oracle.com> wrote:
>>
>>
>> Changing the name seems to have at least been useful to find cases such as this which I suspect are very, very rare.
>>
>>> My Java code sets up a secondary run loop.
>> But JDK only enters that mode if *it* creates a secondary run loop.
>>
>>>   The AppKit implementation of the file dialog calls Java to get accessibility information.
>> Why would Appkit call Java to ask about A11y info for a platform native dialog ?
>>
>> I suppose the situation isn't as clear to me as it should be.
>>
>> I might be asking a lot but is there a test case you can provide ?
>>
>> As to making something like this part of a "public API" it seems to me that Java setting up this
>> mode in a 2ndary run loop in some situations is really an implementation choice and I wouldn't
>> know where to expose it even if it were something appropriate to do.
>> I'd sooner find a way to dispense with it entirely.
>> In fact there is some provision when doing FX interop to not use this mode at all.
>>
>> -phil.
>>
>>
>> On 6/28/21 5:51 AM, Alan Snyder wrote:
>>> Hmm? it appears that in removing JavaNativeFoundation from the JDK the name of the run loop was changed from AWTRunLoopMode to javaRunLoopMode.
>>>
>>> If that is correct, it is an incompatible change that breaks third party use of JavaNativeFoundation for running code on the main thread.
>>>
>>> It also sounds like a gratuitous change.
>>>
>>>
>>>
>>>> On Jun 27, 2021, at 10:24 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
>>>>
>>>> I have a program that reliably deadlocks when run on JDK 17, but not on JDK 16 (although that may be due to timing differences, so it may not imply a new bug).
>>>>
>>>> It?s a fairly complicated situation.
>>>>
>>>> On the AWT thread, my program calls native code that displays a native file dialog. My Java code sets up a secondary run loop. The native code blocks on JNFRunLoop performOnMainThread to create the native file dialog.
>>>>
>>>> The AppKit implementation of the file dialog calls Java to get accessibility information. This sets up a run loop on the main thread and upcalls to Java. I presume this posts an AWT event.
>>>>
>>>> Before the AWT secondary run loop can process the request for accessibility information, it runs an invocation event (previously posted by a timer) that calls native code. This native code blocks attempting to perform code on the main thread using JNFRunLoop. Apparently, this request is never processed and the AWT thread remains blocked forever.
>>>>
>>>> If I change this latter native code to perform the main thread operation without blocking, there is no deadlock and all is fine.
>>>>
>>>> But I have encountered other deadlocks (not reliably repeatable) where this option is not available. Therefore, I would like to understand why this deadlock is happening.
>>>>
>>>> With run loops on both threads, what would cause the deadlock?
>>>>
>>>> [Question: does JDK 17 and JNFRunLoop use the same NSString to identify the java run loop mode? If not, might that matter?]
>>>>
>>>> I would appreciate any suggestions of what might be going wrong or how to track it down.
>>>>
>>>>   Alan
>>>>


From fishgarage at cbfiddle.com  Fri Jul  9 01:17:16 2021
From: fishgarage at cbfiddle.com (Alan Snyder)
Date: Thu, 8 Jul 2021 18:17:16 -0700
Subject: <AWT Dev> deadlock between AppKit main thread and AWT event
 thread in JDK 17
In-Reply-To: <31dba0cf-2c8f-2fa4-2c7a-acc2cc662e68@oracle.com>
References: <391E8AA7-2DF8-48B9-89AC-47D710C12554@cbfiddle.com>
 <6AD2C4C4-F1C1-4ACA-BBB8-B0F6A98C5930@cbfiddle.com>
 <5b3e7e32-284f-55a8-61e9-4da4cdf05db6@oracle.com>
 <F9EB84BE-C832-4A45-AA19-40677A352E78@cbfiddle.com>
 <31dba0cf-2c8f-2fa4-2c7a-acc2cc662e68@oracle.com>
Message-ID: <2806F979-BFDB-4ABD-99F7-BA1CD79C408A@cbfiddle.com>



> On Jul 8, 2021, at 5:18 PM, Philip Race <philip.race at oracle.com> wrote:
> 
> There has never been any contract that JDK would use JNF or specify a value for a run loop.
> I'd be interested to know where this was documented. I can't even find any Apple docs.
> There's no way we would ever consider something like this name a supported interface without lots
> of thought and consideration of the implications.
> 

Well, it sounds like you are splitting hairs. When Oracle took over the Apple JDK, they acquired the API contracts of that JDK, morally, if not legally.

The original implementation of JDK on macOS was created by Apple.
They created JavaNativeFoundation which was used by their JDK *and* provided to application developers writing JNI libraries.
The run loop name was not exposed to application developers, it was hidden in the implementation of [JNFRunLoop performOnMainThreadWaiting].
It worked because it used the same run loop mode as ThreadUtilities, which was used in the JDK native code.
As Mike Swingler said, JNFRunLoop was created for this purpose.

Link: https://wiki.openjdk.java.net/display/MacOSXPort/Java+vs.+AppKit+Threading+Manifesto

I found this document when investigating my deadlock. It wasn?t hard to find.

It is unfortunate that you decided to mess with code you did not understand.

JNF is not going away. It has been converted to an open source unbundled framework.
I am told it is being bundled with some arm64 implementations of JDK because the JavaNativeFoundation in macOS 11 contains only x86_64 code.

All of my JNI libraries that interact with AppKit use JNF. It is hard to imagine a macOS-specific JNI library that doesn?t use JNF.

I have no intention of rewriting my code at this time.
If OpenJDK provides its own JNI support for macOS, I would use it (if necessary to work with the latest JDK).

If I should publish my code for using native file dialogs, I bet it would be used, and all of the developers using it would eventually get reports of deadlock on JDK 17 as it now stands, as all it takes is the user typing a keyboard shortcut. In any case, you are taking a big chance by hoping that no one else will be affected.

Is there a process for submitting a CSR when an incompatibility is discovered after a change has been integrated?

Yes, I use the standard API for creating an AWT secondary run loop.

  Alan





> It is clear that you are interested only in changing the value but I still need to understand the use case better
> since even reverting it is implying some level of contract which does not exist.
> I suppose you *must* somewhere be using JNF directly but it is not clear where.
> And since JNF is going away you are going to have to re-write this code to use something else besides use JNF.
> And whereas I presume today you are getting the value from JNF you'll have to hard-code it in the future
> So there won't be any more "at run time get the string from JNF". Everyone would need to know it which
> makes it a de facto API which makes me very uncomfortable. But I've not heard anyone else who is
> "broken" by this change so no sarcasm meant, it could mean no one else is affected.
> 
> So a test case might have helped more than the words.
> 
> "My Java code running on the AWT thread starts a secondary Java run loop"
> 
> I presume you mean using standard API? Doing something like calling
> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/EventQueue.html#createSecondaryLoop() ?
> 
> -phil.
> 
> On 7/8/21 4:02 PM, Alan Snyder wrote:
>> The only thing that needs to be part of the API is the run loop mode *name*. If for some reason in the future the JDK stops using a native run loop when the AppKit main thread calls Java, there is no harm if a native (JNI) library calls performOnMainThread and passes that name as one of the run loop modes. The obsolete run loop mode name will have no effect if no native run loop uses that name.
>> 
>> A problem arises only if the run loop mode name is *changed* and the run loop mode is still important, which is the case now.
>> 
>> I don?t think it matters how rare the problem is. There was no reason to change the name of the run loop mode, so even *one* new deadlock is a regression. I have two examples, but only one is repeatable. That doesn?t mean the other one isn?t important.
>> 
>> To be clear about my repeatable example, my Java code running on the AWT thread starts a secondary Java run loop because it wants to block on the result of the native file dialog. AppKit is calling Java because the native file dialog contains an accessory view that is implemented using a Swing component. This works fine before your change.
>> 
>> Although this example deadlocks reliably, I don?t see how it would help you. I think the problem is obvious. Using JavaNativeFoundation to perform code on the main thread (which is how third party JNI libraries have been told to do it), the old run loop mode name is used, so the code is not performed while the AppKit main thread is blocked in a JDK-implemented native run loop. If the JNI library was called on the AWT thread and the AppKit main thread is waiting for its code to be performed on the AWT thread, deadlock results.
>> 
>> The second example uses a native file dialog (no accessory) and deadlocks when a key shortcut is used causing AppKit to inquire about the application menus. It is more timing sensitive and has happened only once.
>> 
>>>> Changing the name seems to have at least been useful to find cases such as this which I suspect are very, very rare.
>> 
>> I trust you are being sarcastic. I have yet to see a CSR that says an incompatible change is being made solely to find out what breaks.
>> 
>>   Alan
>> 
>> 
>> 
>>> On Jul 8, 2021, at 2:39 PM, Philip Race <philip.race at oracle.com> wrote:
>>> 
>>> 
>>> Changing the name seems to have at least been useful to find cases such as this which I suspect are very, very rare.
>>> 
>>>> My Java code sets up a secondary run loop.
>>> But JDK only enters that mode if *it* creates a secondary run loop.
>>> 
>>>>  The AppKit implementation of the file dialog calls Java to get accessibility information.
>>> Why would Appkit call Java to ask about A11y info for a platform native dialog ?
>>> 
>>> I suppose the situation isn't as clear to me as it should be.
>>> 
>>> I might be asking a lot but is there a test case you can provide ?
>>> 
>>> As to making something like this part of a "public API" it seems to me that Java setting up this
>>> mode in a 2ndary run loop in some situations is really an implementation choice and I wouldn't
>>> know where to expose it even if it were something appropriate to do.
>>> I'd sooner find a way to dispense with it entirely.
>>> In fact there is some provision when doing FX interop to not use this mode at all.
>>> 
>>> -phil.
>>> 
>>> 
>>> On 6/28/21 5:51 AM, Alan Snyder wrote:
>>>> Hmm? it appears that in removing JavaNativeFoundation from the JDK the name of the run loop was changed from AWTRunLoopMode to javaRunLoopMode.
>>>> 
>>>> If that is correct, it is an incompatible change that breaks third party use of JavaNativeFoundation for running code on the main thread.
>>>> 
>>>> It also sounds like a gratuitous change.
>>>> 
>>>> 
>>>> 
>>>>> On Jun 27, 2021, at 10:24 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
>>>>> 
>>>>> I have a program that reliably deadlocks when run on JDK 17, but not on JDK 16 (although that may be due to timing differences, so it may not imply a new bug).
>>>>> 
>>>>> It?s a fairly complicated situation.
>>>>> 
>>>>> On the AWT thread, my program calls native code that displays a native file dialog. My Java code sets up a secondary run loop. The native code blocks on JNFRunLoop performOnMainThread to create the native file dialog.
>>>>> 
>>>>> The AppKit implementation of the file dialog calls Java to get accessibility information. This sets up a run loop on the main thread and upcalls to Java. I presume this posts an AWT event.
>>>>> 
>>>>> Before the AWT secondary run loop can process the request for accessibility information, it runs an invocation event (previously posted by a timer) that calls native code. This native code blocks attempting to perform code on the main thread using JNFRunLoop. Apparently, this request is never processed and the AWT thread remains blocked forever.
>>>>> 
>>>>> If I change this latter native code to perform the main thread operation without blocking, there is no deadlock and all is fine.
>>>>> 
>>>>> But I have encountered other deadlocks (not reliably repeatable) where this option is not available. Therefore, I would like to understand why this deadlock is happening.
>>>>> 
>>>>> With run loops on both threads, what would cause the deadlock?
>>>>> 
>>>>> [Question: does JDK 17 and JNFRunLoop use the same NSString to identify the java run loop mode? If not, might that matter?]
>>>>> 
>>>>> I would appreciate any suggestions of what might be going wrong or how to track it down.
>>>>> 
>>>>>  Alan
>>>>> 
> 


From alexey.ushakov at jetbrains.com  Fri Jul  9 10:17:32 2021
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Fri, 9 Jul 2021 13:17:32 +0300
Subject: <AWT Dev> Call for Discussion : New Project to support the
 Wayland display server on Linux
In-Reply-To: <CAJwKKmYT8i1d28csxRJ1oCn4RAX3JJHnNY4p1ZQBpyfUE5BbUg@mail.gmail.com>
References: <31d8ebcf-6c63-fdb9-e8e8-88573975dd2f@oracle.com>
 <da2fb186-7315-226a-a47a-10ecee46bf65@oracle.com>
 <ea31b482-b0d9-ef65-3f70-5cae6e3852cf@oracle.com>
 <CAJwKKmYT8i1d28csxRJ1oCn4RAX3JJHnNY4p1ZQBpyfUE5BbUg@mail.gmail.com>
Message-ID: <431674FA-6FE1-493A-9D9B-9542BB7FBD44@jetbrains.com>



> On 8 Jul 2021, at 19:11, Mario Torre <neugens at redhat.com> wrote:
> 
> [resending with hopefully the correct email address as I have
> completely lost which mailing list I'm subscribed to with which
> email!!!]
> 
> I tend to agree with this, we certainly need to identify the
> underlying APIs that are problematic (screenshot and mouse/keyboard
> control as far as I am aware), then see what we can do from there, and
> I would like to first address the XWayland use case before turning
> into a fully fledged new toolkit implementation (but I agree with Phil
> that this is the long term necessity).
> 
> What I would like to do however is to see if it makes sense to create
> a GTK toolkit rather than a Wayland one, and let GTK deal with every
> abstraction. We can be pretty confident that GTK will always be there,
> and will work on X11 and Wayland transparently, so even a user on a
> pure KDE desktop won?t really need to deal directly with Wayland.

I?m not sure, that it?s right direction. We had a similar situation in early days of java. We had a Motif toolkit that was then replaced by XAWT implementation. I think in long term we need to be as close to low level interfaces as possible. We (JetBrains) have a lot of users on different desktops and having only GTK is not an option for us. So, I think that we need to have something like XAWT for Wayland.

Best Regards,
Alexey

> 
> Ideally, users with pure KDE distributions (OpenSuSE maybe?) may help
> here analyse what the requirements are. One problem that comes to mind
> when using GTK as a toolkit is the interaction with other GTK based
> applications that may be embedded, i.e. Swing views in Eclipse,
> Firefox based web views, etc.. etc? But I think this is already today
> an issue and is dealt with in the current 2d and JFX code already.
> 
> Cheers,
> Mario
> 
> On Wed, Jul 7, 2021 at 11:56 PM Alexander Zvegintsev
> <alexander.zvegintsev at oracle.com <mailto:alexander.zvegintsev at oracle.com>> wrote:
>> 
>> (adding awt-dev)
>> 
>> Let me add a few comments.
>> 
>>> already Wayland is the default on RHEL 8, OL 8, Ubuntu 21.04 and I am
>>> sure others too.
>> It is the default, but not in every case. Wayland may be turned off
>> deliberately if you are using a Nvidia graphics card, so you need to
>> take extra steps to get it working
>> <https://askubuntu.com/questions/1334825/what-are-the-steps-to-run-wayland-on-21-04-with-optimus-nvidia <https://askubuntu.com/questions/1334825/what-are-the-steps-to-run-wayland-on-21-04-with-optimus-nvidia>>.
>> 
>> I faced this issue on Ubuntu 21.04.
>> 
>> However things getting better
>> <https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-470-Wayland-Friendly <https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-470-Wayland-Friendly>>with
>> Nvidia 470 drivers, its beta released
>> <https://www.nvidia.com/download/driverResults.aspx/176525/en-us <https://www.nvidia.com/download/driverResults.aspx/176525/en-us>> on
>> 2021.6.22. So probably it won't be a problem in the near future.
>> 
>>> Consequently we expect quite shortly to propose an OpenJDK project
>>> that will consider the goals of
>>> - a short to medium term solution for JDK running on Wayland in X11
>>> compatibility mode
>>> - a medium to long term solution for JDK running as a native Wayland
>>> client.
>> 
>> Both goals having a common task: we will need to implement
>> java.awt.Robot functionality for Wayland(at least).
>> 
>> So it makes sense to make XToolkit's java.awt.Robot work under Wayland
>> first, and then reuse this code for native Wayland client.
>> 
>> I see two major tasks here: taking screenshots and mouse/keyboard
>> control. As far as I know there is no standard way to implement they
>> across all display servers yet.
>> 
>> Possible ways to implement this:
>> 
>>  * taking screenshot:
>>      o open issue against Wayland, may be resolved
>>        someday:https://gitlab.freedesktop.org/wayland/wayland/-/issues/32 <https://gitlab.freedesktop.org/wayland/wayland/-/issues/32>
>>        <https://gitlab.freedesktop.org/wayland/wayland/-/issues/32 <https://gitlab.freedesktop.org/wayland/wayland/-/issues/32>>
>>      o https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot>
>>        <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot>>
>>      o via DBUS interface(display server dependent),
>>        e.g.https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43 <e.g.https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43>
>>        <https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43 <https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43>>
>>  * generating key/mouse events:
>>      o https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.RemoteDesktop <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.RemoteDesktop>
>>        <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.RemoteDesktop <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.RemoteDesktop>>
>>      o generating new virtual input device, uinput, superuser
>>        privileges required, looks too flaky
>>        https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse <https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse>
>>        <https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse <https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse>>
>> 
>> This still need more investigation, butxdg-desktop-portal
>> <https://github.com/flatpak/xdg-desktop-portal <https://github.com/flatpak/xdg-desktop-portal>>looks more preferable way
>> for now.
>> 
>> 
>> Please see below some caveats for OpenJDK native Wayland client:
>> 
>> You can't control a position for a top-level window.
>> <https://gitlab.freedesktop.org/wayland/wayland/-/issues/183 <https://gitlab.freedesktop.org/wayland/wayland/-/issues/183>>
>> 
>> This will also affect a splashscreen windows. It is still possible to
>> control position under XWayland though.
>> 
>> Looks like we will just accept it.
>> 
>> 
>> Top-level window decorations.
>> 
>> Initially Wayland had only client-side decorations(you have to draw it
>> by yourself).
>> 
>> As of now server-side decorations are available by XDG-Decoration
>> protocol <https://gitlab.gnome.org/GNOME/mutter/-/issues/217 <https://gitlab.gnome.org/GNOME/mutter/-/issues/217>>.
>> 
>> However server-side window decorations are not mandatory and not all
>> compositors are supporting it, e.g. Mutter(Gnome Shell's compositor).
>> 
>> Gnome Shell is the default on Ubuntu, so we will need to provide window
>> decorations somehow. One of possible solutions is to use Gtk to create a
>> window for us.
>> 
>> 
>> --
>> Thanks,
>> Alexander.
>> 
>> On 7/7/21 6:24 AM, Philip Race wrote:
>>> 
>>> For a number of years the Linux community has been working on a
>>> complete replacement for the 1980's era X11 desktop display server
>>> protocol
>>> with new protocols and libraries that support client-side rendering
>>> and a compositing desktop windowing system.
>>> This work is being done under the auspices of the Wayland project [1]
>>> and there is a reference
>>> implementation of a Wayland compositor called "Weston".
>>> 
>>> A new client written for  the Wayland desktop has no dependency at all
>>> on X11, but Wayland also provides a compatibility
>>> mode where the X.org X11 server runs along side Wayland, so that
>>> thousands of X11 applications can continue to run.
>>> 
>>> Presently all distros that ship the Wayland server, also still ship
>>> the pure X11 server and the user can select
>>> which one to use on the login screen. However there will come a time
>>> when Wayland is the only choice and
>>> already Wayland is the default on RHEL 8, OL 8, Ubuntu 21.04 and I am
>>> sure others too.
>>> 
>>> At that time Java for Linux will "mostly" run via the X11
>>> compatibility layer, but would not pass the JCK,
>>> since some important APIs,  notably those of the java.awt.Robot class
>>> [2] will fail with Wayland.
>>> We need to solve this so that pure Java and applications which mix
>>> Java and X11 APis can work.
>>> 
>>> But even then this would mean Java on Linux is not a first class
>>> desktop citizen, which is not desirable for
>>> the long term, given the importance of Linux to many Java developers
>>> as well as to active
>>> individual and corporate contributors to the JDK project.
>>> 
>>> Indeed there have already been informal discussions for some time with
>>> various parties that have expressed
>>> interest in helping towards the outcome of supporting Wayland
>>> 
>>> Consequently we expect quite shortly to propose an OpenJDK project
>>> that will consider the goals of
>>> - a short to medium term solution for JDK running on Wayland in X11
>>> compatibility mode
>>> - a medium to long term solution for JDK running as a native Wayland
>>> client.
>>> 
>>> There are some unknowns and questions, such as what are the options
>>> for supporting Robot ?
>>> What other support is missing ? What platform APIs should the
>>> implementation  use ?
>>> How does a native Wayland solution interoperate with OpenJFX ?
>>> 
>>> 
>>> Comments, expressions of interest etc are welcome.
>>> 
>>> 
>>> -Phil Race, for the Java client groups.
>>> 
>>> 
>>> [1] : https://wayland.freedesktop.org/
>>> [2] :
>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Robot.html
>> 
> 
> 
> -- 
> Mario Torre
> Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com <https://www.redhat.com/>>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

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

From neugens at redhat.com  Fri Jul  9 11:04:24 2021
From: neugens at redhat.com (Mario Torre)
Date: Fri, 9 Jul 2021 13:04:24 +0200
Subject: <AWT Dev> Call for Discussion : New Project to support the
 Wayland display server on Linux
In-Reply-To: <431674FA-6FE1-493A-9D9B-9542BB7FBD44@jetbrains.com>
References: <31d8ebcf-6c63-fdb9-e8e8-88573975dd2f@oracle.com>
 <da2fb186-7315-226a-a47a-10ecee46bf65@oracle.com>
 <ea31b482-b0d9-ef65-3f70-5cae6e3852cf@oracle.com>
 <CAJwKKmYT8i1d28csxRJ1oCn4RAX3JJHnNY4p1ZQBpyfUE5BbUg@mail.gmail.com>
 <431674FA-6FE1-493A-9D9B-9542BB7FBD44@jetbrains.com>
Message-ID: <CAJwKKmZVOkCDCscyVkOETygweqctf1sJVHGX4YQv3DWtpxLa3w@mail.gmail.com>

On Fri, Jul 9, 2021 at 12:17 PM Alexey Ushakov
<alexey.ushakov at jetbrains.com> wrote:
>
>
>
> On 8 Jul 2021, at 19:11, Mario Torre <neugens at redhat.com> wrote:
>
> [resending with hopefully the correct email address as I have
> completely lost which mailing list I'm subscribed to with which
> email!!!]
>
> I tend to agree with this, we certainly need to identify the
> underlying APIs that are problematic (screenshot and mouse/keyboard
> control as far as I am aware), then see what we can do from there, and
> I would like to first address the XWayland use case before turning
> into a fully fledged new toolkit implementation (but I agree with Phil
> that this is the long term necessity).
>
> What I would like to do however is to see if it makes sense to create
> a GTK toolkit rather than a Wayland one, and let GTK deal with every
> abstraction. We can be pretty confident that GTK will always be there,
> and will work on X11 and Wayland transparently, so even a user on a
> pure KDE desktop won?t really need to deal directly with Wayland.
>
>
> I?m not sure, that it?s right direction. We had a similar situation in early days of java. We had a Motif toolkit that was then replaced by XAWT implementation. I think in long term we need to be as close to low level interfaces as possible. We (JetBrains) have a lot of users on different desktops and having only GTK is not an option for us. So, I think that we need to have something like XAWT for Wayland.

Yeah, but the experience with that in the past led to the rather
interesting result of having a lot of unmanageable special casing code
to support all sorts of corner cases with window managers and
toolkits. Also, Wayland is not a window manager but a protocol for a
compositor, as such it doesn't really do much itself, we do rely on
existing implementations. This means that if we have a pure Wayland
toolkit it won't work on every KDE instance, for example, unless where
KDE supports Wayland (but yes, that may not be an issue, since the X11
variant will be there anyway).

I'm not advocating GTK as a sole solution, though, I fully agree with
Phil that we need to first explore the options, and it may turn out
that GTK isn't what we want after all and indeed a pure Wayland
toolkit is the right approach as you suggest, but I think we should
explore first existing abstractions and implementation and decide
where to go.

I would be very interested in your experience here, when you say you
have a lot of users on different desktops, what are the combinations
you encounter, can you share this information, can we be sure GTK is
not part of those distributions?

Cheers,
Mario

-- 
Mario Torre
Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From javalists at cbfiddle.com  Fri Jul  9 15:31:01 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 9 Jul 2021 08:31:01 -0700
Subject: <AWT Dev> deadlock between AppKit main thread and AWT event
 thread in JDK 17
In-Reply-To: <2806F979-BFDB-4ABD-99F7-BA1CD79C408A@cbfiddle.com>
References: <391E8AA7-2DF8-48B9-89AC-47D710C12554@cbfiddle.com>
 <6AD2C4C4-F1C1-4ACA-BBB8-B0F6A98C5930@cbfiddle.com>
 <5b3e7e32-284f-55a8-61e9-4da4cdf05db6@oracle.com>
 <F9EB84BE-C832-4A45-AA19-40677A352E78@cbfiddle.com>
 <31dba0cf-2c8f-2fa4-2c7a-acc2cc662e68@oracle.com>
 <2806F979-BFDB-4ABD-99F7-BA1CD79C408A@cbfiddle.com>
Message-ID: <4C3930EA-D01B-486D-BE84-1EFC1C7FCBAD@cbfiddle.com>

Here is the documentation for JNF, rescued from the dustbin of history:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210709/ddb3e4dd/JavaNativeFoundationFunctionsReference-0001.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210709/ddb3e4dd/JNFRunLoopClassReference-0001.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210709/ddb3e4dd/JNFRunnableClassReference-0001.html>

From alexey.ushakov at jetbrains.com  Sat Jul 10 09:00:49 2021
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Sat, 10 Jul 2021 12:00:49 +0300
Subject: <AWT Dev> Call for Discussion : New Project to support the
 Wayland display server on Linux
In-Reply-To: <CAJwKKmZVOkCDCscyVkOETygweqctf1sJVHGX4YQv3DWtpxLa3w@mail.gmail.com>
References: <31d8ebcf-6c63-fdb9-e8e8-88573975dd2f@oracle.com>
 <da2fb186-7315-226a-a47a-10ecee46bf65@oracle.com>
 <ea31b482-b0d9-ef65-3f70-5cae6e3852cf@oracle.com>
 <CAJwKKmYT8i1d28csxRJ1oCn4RAX3JJHnNY4p1ZQBpyfUE5BbUg@mail.gmail.com>
 <431674FA-6FE1-493A-9D9B-9542BB7FBD44@jetbrains.com>
 <CAJwKKmZVOkCDCscyVkOETygweqctf1sJVHGX4YQv3DWtpxLa3w@mail.gmail.com>
Message-ID: <1F604040-E61B-484E-8D6A-CDB3D1427D37@jetbrains.com>

> I would be very interested in your experience here, when you say you
> have a lot of users on different desktops, what are the combinations
> you encounter, can you share this information, can we be sure GTK is
> not part of those distributions?

I?ve looked through the list of issues that we have resolved in the past and it looks like that many of the WMs indeed based on GTK. The rest of the issues are related to KDE. 
I?ll try to find some more info but it looks like that waste majority of users are either on GNOME based env or KDE based. However, we have a lot of different versions of GNOME and KDE in use. So, if we want to base our code on Gnome or KDE we need to provide some kind of compatibility layers (like we already have in JDK) and these layers should be continuously supported.

Best Regards,
Alexey

> On 9 Jul 2021, at 14:04, Mario Torre <neugens at redhat.com> wrote:
> 
> On Fri, Jul 9, 2021 at 12:17 PM Alexey Ushakov
> <alexey.ushakov at jetbrains.com> wrote:
>> 
>> 
>> 
>> On 8 Jul 2021, at 19:11, Mario Torre <neugens at redhat.com> wrote:
>> 
>> [resending with hopefully the correct email address as I have
>> completely lost which mailing list I'm subscribed to with which
>> email!!!]
>> 
>> I tend to agree with this, we certainly need to identify the
>> underlying APIs that are problematic (screenshot and mouse/keyboard
>> control as far as I am aware), then see what we can do from there, and
>> I would like to first address the XWayland use case before turning
>> into a fully fledged new toolkit implementation (but I agree with Phil
>> that this is the long term necessity).
>> 
>> What I would like to do however is to see if it makes sense to create
>> a GTK toolkit rather than a Wayland one, and let GTK deal with every
>> abstraction. We can be pretty confident that GTK will always be there,
>> and will work on X11 and Wayland transparently, so even a user on a
>> pure KDE desktop won?t really need to deal directly with Wayland.
>> 
>> 
>> I?m not sure, that it?s right direction. We had a similar situation in early days of java. We had a Motif toolkit that was then replaced by XAWT implementation. I think in long term we need to be as close to low level interfaces as possible. We (JetBrains) have a lot of users on different desktops and having only GTK is not an option for us. So, I think that we need to have something like XAWT for Wayland.
> 
> Yeah, but the experience with that in the past led to the rather
> interesting result of having a lot of unmanageable special casing code
> to support all sorts of corner cases with window managers and
> toolkits. Also, Wayland is not a window manager but a protocol for a
> compositor, as such it doesn't really do much itself, we do rely on
> existing implementations. This means that if we have a pure Wayland
> toolkit it won't work on every KDE instance, for example, unless where
> KDE supports Wayland (but yes, that may not be an issue, since the X11
> variant will be there anyway).
> 
> I'm not advocating GTK as a sole solution, though, I fully agree with
> Phil that we need to first explore the options, and it may turn out
> that GTK isn't what we want after all and indeed a pure Wayland
> toolkit is the right approach as you suggest, but I think we should
> explore first existing abstractions and implementation and decide
> where to go.
> 
> I would be very interested in your experience here, when you say you
> have a lot of users on different desktops, what are the combinations
> you encounter, can you share this information, can we be sure GTK is
> not part of those distributions?
> 
> Cheers,
> Mario
> 
> -- 
> Mario Torre
> Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> 


From kizune at openjdk.java.net  Mon Jul 12 12:49:57 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 12 Jul 2021 12:49:57 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility [v2]
In-Reply-To: <6j0d_4-6BRHlcDoGqYi5GwaCgbi3C7mF3a_R8u22644=.68bb35b5-8b69-4cfb-98ae-daf60d3bc353@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
 <6j0d_4-6BRHlcDoGqYi5GwaCgbi3C7mF3a_R8u22644=.68bb35b5-8b69-4cfb-98ae-daf60d3bc353@github.com>
Message-ID: <l2SEWErYX6yb96OBHsZMvAuNTWL4Ymg953A2GQewr7Q=.cd9e202e-528f-45ee-a071-bc196d557d71@github.com>

On Fri, 2 Jul 2021 12:45:25 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility
>> This pull request contains solutions for the following tickets:
>> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility;
>> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol;
>> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer;
>> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer;
>> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer;
>> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol;
>> * JDK-8267388 Create implementation for NSAccessibilityTable protocol.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Even on Linux? I meant if the test will be run on the platform where a11y is not implemented then this will be

During testing of text input i have found that the previous implementation with voiceover active pronounced every entered character and then, whet typing pauses, it pronounced the last entered word. With new implementation i only hear the first typed character in the text field and then nothing - no other characters and no last entered word. Looks like we are not sending some notification to the system when text is updated. Needs further investigation.

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

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

From attila at openjdk.java.net  Tue Jul 13 13:08:05 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Tue, 13 Jul 2021 13:08:05 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v9]
In-Reply-To: <_TQh_iGjI3byKr1pc0gr7GZnCiyeKubYIy4rkLwbipY=.08915956-df4e-411e-b985-edd411a5bdc3@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
 <_TQh_iGjI3byKr1pc0gr7GZnCiyeKubYIy4rkLwbipY=.08915956-df4e-411e-b985-edd411a5bdc3@github.com>
Message-ID: <P1bleKY0ErOGoARqX7TwlWUMToCFitDwdEtpPbZPFI0=.0c62cbca-c3a2-4734-b267-415ba99bf399@github.com>

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

>> ?????? ??????? 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 ten additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8268113
>>  - Merge branch 'master' into 8268113
>>  - Merge branch 'master' into 8268113
>>  - Merge branch 'master' into 8268113
>>  - Merge branch 'master' into 8268113
>>  - Merge branch 'master' into 8268113
>>  - 8268113: Inline local vars where reasonable
>>  - 8268113: Delegate to Double.hashCode()
>>  - 8268113: Re-use Long.hashCode() where possible
>
> src/java.base/share/classes/java/util/BitSet.java line 1040:
> 
>> 1038:             h ^= words[i] * (i + 1);
>> 1039: 
>> 1040:         return Long.hashCode(h);
> 
> Here `>>` instead of `>>>` in original code seems to be a typo

It is specified as `>>` in JavaDoc just above the implementation. As the algorithm is part of the public API and thus part of the specification, I don't think you can change it just here in the implementation; you'd need to at least submit a CSR for it.

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

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

From github.com+36081106+savoptik at openjdk.java.net  Tue Jul 13 14:53:28 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Tue, 13 Jul 2021 14:53:28 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility [v3]
In-Reply-To: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
Message-ID: <41bsEbad0o5bwmjM5oIJxvjKulJxW-wHk_H5y5Xp5Fg=.035810e6-9beb-4c8b-a414-95546abd7681@github.com>

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

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

  1. Fixed memory management problems, due to which a11y cells in tables, as well as a11y components nested in list rows, disappeared;
  2. Added checks for exceptions;
  3. corrected descriptions of tests;
  4. Fixed a problem with the pronunciation of the edited text.
  5. Fixed a problem due to which the line number in the table was not pronounced correctly.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4412/files
  - new: https://git.openjdk.java.net/jdk/pull/4412/files/e9b966b5..ba095696

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

  Stats: 154 lines in 17 files changed: 53 ins; 44 del; 57 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4412.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4412/head:pull/4412

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

From clanger at openjdk.java.net  Tue Jul 13 21:43:26 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 13 Jul 2021 21:43:26 GMT
Subject: <AWT Dev> [jdk17] RFR: 8268620: InfiniteLoopException test may fail
 on x86 platforms
Message-ID: <y0h6RB_hLgZahl1DdSjXyZd0XOedZ1sFAt9JQBZfYRg=.d92c82d8-0842-4b41-8c5c-e7e66320e56d@github.com>

Hi all,

this pull request contains a backport of commit 0b09129f from the openjdk/jdk repository.

The commit being backported was authored by Sergey Bylokhov on 15 Jun 2021 and was reviewed by Phil Race, Tejpal Rebari and Alexander Zvegintsev.

It is a test fix only, so it should still be committed to JDK 17.

Thanks!

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

Commit messages:
 - Backport 0b09129faefb945c2f2c35dab2731961216d054e

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

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

From clanger at openjdk.java.net  Wed Jul 14 05:41:12 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Wed, 14 Jul 2021 05:41:12 GMT
Subject: <AWT Dev> [jdk17] Integrated: 8268620: InfiniteLoopException test
 may fail on x86 platforms
In-Reply-To: <y0h6RB_hLgZahl1DdSjXyZd0XOedZ1sFAt9JQBZfYRg=.d92c82d8-0842-4b41-8c5c-e7e66320e56d@github.com>
References: <y0h6RB_hLgZahl1DdSjXyZd0XOedZ1sFAt9JQBZfYRg=.d92c82d8-0842-4b41-8c5c-e7e66320e56d@github.com>
Message-ID: <AoBBafvIp9oUqbb3dESIFWU-a8t1lm0kdsyUsZZ2Gd8=.d02235fe-5771-4371-a6b1-724e23e89c6f@github.com>

On Tue, 13 Jul 2021 21:33:17 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> this pull request contains a backport of commit 0b09129f from the openjdk/jdk repository.
> 
> The commit being backported was authored by Sergey Bylokhov on 15 Jun 2021 and was reviewed by Phil Race, Tejpal Rebari and Alexander Zvegintsev.
> 
> It is a test fix only, so it should still be committed to JDK 17.
> 
> Thanks!

This pull request has now been integrated.

Changeset: e5db9a94
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/e5db9a9405d13cf4b72a8efa903cf8cdcf528e58
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8268620: InfiniteLoopException test may fail on x86 platforms

Backport-of: 0b09129faefb945c2f2c35dab2731961216d054e

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

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

From github.com+36081106+savoptik at openjdk.java.net  Wed Jul 14 11:21:48 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Wed, 14 Jul 2021 11:21:48 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility [v4]
In-Reply-To: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
Message-ID: <MU9liuxP0fpA6tFWPhh4paLzhm23QrNk-ywxTErB1h8=.de8a5792-51fd-466f-a852-15032b3f4ffe@github.com>

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

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

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

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4412/files
  - new: https://git.openjdk.java.net/jdk/pull/4412/files/ba095696..fbe34430

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

  Stats: 40 lines in 10 files changed: 9 ins; 8 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4412.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4412/head:pull/4412

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

From kizune at openjdk.java.net  Wed Jul 14 11:27:23 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 14 Jul 2021 11:27:23 GMT
Subject: <AWT Dev> RFR: 8269637:
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on
 windows
Message-ID: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>

Make fallback code for inaccessible file to return multiresolution icon
Remove test from ProblemList

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

Commit messages:
 - 8269637: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on windows

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

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

From aivanov at openjdk.java.net  Wed Jul 14 11:59:13 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 14 Jul 2021 11:59:13 GMT
Subject: <AWT Dev> RFR: 8269637:
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on
 windows
In-Reply-To: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>
References: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>
Message-ID: <jX9IgbWvhrdEX-fl_pGepEGfJzQr-omklGvp6RlvG4g=.887ce319-25d7-43f1-b8cf-9ed0dd7b710d@github.com>

On Wed, 14 Jul 2021 11:19:53 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Make fallback code for inaccessible file to return multiresolution icon
> Remove test from ProblemList

So, essentially all the icons returned are MultiResolutionIcon even if there's only one icon, right?

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jul 14 12:40:14 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 14 Jul 2021 12:40:14 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v9]
In-Reply-To: <P1bleKY0ErOGoARqX7TwlWUMToCFitDwdEtpPbZPFI0=.0c62cbca-c3a2-4734-b267-415ba99bf399@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
 <_TQh_iGjI3byKr1pc0gr7GZnCiyeKubYIy4rkLwbipY=.08915956-df4e-411e-b985-edd411a5bdc3@github.com>
 <P1bleKY0ErOGoARqX7TwlWUMToCFitDwdEtpPbZPFI0=.0c62cbca-c3a2-4734-b267-415ba99bf399@github.com>
Message-ID: <kSkTAfbM5U7mmIY7zgGfNxaJKFg6ESLoULuug9zIh5s=.854709a6-b430-4b44-a6fd-7a0bd8ca8c5b@github.com>

On Tue, 13 Jul 2021 13:04:36 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/BitSet.java line 1040:
>> 
>>> 1038:             h ^= words[i] * (i + 1);
>>> 1039: 
>>> 1040:         return Long.hashCode(h);
>> 
>> Here `>>` instead of `>>>` in original code seems to be a typo
>
> It is specified as `>>` in JavaDoc just above the implementation. As the algorithm is part of the public API and thus part of the specification, I don't think you can change it just here in the implementation; you'd need to at least submit a CSR for it.

Good point! I'll then revert this change

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jul 14 12:47:43 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 14 Jul 2021 12:47:43 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v10]
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <Gr0Inz8Szvq_9_XqMLpsOM3K-NSVYzKbwd3cDMsTJsQ=.0dfd998d-1423-4e5a-9df0-372e186c5632@github.com>

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

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

 - 8270160 Revert changes in BitSet.hashCode
 - Merge branch 'master' into 8268113
 - 8270160 Revert changes in BitSet.hashCode
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - 8268113: Inline local vars where reasonable
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/2f04364f...1d619c73

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4309/files
  - new: https://git.openjdk.java.net/jdk/pull/4309/files/a72a09b6..1d619c73

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

  Stats: 6977 lines in 323 files changed: 3755 ins; 2117 del; 1105 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309

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

From kizune at openjdk.java.net  Wed Jul 14 17:16:14 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 14 Jul 2021 17:16:14 GMT
Subject: <AWT Dev> RFR: 8269637:
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on
 windows
In-Reply-To: <jX9IgbWvhrdEX-fl_pGepEGfJzQr-omklGvp6RlvG4g=.887ce319-25d7-43f1-b8cf-9ed0dd7b710d@github.com>
References: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>
 <jX9IgbWvhrdEX-fl_pGepEGfJzQr-omklGvp6RlvG4g=.887ce319-25d7-43f1-b8cf-9ed0dd7b710d@github.com>
Message-ID: <ttBGdKwpTUy07-2TtVEXZJlge3LnaVoA172ZQ2-EDi0=.6b80da92-ae14-47cc-9837-71884ea4885a@github.com>

On Wed, 14 Jul 2021 11:56:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> So, essentially all the icons returned are MultiResolutionIcon even if there's only one icon, right?

It was a multiresolution icon even with one icon inside but only when the native and requested icon resolutions do not match. Now it will always be MRI even if file is inaccessible and there is a default icon in System32.dll that matches the requested resolution.

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

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

From aivanov at openjdk.java.net  Wed Jul 14 17:20:13 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 14 Jul 2021 17:20:13 GMT
Subject: <AWT Dev> RFR: 8269637:
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on
 windows
In-Reply-To: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>
References: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>
Message-ID: <KbJbqSnvbATyMOJjlU_uw20E1L2yi808jhZysA8aEJg=.10b3dd34-814e-44e5-a93a-fb2b651926df@github.com>

On Wed, 14 Jul 2021 11:19:53 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Make fallback code for inaccessible file to return multiresolution icon
> Remove test from ProblemList

Marked as reviewed by aivanov (Reviewer).

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

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

From kizune at openjdk.java.net  Wed Jul 14 18:29:16 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 14 Jul 2021 18:29:16 GMT
Subject: <AWT Dev> Integrated: 8269637:
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on
 windows
In-Reply-To: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>
References: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>
Message-ID: <Lz3gNA2f0aS4oeHMdysK3XN-wRp8dOQkgFe4LRot3uQ=.8210c08b-83ee-4c3f-be8c-87038d179a6c@github.com>

On Wed, 14 Jul 2021 11:19:53 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Make fallback code for inaccessible file to return multiresolution icon
> Remove test from ProblemList

This pull request has now been integrated.

Changeset: a033866d
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a033866d786507db69ab75643684e617fd1f4ba2
Stats:     11 lines in 2 files changed: 8 ins; 1 del; 2 mod

8269637: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on windows

Reviewed-by: aivanov

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

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

From github.com+87324768+lawrence-andrew at openjdk.java.net  Thu Jul 15 12:03:34 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Thu, 15 Jul 2021 12:03:34 GMT
Subject: <AWT Dev> RFR: 8270312: Error: Not a test or directory containing
 tests: java/awt/print/PrinterJob/XparColor.java
Message-ID: <BpuGPgEI7nDul5ROrIRKi73Dcu0K0zwcl726jR6B9eo=.5a78a149-672b-4ab9-8d9b-b6f7f2c3baa6@github.com>

1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java
2) Added @test tag so that this testcase can be run
3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main
4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it.
5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog.
6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. 

@shurymury

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

Commit messages:
 - 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java

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

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

From github.com+36081106+savoptik at openjdk.java.net  Thu Jul 15 12:07:44 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Thu, 15 Jul 2021 12:07:44 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility [v5]
In-Reply-To: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
Message-ID: <fpJtQMaZf9nWmcRQQDfp9-mPd_GdrDt0yjsCEFLxORE=.1a5ce2ff-4b8c-4ebb-acb7-2365daa56a61@github.com>

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

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

  ok, so this is in the new code, how hard it will be to reimplement these methods to call invokeAndWait only once per callback from the native, as it usually was done before?

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4412/files
  - new: https://git.openjdk.java.net/jdk/pull/4412/files/fbe34430..76cba143

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

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

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

From github.com+36081106+savoptik at openjdk.java.net  Thu Jul 15 12:35:12 2021
From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov)
Date: Thu, 15 Jul 2021 12:35:12 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility [v5]
In-Reply-To: <tvJ7Xmb4ubHIAor5vwa9GsP0RYq5OatCuVrfmtYATkY=.36b22b34-b48e-413c-9ee6-26083f79875e@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
 <4CZCGYIDcZlVhckVi87sZpwUATr3w9yT_7o5eBD1s5U=.1b564e7b-7861-486a-a53e-7ff04084e994@github.com>
 <DFe4h-ztl4BnHaItVfvImpBeDItCLgKDl5OMYNJSlYM=.86889536-35ad-41e3-94a5-0c9ec7578336@github.com>
 <tvJ7Xmb4ubHIAor5vwa9GsP0RYq5OatCuVrfmtYATkY=.36b22b34-b48e-413c-9ee6-26083f79875e@github.com>
Message-ID: <v8qSA11uBT4R7u6-kmLIbYp22Sf5YtpAlVYuAWqjvIw=.df21bcef-772f-4c86-bc90-d3454f1721df@github.com>

On Wed, 7 Jul 2021 11:23:18 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> The new TabGroup is also named TabGroupAccessibility, so as not to get out of the naming, the old class is renamed for this, otherwise the building will fail.
>
> But when are these Legacy classes used? The "pagetablist" and "table" roles are being handled in commonComponentAccessibility and new implementation classes will be used there. Why can't we just remove these legacy classes and any references to them, instead of renaming them

By agreement, it was decided that we do not remove the legacy code yet until at least one release has passed to make sure there are no regressions.
The legacy code can then be removed with a separate commit without any difficulty.

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

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

From psadhukhan at openjdk.java.net  Thu Jul 15 14:55:12 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 15 Jul 2021 14:55:12 GMT
Subject: <AWT Dev> RFR: 8270312: Error: Not a test or directory
 containing tests: java/awt/print/PrinterJob/XparColor.java
In-Reply-To: <BpuGPgEI7nDul5ROrIRKi73Dcu0K0zwcl726jR6B9eo=.5a78a149-672b-4ab9-8d9b-b6f7f2c3baa6@github.com>
References: <BpuGPgEI7nDul5ROrIRKi73Dcu0K0zwcl726jR6B9eo=.5a78a149-672b-4ab9-8d9b-b6f7f2c3baa6@github.com>
Message-ID: <MJs7RIbLK0oDdWxR_74fpvmFq2H5kBb0skEAj0set_w=.8e96ae65-9f9f-465c-97fa-3a337ecfcf9e@github.com>

On Tue, 13 Jul 2021 14:57:30 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

> 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java
> 2) Added @test tag so that this testcase can be run
> 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main
> 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it.
> 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog.
> 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. 
> 
> @shurymury

I guess for applet/manual=yesno cases, it was decided not to tackle individual tests but to use some standard machinery for all such tests..Not sure if such idea has been dropped
May @prrace can throw some idea.

Otherwise it looks good...BTW, it does not timeout and hangs infinitely if left alone..it should timeout after sometime..did you check that case...
You can modify the copyright year too..

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

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

From github.com+87324768+lawrence-andrew at openjdk.java.net  Thu Jul 15 15:19:13 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Thu, 15 Jul 2021 15:19:13 GMT
Subject: <AWT Dev> RFR: 8270312: Error: Not a test or directory
 containing tests: java/awt/print/PrinterJob/XparColor.java
In-Reply-To: <MJs7RIbLK0oDdWxR_74fpvmFq2H5kBb0skEAj0set_w=.8e96ae65-9f9f-465c-97fa-3a337ecfcf9e@github.com>
References: <BpuGPgEI7nDul5ROrIRKi73Dcu0K0zwcl726jR6B9eo=.5a78a149-672b-4ab9-8d9b-b6f7f2c3baa6@github.com>
 <MJs7RIbLK0oDdWxR_74fpvmFq2H5kBb0skEAj0set_w=.8e96ae65-9f9f-465c-97fa-3a337ecfcf9e@github.com>
Message-ID: <dFVFS3jooUGCOqABVswgqUgusQ5WR8K2fpEHeWhnFCo=.aa4a44aa-4e57-4ed0-b4bf-c24196f8fb7e@github.com>

On Thu, 15 Jul 2021 14:52:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java
>> 2) Added @test tag so that this testcase can be run
>> 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main
>> 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it.
>> 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog.
>> 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. 
>> 
>> @shurymury
>
> I guess for applet/manual=yesno cases, it was decided not to tackle individual tests but to use some standard machinery for all such tests..Not sure if such idea has been dropped
> May @prrace can throw some idea.
> 
> Otherwise it looks good...BTW, it does not timeout and hangs infinitely if left alone..it should timeout after sometime..did you check that case...
> You can modify the copyright year too..

@prsadhuk , thanks for reviewing the test case. Yes, I checked for timeout tag but when I went though the jtreg documentation https://openjdk.java.net/jtreg/tag-spec.html under /manual[=(yesno|done)] found that we cannot add both /manual and /timeout together . According to the documentation "The /manual option may not be given in conjunction with the /timeout option."  I even tried an run the test case and got the following error so decided not to add timeout.
execStatus=Error. Parse Exception: `/manual' disables use of `/timeout'

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

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

From jdv at openjdk.java.net  Thu Jul 15 15:54:27 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 15 Jul 2021 15:54:27 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL [v3]
In-Reply-To: <8vWOzbaaoF3324zsU95c3yLDWF_stflCN9wuK3438Fo=.c4cb5afd-b7f1-41bc-b478-bf300ccc5856@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <usmOxzkj1CF0pC-5Ow29otKIN83h0QWLtjJDbuA14x4=.f5f34034-7126-46c4-b73e-988aaa164bd6@github.com>
 <2l3cbAuO_7J82qboQR3gs_mK7Q80KT5Cc14iyB864kY=.d1986bad-1d4e-4de7-8589-7c1c4989cf3b@github.com>
 <8vWOzbaaoF3324zsU95c3yLDWF_stflCN9wuK3438Fo=.c4cb5afd-b7f1-41bc-b478-bf300ccc5856@github.com>
Message-ID: <Z3NQT2rDU9DM63w1rAG8_9_LNryldUwf-bGgN-duuC0=.cb741aec-6b54-49e8-b65a-183b34bc835c@github.com>

On Mon, 5 Jul 2021 15:51:46 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> The latest version of this PR re-introduces [JDK-8243547](https://bugs.openjdk.java.net/browse/JDK-8243547)
>
>> The latest version of this PR re-introduces [JDK-8243547](https://bugs.openjdk.java.net/browse/JDK-8243547)
> 
> Fixed

@avu Since we are past RDP2, lets close this JDK17 PR and open new jdk-dev(18) PR to continue the review.

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

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

From maxim.kartashev at jetbrains.com  Thu Jul 15 16:53:15 2021
From: maxim.kartashev at jetbrains.com (Maxim Kartashev)
Date: Thu, 15 Jul 2021 19:53:15 +0300
Subject: <AWT Dev> FYI: A CFD for a Wayland project has been posted to
 discuss@openjdk.java.net
In-Reply-To: <e3beaf45-3034-438c-cf45-6e22d2527a5f@oracle.com>
References: <e3beaf45-3034-438c-cf45-6e22d2527a5f@oracle.com>
Message-ID: <CAG0Tb0hryfRq3Ze2=XnVCuX5=q4SPy=4Cnt2NPVupAd3557pkg@mail.gmail.com>

> At that time Java for Linux will "mostly" run via the X11 compatibility layer

There's a quality-of-service problem with running via the compatibility layer as
under certain circumstances native X windows look blurry.

Users with small(ish) HiDPI displays tend to enable fractional scaling and with
that enabled (regardless of the actual scale), XWayland pretends that the screen
size is smaller and then pixel-stretches the resulting window according
to the global scale. This works as a temporary solution, but people get quickly
tired of looking at text that is blurry.

See https://gitlab.gnome.org/GNOME/mutter/-/issues/402 and
https://github.com/swaywm/sway/issues/5917 for some more details.



On Wed, Jul 7, 2021 at 4:59 PM Philip Race <philip.race at oracle.com> wrote:
>
> https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
>
> -phil.

From github.com+9004656+yaaz at openjdk.java.net  Thu Jul 15 17:38:42 2021
From: github.com+9004656+yaaz at openjdk.java.net (Nikita Gubarkov)
Date: Thu, 15 Jul 2021 17:38:42 GMT
Subject: <AWT Dev> RFR: 8269806: Emoji rendering on Linux
Message-ID: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>

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

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

Commit messages:
 - 8269806: Emoji rendering on Linux

Changes: https://git.openjdk.java.net/jdk/pull/4798/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4798&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269806
  Stats: 749 lines in 9 files changed: 555 ins; 51 del; 143 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4798.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4798/head:pull/4798

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

From neugens.limasoftware at gmail.com  Thu Jul  8 16:07:10 2021
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Thu, 8 Jul 2021 18:07:10 +0200
Subject: <AWT Dev> Call for Discussion : New Project to support the
 Wayland display server on Linux
In-Reply-To: <ea31b482-b0d9-ef65-3f70-5cae6e3852cf@oracle.com>
References: <31d8ebcf-6c63-fdb9-e8e8-88573975dd2f@oracle.com>
 <da2fb186-7315-226a-a47a-10ecee46bf65@oracle.com>
 <ea31b482-b0d9-ef65-3f70-5cae6e3852cf@oracle.com>
Message-ID: <72966394-A115-42CD-8E8E-C5B23A049DB2@gmail.com>

I tend to agree with this, we certainly need to identify the underlying APIs that are problematic (screenshot and mouse/keyboard control as far as I am aware), then see what we can do from there, and I would like to first address the XWayland use case before turning into a fully fledged new toolkit implementation (but I agree with Phil that this is the long term necessity).

What I would like to do however is to see if it makes sense to create a GTK toolkit rather than a Wayland one, and let GTK deal with every abstraction. We can be pretty confident that GTK will always be there, and will work on X11 and Wayland transparently, so even a user on a pure KDE desktop won?t really need to deal directly with Wayland.

Ideally, users with pure KDE distributions (OpenSuSE maybe?) may help here analyse what the requirements are. One problem that comes to mind when using GTK as a toolkit is the interaction with other GTK based applications that may be embedded, i.e. Swing views in Eclipse, Firefox based web views, etc.. etc? But I think this is already today an issue and is dealt with in the current 2d and JFX code already.

Cheers,
Mario


> On 7. Jul 2021, at 23:52, Alexander Zvegintsev <alexander.zvegintsev at oracle.com> wrote:
> 
> (adding awt-dev)
> 
> Let me add a few comments.
> 
>> already Wayland is the default on RHEL 8, OL 8, Ubuntu 21.04 and I am sure others too.
> It is the default, but not in every case. Wayland may be turned off deliberately if you are using a Nvidia graphics card, so you need to take extra steps to get it working <https://askubuntu.com/questions/1334825/what-are-the-steps-to-run-wayland-on-21-04-with-optimus-nvidia>.
> 
> I faced this issue on Ubuntu 21.04.
> 
> However things getting better <https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-470-Wayland-Friendly>with Nvidia 470 drivers, its beta released <https://www.nvidia.com/download/driverResults.aspx/176525/en-us> on 2021.6.22. So probably it won't be a problem in the near future.
> 
>> Consequently we expect quite shortly to propose an OpenJDK project that will consider the goals of
>> - a short to medium term solution for JDK running on Wayland in X11 compatibility mode
>> - a medium to long term solution for JDK running as a native Wayland client.
> 
> Both goals having a common task: we will need to implement java.awt.Robot functionality for Wayland(at least).
> 
> So it makes sense to make XToolkit's java.awt.Robot work under Wayland first, and then reuse this code for native Wayland client.
> 
> I see two major tasks here: taking screenshots and mouse/keyboard control. As far as I know there is no standard way to implement they across all display servers yet.
> 
> Possible ways to implement this:
> 
> * taking screenshot:
>     o open issue against Wayland, may be resolved
>       someday:https://gitlab.freedesktop.org/wayland/wayland/-/issues/32
>       <https://gitlab.freedesktop.org/wayland/wayland/-/issues/32>
>     o https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot
>       <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot>
>     o via DBUS interface(display server dependent),
>       e.g.https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43
>       <https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43>
> * generating key/mouse events:
>     o https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.RemoteDesktop
>       <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.RemoteDesktop>
>     o generating new virtual input device, uinput, superuser
>       privileges required, looks too flaky
>       https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse
>       <https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse>
> 
> This still need more investigation, butxdg-desktop-portal <https://github.com/flatpak/xdg-desktop-portal>looks more preferable way for now.
> 
> 
> Please see below some caveats for OpenJDK native Wayland client:
> 
> You can't control a position for a top-level window. <https://gitlab.freedesktop.org/wayland/wayland/-/issues/183>
> 
> This will also affect a splashscreen windows. It is still possible to control position under XWayland though.
> 
> Looks like we will just accept it.
> 
> 
> Top-level window decorations.
> 
> Initially Wayland had only client-side decorations(you have to draw it by yourself).
> 
> As of now server-side decorations are available by XDG-Decoration protocol <https://gitlab.gnome.org/GNOME/mutter/-/issues/217>.
> 
> However server-side window decorations are not mandatory and not all compositors are supporting it, e.g. Mutter(Gnome Shell's compositor).
> 
> Gnome Shell is the default on Ubuntu, so we will need to provide window decorations somehow. One of possible solutions is to use Gtk to create a window for us.
> 
> 
> --
> Thanks,
> Alexander.
> 
> On 7/7/21 6:24 AM, Philip Race wrote:
>> 
>> For a number of years the Linux community has been working on a complete replacement for the 1980's era X11 desktop display server protocol
>> with new protocols and libraries that support client-side rendering and a compositing desktop windowing system.
>> This work is being done under the auspices of the Wayland project [1] and there is a reference
>> implementation of a Wayland compositor called "Weston".
>> 
>> A new client written for  the Wayland desktop has no dependency at all on X11, but Wayland also provides a compatibility
>> mode where the X.org X11 server runs along side Wayland, so that thousands of X11 applications can continue to run.
>> 
>> Presently all distros that ship the Wayland server, also still ship the pure X11 server and the user can select
>> which one to use on the login screen. However there will come a time when Wayland is the only choice and
>> already Wayland is the default on RHEL 8, OL 8, Ubuntu 21.04 and I am sure others too.
>> 
>> At that time Java for Linux will "mostly" run via the X11 compatibility layer, but would not pass the JCK,
>> since some important APIs,  notably those of the java.awt.Robot class [2] will fail with Wayland.
>> We need to solve this so that pure Java and applications which mix Java and X11 APis can work.
>> 
>> But even then this would mean Java on Linux is not a first class desktop citizen, which is not desirable for
>> the long term, given the importance of Linux to many Java developers as well as to active
>> individual and corporate contributors to the JDK project.
>> 
>> Indeed there have already been informal discussions for some time with various parties that have expressed
>> interest in helping towards the outcome of supporting Wayland
>> 
>> Consequently we expect quite shortly to propose an OpenJDK project that will consider the goals of
>> - a short to medium term solution for JDK running on Wayland in X11 compatibility mode
>> - a medium to long term solution for JDK running as a native Wayland client.
>> 
>> There are some unknowns and questions, such as what are the options for supporting Robot ?
>> What other support is missing ? What platform APIs should the implementation  use ?
>> How does a native Wayland solution interoperate with OpenJFX ?
>> 
>> 
>> Comments, expressions of interest etc are welcome.
>> 
>> 
>> -Phil Race, for the Java client groups.
>> 
>> 
>> [1] : https://wayland.freedesktop.org/
>> [2] : https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Robot.html
> 

?
Mario Torre
Java Champion and OpenJDK contributor

PGP Key: 0BAB254E
Fingerprint: AB1C 7C6F 7181 895F E581  93A9 C6B8 A242 0BAB 254E

Twitter: @neugens
Web: https://www.mario-torre.eu/
Music: https://mario-torre.bandcamp.com/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210708/a6fafe91/signature.asc>

From kizune at openjdk.java.net  Fri Jul 16 18:17:53 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 16 Jul 2021 18:17:53 GMT
Subject: <AWT Dev> RFR: 8267385: Create NSAccessibilityElement
 implementation for JavaComponentAccessibility [v5]
In-Reply-To: <fpJtQMaZf9nWmcRQQDfp9-mPd_GdrDt0yjsCEFLxORE=.1a5ce2ff-4b8c-4ebb-acb7-2365daa56a61@github.com>
References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com>
 <fpJtQMaZf9nWmcRQQDfp9-mPd_GdrDt0yjsCEFLxORE=.1a5ce2ff-4b8c-4ebb-acb7-2365daa56a61@github.com>
Message-ID: <oSf9y0V5eT-e_WLWRYwhcS02RmywAFVdMWvPliRLnWQ=.3fc2223b-7cb3-477a-86d8-e8aa575ed8af@github.com>

On Thu, 15 Jul 2021 12:07:44 GMT, Artem Semenov <github.com+36081106+savoptik at openjdk.org> wrote:

>> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility
>> This pull request contains solutions for the following tickets:
>> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility;
>> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol;
>> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer;
>> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer;
>> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer;
>> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol;
>> * JDK-8267388 Create implementation for NSAccessibilityTable protocol.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ok, so this is in the new code, how hard it will be to reimplement these methods to call invokeAndWait only once per callback from the native, as it usually was done before?

Ok, remaining issues for the table implementation:
1. Debug information "WARNING: -[CommonComponentAccessibility isAccessibilityEnabled] called on component that has no accessible component..." printed whenever navigated to the cell that has image inside it - i think this as well as the same message when navigating with voiceover shortcuts to the disabled components - needs to be addressed in this pull request
2. No matter what selection mode is set on the table - cell selection, row selection or column selection - when selection changes due to the table navigation the content of the row where cursor currently placed is announced. Since in previous implementation we had only "Selection changes: n elements out of nnn elements are selected" announcement and in individual cell selection mode there were no announcements at all i consider it as not a functional regression but still we need to create a bug for improving this behavior and it should be addressed as soon as possible and backported to all releases where this implementation will go.
3. Indexes when announcing the content are not right - when full cell announcement happens it always says column 1 row 1 - no matter what cell is being announced. I think that needs to be fixed.

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

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

From prr at openjdk.java.net  Fri Jul 16 19:43:10 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 16 Jul 2021 19:43:10 GMT
Subject: <AWT Dev> [jdk17] RFR: 8270858: Problem List
 java/awt/Window/MultiWindowApp/MultiWindowAppTest.java on Linux
Message-ID: <9m3EN7vTp5gz2H4u6Mwk7jYxMUTwCQfQHUabq7VqWio=.50e78e9f-bacd-4a32-b522-6d9b52133319@github.com>

Failing too often on Ubuntu 21.04 so creating noise in the system. 
We need to look at whether there's a product issue or a system config issue but it still needs to be problem listed.
Per the RDP 2 rules no approval is needed to problem list a test.

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

Commit messages:
 - 8270858: Problem List java/awt/Window/MultiWindowApp/MultiWindowAppTest.java on Linux

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

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

From mikael at openjdk.java.net  Fri Jul 16 19:54:50 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Fri, 16 Jul 2021 19:54:50 GMT
Subject: <AWT Dev> [jdk17] RFR: 8270858: Problem List
 java/awt/Window/MultiWindowApp/MultiWindowAppTest.java on Linux
In-Reply-To: <9m3EN7vTp5gz2H4u6Mwk7jYxMUTwCQfQHUabq7VqWio=.50e78e9f-bacd-4a32-b522-6d9b52133319@github.com>
References: <9m3EN7vTp5gz2H4u6Mwk7jYxMUTwCQfQHUabq7VqWio=.50e78e9f-bacd-4a32-b522-6d9b52133319@github.com>
Message-ID: <0xC31wjDFXtFf_T5KO8ICsUlzwRTSJNNBAZKEc99Mzk=.9960836c-ce5f-4357-a944-661a997cab06@github.com>

On Fri, 16 Jul 2021 19:35:44 GMT, Phil Race <prr at openjdk.org> wrote:

> Failing too often on Ubuntu 21.04 so creating noise in the system. 
> We need to look at whether there's a product issue or a system config issue but it still needs to be problem listed.
> Per the RDP 2 rules no approval is needed to problem list a test.

Marked as reviewed by mikael (Reviewer).

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

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

From pbansal at openjdk.java.net  Fri Jul 16 20:02:52 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 16 Jul 2021 20:02:52 GMT
Subject: <AWT Dev> [jdk17] RFR: 8270858: Problem List
 java/awt/Window/MultiWindowApp/MultiWindowAppTest.java on Linux
In-Reply-To: <9m3EN7vTp5gz2H4u6Mwk7jYxMUTwCQfQHUabq7VqWio=.50e78e9f-bacd-4a32-b522-6d9b52133319@github.com>
References: <9m3EN7vTp5gz2H4u6Mwk7jYxMUTwCQfQHUabq7VqWio=.50e78e9f-bacd-4a32-b522-6d9b52133319@github.com>
Message-ID: <UWHX2WJ28EVYFn5V3X7bhQI5MeNTsbc3ZGy7eWre8NM=.5725d1dd-4126-4a52-b03b-b59fc875a0bf@github.com>

On Fri, 16 Jul 2021 19:35:44 GMT, Phil Race <prr at openjdk.org> wrote:

> Failing too often on Ubuntu 21.04 so creating noise in the system. 
> We need to look at whether there's a product issue or a system config issue but it still needs to be problem listed.
> Per the RDP 2 rules no approval is needed to problem list a test.

Marked as reviewed by pbansal (Reviewer).

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

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

From prr at openjdk.java.net  Fri Jul 16 20:06:54 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 16 Jul 2021 20:06:54 GMT
Subject: <AWT Dev> [jdk17] Integrated: 8270858: Problem List
 java/awt/Window/MultiWindowApp/MultiWindowAppTest.java on Linux
In-Reply-To: <9m3EN7vTp5gz2H4u6Mwk7jYxMUTwCQfQHUabq7VqWio=.50e78e9f-bacd-4a32-b522-6d9b52133319@github.com>
References: <9m3EN7vTp5gz2H4u6Mwk7jYxMUTwCQfQHUabq7VqWio=.50e78e9f-bacd-4a32-b522-6d9b52133319@github.com>
Message-ID: <Jb7xwqAAfDZnzm829FhLLhY3OB0Tac9z9xzIj4CIohg=.1a60a4b4-2f7e-42b3-bbf7-e2a23ad97822@github.com>

On Fri, 16 Jul 2021 19:35:44 GMT, Phil Race <prr at openjdk.org> wrote:

> Failing too often on Ubuntu 21.04 so creating noise in the system. 
> We need to look at whether there's a product issue or a system config issue but it still needs to be problem listed.
> Per the RDP 2 rules no approval is needed to problem list a test.

This pull request has now been integrated.

Changeset: 2dddcce2
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/2dddcce29bec5d16ba2b0580bbcb7cd65e7ea66e
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8270858: Problem List java/awt/Window/MultiWindowApp/MultiWindowAppTest.java on Linux

Reviewed-by: mikael, pbansal

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

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

From weijun at openjdk.java.net  Fri Jul 16 20:58:08 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 16 Jul 2021 20:58:08 GMT
Subject: <AWT Dev> RFR: 8270859: Post JEP 411 refactoring: client libs with
 maximum covering > 10K
Message-ID: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>

This is the last part of Post JEP 411 refactoring that makes `@SuppressWarnings("removal")` more fine grained. This fix deals with all client libs annotations that covers more than 10K bytes of code.

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

Commit messages:
 - 8270859: Post JEP 411 refactoring: client libs with maximum covering > 10K

Changes: https://git.openjdk.java.net/jdk/pull/4815/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4815&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270859
  Stats: 279 lines in 22 files changed: 146 ins; 96 del; 37 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4815.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4815/head:pull/4815

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

From github.com+1671049+vest at openjdk.java.net  Fri Jul 16 21:44:51 2021
From: github.com+1671049+vest at openjdk.java.net (Vest)
Date: Fri, 16 Jul 2021 21:44:51 GMT
Subject: <AWT Dev> RFR: 8270859: Post JEP 411 refactoring: client libs
 with maximum covering > 10K
In-Reply-To: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
References: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
Message-ID: <LkO4xq8qMYUeluQhjkLNhKBXlcjyGqVw4H2Cb2V_DTU=.1588f3ab-cbd0-4194-b23c-d461f1221983@github.com>

On Fri, 16 Jul 2021 20:52:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This is the last part of Post JEP 411 refactoring that makes `@SuppressWarnings("removal")` more fine grained. This fix deals with all client libs annotations that cover more than 10K bytes of code.

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 124:

> 122:                 // We don't care about component.
> 123:                 // So don't prevent class initialisation.
> 124:                 e.printStackTrace();

I am not the reviewer, but I am curious. If we do not care about the exception, is it a right way to just print it to the console as it is? If people use loggers, they won?t be able to capture this stack trace.
thank you for your answer in advance.
p.s. I know it is not your code, but isn?t it a suitable time to improve this part?

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

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

From kcr at openjdk.java.net  Fri Jul 16 22:05:50 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 22:05:50 GMT
Subject: <AWT Dev> RFR: 8270859: Post JEP 411 refactoring: client libs
 with maximum covering > 10K
In-Reply-To: <LkO4xq8qMYUeluQhjkLNhKBXlcjyGqVw4H2Cb2V_DTU=.1588f3ab-cbd0-4194-b23c-d461f1221983@github.com>
References: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
 <LkO4xq8qMYUeluQhjkLNhKBXlcjyGqVw4H2Cb2V_DTU=.1588f3ab-cbd0-4194-b23c-d461f1221983@github.com>
Message-ID: <6CzDn79NU1Z2-mXGthin5FZ0RoHxtPFhe1zSnDoQVxg=.20b080dd-cf22-47fa-b3b5-93fb7524c381@github.com>

On Fri, 16 Jul 2021 21:39:56 GMT, Vest <github.com+1671049+Vest at openjdk.org> wrote:

>> This is the last part of Post JEP 411 refactoring that makes `@SuppressWarnings("removal")` more fine grained. This fix deals with all client libs annotations that cover more than 10K bytes of code.
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 124:
> 
>> 122:                 // We don't care about component.
>> 123:                 // So don't prevent class initialisation.
>> 124:                 e.printStackTrace();
> 
> I am not the reviewer, but I am curious. If we do not care about the exception, is it a right way to just print it to the console as it is? If people use loggers, they won?t be able to capture this stack trace.
> thank you for your answer in advance.
> p.s. I know it is not your code, but isn?t it a suitable time to improve this part?

No. A refactoring change like this is the wrong time to make any unrelated changes. If such changes are a good idea, they should be done in a different bug with a separate pull request.

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

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

From prr at openjdk.java.net  Sat Jul 17 02:00:51 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 17 Jul 2021 02:00:51 GMT
Subject: <AWT Dev> RFR: 8270859: Post JEP 411 refactoring: client libs
 with maximum covering > 10K
In-Reply-To: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
References: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
Message-ID: <eWkWQligjktwkzkX35fM9qt6nxyHA2l5iz2TUh9Fohs=.c7300b4b-1ff5-4785-9fe5-d4e75e77b6d2@github.com>

On Fri, 16 Jul 2021 20:52:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This is the last part of Post JEP 411 refactoring that makes `@SuppressWarnings("removal")` more fine grained. This fix deals with all client libs annotations that cover more than 10K bytes of code.

src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java line 130:

> 128:         }
> 129: 
> 130:         osname = System.getProperty("os.name");

I suppose that you are relying on the default security settings which allow access to this property ?
Do you have reason to believe that it is common to make this assumption in code in the JDK ?
Why take the chance ?

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

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

From prr at openjdk.java.net  Sat Jul 17 02:00:50 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 17 Jul 2021 02:00:50 GMT
Subject: <AWT Dev> RFR: 8270859: Post JEP 411 refactoring: client libs
 with maximum covering > 10K
In-Reply-To: <LkO4xq8qMYUeluQhjkLNhKBXlcjyGqVw4H2Cb2V_DTU=.1588f3ab-cbd0-4194-b23c-d461f1221983@github.com>
References: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
 <LkO4xq8qMYUeluQhjkLNhKBXlcjyGqVw4H2Cb2V_DTU=.1588f3ab-cbd0-4194-b23c-d461f1221983@github.com>
Message-ID: <x5eAAfp6ZJoyOQD8tei4jPLoqeRkNDMQLLTHGgHugUU=.f8840854-4522-422c-a6a6-d42b193e8844@github.com>

On Fri, 16 Jul 2021 21:39:56 GMT, Vest <github.com+1671049+Vest at openjdk.org> wrote:

>> This is the last part of Post JEP 411 refactoring that makes `@SuppressWarnings("removal")` more fine grained. This fix deals with all client libs annotations that cover more than 10K bytes of code.
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 124:
> 
>> 122:                 // We don't care about component.
>> 123:                 // So don't prevent class initialisation.
>> 124:                 e.printStackTrace();
> 
> I am not the reviewer, but I am curious. If we do not care about the exception, is it a right way to just print it to the console as it is? If people use loggers, they won?t be able to capture this stack trace.
> thank you for your answer in advance.
> p.s. I know it is not your code, but isn?t it a suitable time to improve this part?

No, that has nothing to do with what is being done here so it is a terrible time to do it.

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

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

From serb at openjdk.java.net  Sat Jul 17 02:55:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 17 Jul 2021 02:55:48 GMT
Subject: <AWT Dev> RFR: 8270859: Post JEP 411 refactoring: client libs
 with maximum covering > 10K
In-Reply-To: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
References: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
Message-ID: <UpNTNUwTtRI0A6-pFNitqhgawXSHTY5McYsgLfM8KyY=.36c4e94a-89f8-456b-b99f-4280d812b788@github.com>

On Fri, 16 Jul 2021 20:52:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This is the last part of Post JEP 411 refactoring that makes `@SuppressWarnings("removal")` more fine grained. This fix deals with all client libs annotations that cover more than 10K bytes of code.

After the requested change to the PrintServiceLookupProvider.java. Please confirm that the client tests are green.

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

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

From duke at openjdk.java.net  Wed Jul 21 21:16:54 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 21 Jul 2021 21:16:54 GMT
Subject: <AWT Dev> Withdrawn: 8265445: Introduce the new client property for
 mac: apple.awt.windowAppearance
In-Reply-To: <5exzrsMUsqVrr6_YrNKxLSD5A3EWK-VTUzrV5LUwHEg=.45843aa0-0ae8-4ca0-90ee-a647e096d1ec@github.com>
References: <5exzrsMUsqVrr6_YrNKxLSD5A3EWK-VTUzrV5LUwHEg=.45843aa0-0ae8-4ca0-90ee-a647e096d1ec@github.com>
Message-ID: <9Tu8ELdwdsuh5aIwvWBPimXGsKu78c_6wfoiB5LA6xg=.c4db8015-8582-4ba5-870d-7886e82cceef@github.com>

On Tue, 20 Apr 2021 08:01:50 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Implemented apple.awt.windowAppearance client property

This pull request has been closed without being integrated.

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

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

From jwilhelm at openjdk.java.net  Thu Jul 22 00:02:23 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 22 Jul 2021 00:02:23 GMT
Subject: <AWT Dev> RFR: Merge jdk17
Message-ID: <EyjzhDedbKuTrHsbgwBAv7Q3cDRnmZ9pv_zR_rRzdZg=.779ee90b-0a77-413a-95b2-6f85d77296c4@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8266347: assert(Dependencies::is_concrete_root_method(fm, ctxk) == Dependencies::is_concrete_method(m, ctxk)) failed: mismatch
 - 8264066: Enhance compiler validation
 - 8265201: JarFile.getInputStream not validating invalid signed jars
 - 8258432: Improve File Transfers
 - 8264079: Improve abstractions
 - 8262380: Enhance XML processing passes
 - 8262967: Improve Zip file support
 - 8264460: Improve NTLM support
 - 8256491: Better HTTP transport
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/0790f04d...025eaefb

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4863/files
  Stats: 517 lines in 33 files changed: 403 ins; 34 del; 80 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4863/head:pull/4863

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

From jwilhelm at openjdk.java.net  Thu Jul 22 00:51:37 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 22 Jul 2021 00:51:37 GMT
Subject: <AWT Dev> RFR: Merge jdk17 [v2]
In-Reply-To: <EyjzhDedbKuTrHsbgwBAv7Q3cDRnmZ9pv_zR_rRzdZg=.779ee90b-0a77-413a-95b2-6f85d77296c4@github.com>
References: <EyjzhDedbKuTrHsbgwBAv7Q3cDRnmZ9pv_zR_rRzdZg=.779ee90b-0a77-413a-95b2-6f85d77296c4@github.com>
Message-ID: <pAbckiZhttmfKUoxQWEPkJpNvzyNGo9c0VKlKeN929A=.b6e0fb04-aa73-4174-aa51-0b7eecf86564@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 282 commits:

 - Merge
 - 8271015: Split cds/SharedBaseAddress.java test into smaller parts
   
   Reviewed-by: ccheung, minqi
 - 8271014: Refactor HeapShared::is_archived_object()
   
   Reviewed-by: ccheung, minqi
 - 8270949: Make dynamically generated classes with the class file version of the current release
   
   Reviewed-by: alanb
 - 8269849: vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects"
   
   Reviewed-by: kbarrett
 - 8270991: G1 Full GC always performs heap verification after JDK-8269295
   
   Reviewed-by: iwalulya, kbarrett
 - 8270820: remove unused stiFileTableIndex from SDE.c
   
   Reviewed-by: cjplummer, sspitsyn
 - 8270147: Increase stride size allowing unrolling more loops
   
   Reviewed-by: kvn, iveresov
 - 8270803: Reduce CDS API verbosity
   
   Reviewed-by: minqi, ccheung
 - 8269933: test/jdk/javax/net/ssl/compatibility/JdkInfo incorrect verification of protocol and cipher support
   
   Reviewed-by: xuelei, rhalade
 - ... and 272 more: https://git.openjdk.java.net/jdk/compare/89f7998a...025eaefb

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

Changes: https://git.openjdk.java.net/jdk/pull/4863/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=01
  Stats: 55988 lines in 1158 files changed: 26162 ins; 25130 del; 4696 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4863/head:pull/4863

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

From jwilhelm at openjdk.java.net  Thu Jul 22 00:51:38 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 22 Jul 2021 00:51:38 GMT
Subject: <AWT Dev> Integrated: Merge jdk17
In-Reply-To: <EyjzhDedbKuTrHsbgwBAv7Q3cDRnmZ9pv_zR_rRzdZg=.779ee90b-0a77-413a-95b2-6f85d77296c4@github.com>
References: <EyjzhDedbKuTrHsbgwBAv7Q3cDRnmZ9pv_zR_rRzdZg=.779ee90b-0a77-413a-95b2-6f85d77296c4@github.com>
Message-ID: <uLKilEHqK1ophFqLcb19742sf7ShTcYaXP-yo8A0U-M=.04e4edb1-ff3b-406e-8a45-9bc01771a05b@github.com>

On Wed, 21 Jul 2021 23:52:53 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: c36755de
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c36755dedf1a0d7ce0aeadd401e0c70ff84185e7
Stats:     517 lines in 33 files changed: 403 ins; 34 del; 80 mod

Merge

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

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

From psadhukhan at openjdk.java.net  Thu Jul 22 05:51:51 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 22 Jul 2021 05:51:51 GMT
Subject: <AWT Dev> RFR: 8270058: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.desktop [v2]
In-Reply-To: <B7Le6fXQ1ROPzwlmajQeqQdmcUfw3ITgZBS1oLdu34w=.430e6c64-1a2d-4a69-b0ef-9890765d572b@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
 <B7Le6fXQ1ROPzwlmajQeqQdmcUfw3ITgZBS1oLdu34w=.430e6c64-1a2d-4a69-b0ef-9890765d572b@github.com>
Message-ID: <joyBDgpS3uc_k11i-puUWSS0CZEPxRGgKy_E4KmgSfA=.e0e3890c-d8ce-475e-8501-2d14edefcad0@github.com>

On Wed, 21 Jul 2021 09:58:23 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>> 
>> As Mandy suggested, I create this PR for changes involving client code:
>> 
>> src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java
>> src/java.desktop/share/classes/javax/swing/JTabbedPane.java
>> test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
>> test/jdk/javax/imageio/AppletResourceTest.java
>> test/jdk/javax/imageio/ImageReaderReadAll.java
>> test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   checkFromIndexSize(off, len,...)

test/jdk/javax/imageio/ImageReaderReadAll.java line 94:

> 92:             if (seekForwardOnly) {
> 93:                 if (imageIndex < minIndex)
> 94:                     throw new IndexOutOfBoundsException();

Can't we use checkFromToIndex? for this IOOBE too? Used in many other places in this PR...

Please also confirm all tests modified are green after this modification..

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

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

From yyang at openjdk.java.net  Thu Jul 22 06:29:13 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 22 Jul 2021 06:29:13 GMT
Subject: <AWT Dev> RFR: 8270058: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.desktop [v3]
In-Reply-To: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
Message-ID: <FBiKIDgqehM1qVz94eqqkPEyXPKzc-X9qY6lz_zIXsU=.65ecec40-aa0a-4682-9c48-83a1b638abb5@github.com>

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
> 
> As Mandy suggested, I create this PR for changes involving client code:
> 
> src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java
> src/java.desktop/share/classes/javax/swing/JTabbedPane.java
> test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
> test/jdk/javax/imageio/AppletResourceTest.java
> test/jdk/javax/imageio/ImageReaderReadAll.java
> test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java

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

  typo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4718/files
  - new: https://git.openjdk.java.net/jdk/pull/4718/files/e8bea045..1db9e872

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

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

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

From yyang at openjdk.java.net  Thu Jul 22 06:29:14 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 22 Jul 2021 06:29:14 GMT
Subject: <AWT Dev> RFR: 8270058: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.desktop [v2]
In-Reply-To: <joyBDgpS3uc_k11i-puUWSS0CZEPxRGgKy_E4KmgSfA=.e0e3890c-d8ce-475e-8501-2d14edefcad0@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
 <B7Le6fXQ1ROPzwlmajQeqQdmcUfw3ITgZBS1oLdu34w=.430e6c64-1a2d-4a69-b0ef-9890765d572b@github.com>
 <joyBDgpS3uc_k11i-puUWSS0CZEPxRGgKy_E4KmgSfA=.e0e3890c-d8ce-475e-8501-2d14edefcad0@github.com>
Message-ID: <CIuwP2aJ_IOxyn5pqM_hc2S5JCsSYPe-2IMdlZTHwE0=.2897eaa2-6b53-4b9a-bcbe-64e537fc3e78@github.com>

On Thu, 22 Jul 2021 05:48:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   checkFromIndexSize(off, len,...)
>
> test/jdk/javax/imageio/ImageReaderReadAll.java line 94:
> 
>> 92:             if (seekForwardOnly) {
>> 93:                 if (imageIndex < minIndex)
>> 94:                     throw new IndexOutOfBoundsException();
> 
> Can't we use checkFromToIndex? for this IOOBE too? Used in many other places in this PR...
> 
> Please also confirm all tests modified are green after this modification..

checkFromToIndex? has different semantice with checkIndex:

- checkFromToIndex

     * <ul>
     *  <li>{@code fromIndex < 0}</li>
     *  <li>{@code fromIndex > toIndex}</li>
     *  <li>{@code toIndex > length}</li>
     *  <li>{@code length < 0}, which is implied from the former inequalities</li>
     * </ul>

- checkIndex

     * <ul>
     *  <li>{@code index < 0}</li>
     *  <li>{@code index >= length}</li>
     *  <li>{@code length < 0}, which is implied from the former inequalities</li>
     * </ul>

---

The following tests are passed after applying this patch:

test/jdk/javax/imageio/AppletResourceTest.java
test/jdk/javax/imageio/ImageReaderReadAll.java
test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java


ClippedImages.java is a manual test, I have no environment to test it, but since it's a trivial replacement, I think it's okay..

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

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

From psadhukhan at openjdk.java.net  Thu Jul 22 06:37:46 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 22 Jul 2021 06:37:46 GMT
Subject: <AWT Dev> RFR: 8270058: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.desktop [v2]
In-Reply-To: <CIuwP2aJ_IOxyn5pqM_hc2S5JCsSYPe-2IMdlZTHwE0=.2897eaa2-6b53-4b9a-bcbe-64e537fc3e78@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
 <B7Le6fXQ1ROPzwlmajQeqQdmcUfw3ITgZBS1oLdu34w=.430e6c64-1a2d-4a69-b0ef-9890765d572b@github.com>
 <joyBDgpS3uc_k11i-puUWSS0CZEPxRGgKy_E4KmgSfA=.e0e3890c-d8ce-475e-8501-2d14edefcad0@github.com>
 <CIuwP2aJ_IOxyn5pqM_hc2S5JCsSYPe-2IMdlZTHwE0=.2897eaa2-6b53-4b9a-bcbe-64e537fc3e78@github.com>
Message-ID: <OEX8bbCcVIs1FJEdd3HpYZpK_nyLud01L0PlAPS00GE=.a4d079b9-95a2-48b3-b010-845d8491beae@github.com>

On Thu, 22 Jul 2021 06:23:43 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> test/jdk/javax/imageio/ImageReaderReadAll.java line 94:
>> 
>>> 92:             if (seekForwardOnly) {
>>> 93:                 if (imageIndex < minIndex)
>>> 94:                     throw new IndexOutOfBoundsException();
>> 
>> Can't we use checkFromToIndex? for this IOOBE too? Used in many other places in this PR...
>> 
>> Please also confirm all tests modified are green after this modification..
>
> checkFromToIndex? has different semantice with checkIndex:
> 
> - checkFromToIndex
> 
>      * <ul>
>      *  <li>{@code fromIndex < 0}</li>
>      *  <li>{@code fromIndex > toIndex}</li>
>      *  <li>{@code toIndex > length}</li>
>      *  <li>{@code length < 0}, which is implied from the former inequalities</li>
>      * </ul>
> 
> - checkIndex
> 
>      * <ul>
>      *  <li>{@code index < 0}</li>
>      *  <li>{@code index >= length}</li>
>      *  <li>{@code length < 0}, which is implied from the former inequalities</li>
>      * </ul>
> 
> ---
> 
> The following tests are passed after applying this patch:
> 
> test/jdk/javax/imageio/AppletResourceTest.java
> test/jdk/javax/imageio/ImageReaderReadAll.java
> test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java
> 
> 
> ClippedImages.java is a manual test, I have no environment to test it, but since it's a trivial replacement, I think it's okay..

I meant 

if (imageIndex < minIndex)
                    throw new IndexOutOfBoundsException();

can't it be replaced with Objects.checkFromToIndex(minIndex, imageIndex, ..

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

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

From kizune at openjdk.java.net  Thu Jul 22 16:29:56 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 22 Jul 2021 16:29:56 GMT
Subject: <AWT Dev> RFR: 8269984: [macos] JTabbedPane title looks like
 disabled
In-Reply-To: <1UgnY8bvbl7eZ2m_L5HD55XKLcF8ruX5F2WK6VTt1OY=.72741dde-37ef-4e20-8cb5-30ddc5c21c6e@github.com>
References: <1UgnY8bvbl7eZ2m_L5HD55XKLcF8ruX5F2WK6VTt1OY=.72741dde-37ef-4e20-8cb5-30ddc5c21c6e@github.com>
Message-ID: <MRzY2jkCrVhWB2yVRBj3XUui3Jf71l54IKLJajxP1R8=.6735a098-231d-4311-9565-c14f9bc19867@github.com>

On Tue, 20 Jul 2021 01:11:25 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Fixed the version string parsing to work correctly on macOS 11.x and beyond

Closing this PR while opening one for jdk17.

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

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

From kizune at openjdk.java.net  Thu Jul 22 16:29:56 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 22 Jul 2021 16:29:56 GMT
Subject: <AWT Dev> Withdrawn: 8269984: [macos] JTabbedPane title looks like
 disabled
In-Reply-To: <1UgnY8bvbl7eZ2m_L5HD55XKLcF8ruX5F2WK6VTt1OY=.72741dde-37ef-4e20-8cb5-30ddc5c21c6e@github.com>
References: <1UgnY8bvbl7eZ2m_L5HD55XKLcF8ruX5F2WK6VTt1OY=.72741dde-37ef-4e20-8cb5-30ddc5c21c6e@github.com>
Message-ID: <reNAhmULHIBELrVc9WTLJaT903VTSfZmpJ8ibJJBSaw=.1dea435c-d315-4cd7-9283-83d10672f2ea@github.com>

On Tue, 20 Jul 2021 01:11:25 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Fixed the version string parsing to work correctly on macOS 11.x and beyond

This pull request has been closed without being integrated.

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

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

From kizune at openjdk.java.net  Thu Jul 22 16:34:29 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 22 Jul 2021 16:34:29 GMT
Subject: <AWT Dev> [jdk17] RFR: 8269984: [macos] JTabbedPane title looks
 like disabled
Message-ID: <NsNjYNzFGw8eZWTVHf09YPmlKECvSZigBjmEX3Lh004=.7c56bfc5-6dfd-4051-865e-b25e43f5339a@github.com>

Fixed the version string parsing to work correctly on macOS 11.x and beyond

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

Commit messages:
 - 8269984: [macos] JTabbedPane title looks like disabled

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

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

From azvegint at openjdk.java.net  Thu Jul 22 20:01:20 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 22 Jul 2021 20:01:20 GMT
Subject: <AWT Dev> [jdk17] RFR: 8015886:
 java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java
 sometimes failed on ubuntu
Message-ID: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>

This test can fail pretty consistently on some slow systems. Increased delay fixes the issue. 
We do have similar fix in #260

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

Commit messages:
 - initial

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

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

From kizune at openjdk.java.net  Thu Jul 22 20:24:01 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 22 Jul 2021 20:24:01 GMT
Subject: <AWT Dev> [jdk17] RFR: 8015886:
 java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java
 sometimes failed on ubuntu
In-Reply-To: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
References: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
Message-ID: <v8dHqwmZGIlAFEugaWGW2h1XF5eRb-EpeeRgl-9soEY=.108085ba-1ed7-4e59-b885-dbf6730448ca@github.com>

On Thu, 22 Jul 2021 19:53:37 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test can fail pretty consistently on some slow systems. Increased delay fixes the issue. 
> We do have similar fix in #260

I am not sure if we supposed to bump up the copyright year or it is supposed to be done with some script later, but i usually do it myself just to be sure.

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

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

From kcr at openjdk.java.net  Thu Jul 22 20:39:07 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 22 Jul 2021 20:39:07 GMT
Subject: <AWT Dev> [jdk17] RFR: 8269984: [macos] JTabbedPane title looks
 like disabled
In-Reply-To: <NsNjYNzFGw8eZWTVHf09YPmlKECvSZigBjmEX3Lh004=.7c56bfc5-6dfd-4051-865e-b25e43f5339a@github.com>
References: <NsNjYNzFGw8eZWTVHf09YPmlKECvSZigBjmEX3Lh004=.7c56bfc5-6dfd-4051-865e-b25e43f5339a@github.com>
Message-ID: <LU1SQEy-cddEdwUgs-n2zbZSzh69KHsdtbXUDPP-owA=.a8fe7a50-1a9f-4349-8c73-33055f785627@github.com>

On Thu, 22 Jul 2021 16:25:40 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Fixed the version string parsing to work correctly on macOS 11.x and beyond

Looks good. I also tested it on macOS 11.5 and verified that the test case fails (is rendered incorrectly) without your fix and passes with your fix.

@prsadhuk Can you review this?

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

Marked as reviewed by kcr (Author).

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

From azvegint at openjdk.java.net  Thu Jul 22 20:49:36 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 22 Jul 2021 20:49:36 GMT
Subject: <AWT Dev> [jdk17] RFR: 8015886:
 java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java
 sometimes failed on ubuntu [v2]
In-Reply-To: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
References: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
Message-ID: <tQ66tiwwigjeU1GNdGRHxuci2tdWoTVcqrRT0ubtn-k=.3a082bf8-6677-442c-96d4-6281d7fa9b8d@github.com>

> This test can fail pretty consistently on some slow systems. Increased delay fixes the issue. 
> We do have similar fix in #260

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

  year bump

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/272/files
  - new: https://git.openjdk.java.net/jdk17/pull/272/files/d64dd52d..10ca677e

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

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

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

From azvegint at openjdk.java.net  Thu Jul 22 20:49:38 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 22 Jul 2021 20:49:38 GMT
Subject: <AWT Dev> [jdk17] RFR: 8015886:
 java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java
 sometimes failed on ubuntu
In-Reply-To: <v8dHqwmZGIlAFEugaWGW2h1XF5eRb-EpeeRgl-9soEY=.108085ba-1ed7-4e59-b885-dbf6730448ca@github.com>
References: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
 <v8dHqwmZGIlAFEugaWGW2h1XF5eRb-EpeeRgl-9soEY=.108085ba-1ed7-4e59-b885-dbf6730448ca@github.com>
Message-ID: <Zed2kNugMl-riK-tcV_v-axTbvKf2VjDd4V0SESmaio=.bc7aa1aa-f759-4e04-bcaa-06cbe6acfb05@github.com>

On Thu, 22 Jul 2021 20:20:48 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> I am not sure if we supposed to bump up the copyright year or it is supposed to be done with some script later, but i usually do it myself just to be sure.

updated

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

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

From kizune at openjdk.java.net  Thu Jul 22 21:00:07 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 22 Jul 2021 21:00:07 GMT
Subject: <AWT Dev> [jdk17] RFR: 8015886:
 java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java
 sometimes failed on ubuntu [v2]
In-Reply-To: <tQ66tiwwigjeU1GNdGRHxuci2tdWoTVcqrRT0ubtn-k=.3a082bf8-6677-442c-96d4-6281d7fa9b8d@github.com>
References: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
 <tQ66tiwwigjeU1GNdGRHxuci2tdWoTVcqrRT0ubtn-k=.3a082bf8-6677-442c-96d4-6281d7fa9b8d@github.com>
Message-ID: <WftGnjZzKd9mY11jjShTUrhND1REuy1w-S2bYAtc7CQ=.ba81619d-21fe-44d9-83af-d43e7d3ec17f@github.com>

On Thu, 22 Jul 2021 20:49:36 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This test can fail pretty consistently on some slow systems. Increased delay fixes the issue. 
>> We do have similar fix in #260
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   year bump

Marked as reviewed by kizune (Reviewer).

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

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

From serb at openjdk.java.net  Thu Jul 22 22:45:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 22 Jul 2021 22:45:06 GMT
Subject: <AWT Dev> [jdk17] RFR: 8015886:
 java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java
 sometimes failed on ubuntu [v2]
In-Reply-To: <tQ66tiwwigjeU1GNdGRHxuci2tdWoTVcqrRT0ubtn-k=.3a082bf8-6677-442c-96d4-6281d7fa9b8d@github.com>
References: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
 <tQ66tiwwigjeU1GNdGRHxuci2tdWoTVcqrRT0ubtn-k=.3a082bf8-6677-442c-96d4-6281d7fa9b8d@github.com>
Message-ID: <zfH1JJb1hBsahk_zTnqBlhRK4XMorPe9rky5tsOY_JA=.853ac43b-215b-414c-92dd-2eaa0f65cb13@github.com>

On Thu, 22 Jul 2021 20:49:36 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This test can fail pretty consistently on some slow systems. Increased delay fixes the issue. 
>> We do have similar fix in #260
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   year bump

test/jdk/java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java line 82:

> 80: 
> 81:         Util.waitForIdle(robot);
> 82:         robot.delay(200);

I remember some similar issues, so I 'grep" our tests. Looks like usually a bigger delay is used, like 500 or even 1 second.

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

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

From psadhukhan at openjdk.java.net  Fri Jul 23 04:22:06 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 23 Jul 2021 04:22:06 GMT
Subject: <AWT Dev> [jdk17] RFR: 8269984: [macos] JTabbedPane title looks
 like disabled
In-Reply-To: <NsNjYNzFGw8eZWTVHf09YPmlKECvSZigBjmEX3Lh004=.7c56bfc5-6dfd-4051-865e-b25e43f5339a@github.com>
References: <NsNjYNzFGw8eZWTVHf09YPmlKECvSZigBjmEX3Lh004=.7c56bfc5-6dfd-4051-865e-b25e43f5339a@github.com>
Message-ID: <IOkoG3g5LxQ8r5nLffpalIh8FpAq9pIs-Cd2X4MYwEw=.c42fc1d4-d27d-401e-9242-5299e1d16c71@github.com>

On Thu, 22 Jul 2021 16:25:40 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Fixed the version string parsing to work correctly on macOS 11.x and beyond

Since existing currentMacOSXVersionMatchesGivenVersionRange() is changed, did you test in osx 10.15 or below to see current functionality is ok?
ALso, please add noreg-demo to JBS since I guess SwingSet2 is used to test.

src/java.desktop/macosx/classes/apple/laf/JRSUIUtils.java line 39:

> 37:     static boolean isLeopard = isMacOSXLeopard();
> 38:     static boolean isSnowLeopardOrBelow = isMacOSXSnowLeopardOrBelow();
> 39:     static boolean isBigSurOrAbove = isMacOSXBigSurOrAbove();

This is not required..Need to be removed.

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

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

From psadhukhan at openjdk.java.net  Fri Jul 23 04:29:08 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 23 Jul 2021 04:29:08 GMT
Subject: <AWT Dev> [jdk17] RFR: 8015886:
 java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java
 sometimes failed on ubuntu [v2]
In-Reply-To: <zfH1JJb1hBsahk_zTnqBlhRK4XMorPe9rky5tsOY_JA=.853ac43b-215b-414c-92dd-2eaa0f65cb13@github.com>
References: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
 <tQ66tiwwigjeU1GNdGRHxuci2tdWoTVcqrRT0ubtn-k=.3a082bf8-6677-442c-96d4-6281d7fa9b8d@github.com>
 <zfH1JJb1hBsahk_zTnqBlhRK4XMorPe9rky5tsOY_JA=.853ac43b-215b-414c-92dd-2eaa0f65cb13@github.com>
Message-ID: <dgEoZY248Fnom1S_Yu9LyQu4Vdj_6PbLaytoYSxmE5Y=.7cbc1a18-3eea-47b1-911f-d151c51b5670@github.com>

On Thu, 22 Jul 2021 22:41:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   year bump
>
> test/jdk/java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java line 82:
> 
>> 80: 
>> 81:         Util.waitForIdle(robot);
>> 82:         robot.delay(200);
> 
> I remember some similar issues, so I 'grep" our tests. Looks like usually a bigger delay is used, like 500 or even 1 second.

Normally we use delay of 1 sec after frame.setvisible and 500ms after events. 

Can you also please rectify the wildcard imports? Did you try to give CI job running this test for several iterations in all platforms, if yes, can you post it in JBS?

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

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

From kizune at openjdk.java.net  Fri Jul 23 04:54:00 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 23 Jul 2021 04:54:00 GMT
Subject: <AWT Dev> [jdk17] RFR: 8269984: [macos] JTabbedPane title looks
 like disabled
In-Reply-To: <IOkoG3g5LxQ8r5nLffpalIh8FpAq9pIs-Cd2X4MYwEw=.c42fc1d4-d27d-401e-9242-5299e1d16c71@github.com>
References: <NsNjYNzFGw8eZWTVHf09YPmlKECvSZigBjmEX3Lh004=.7c56bfc5-6dfd-4051-865e-b25e43f5339a@github.com>
 <IOkoG3g5LxQ8r5nLffpalIh8FpAq9pIs-Cd2X4MYwEw=.c42fc1d4-d27d-401e-9242-5299e1d16c71@github.com>
Message-ID: <MEAW6n3V_rT0oHtM7n2INWx15MfjE52DDAEJpZr8TsI=.860d786b-8e3b-4be0-8a26-b1e4ff405a07@github.com>

On Fri, 23 Jul 2021 04:18:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Since existing currentMacOSXVersionMatchesGivenVersionRange() is changed, did you test in osx 10.15 or below to see current functionality is ok?

I have tested the public methods of this class with simulated version strings for previous macOS releases - they return correct assumptions about them. I haven't tested the code that acquires the version string but i haven't changed that.

> ALso, please add noreg-demo to JBS since I guess SwingSet2 is used to test.

Done.

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

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

From kizune at openjdk.java.net  Fri Jul 23 05:49:25 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 23 Jul 2021 05:49:25 GMT
Subject: <AWT Dev> [jdk17] RFR: 8269984: [macos] JTabbedPane title looks
 like disabled [v2]
In-Reply-To: <NsNjYNzFGw8eZWTVHf09YPmlKECvSZigBjmEX3Lh004=.7c56bfc5-6dfd-4051-865e-b25e43f5339a@github.com>
References: <NsNjYNzFGw8eZWTVHf09YPmlKECvSZigBjmEX3Lh004=.7c56bfc5-6dfd-4051-865e-b25e43f5339a@github.com>
Message-ID: <j_cfCAQaC-q6ya5cxSELGYMxC6BYCm00JhEyNYvnAg0=.c36c74f1-b65c-440e-89a9-c46af1dc542d@github.com>

> Fixed the version string parsing to work correctly on macOS 11.x and beyond

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

  Demoved isBigSurOrAbove variable that was never used in the code

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/269/files
  - new: https://git.openjdk.java.net/jdk17/pull/269/files/538305f9..3543c209

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

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

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

From kizune at openjdk.java.net  Fri Jul 23 05:49:26 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 23 Jul 2021 05:49:26 GMT
Subject: <AWT Dev> [jdk17] RFR: 8269984: [macos] JTabbedPane title looks
 like disabled [v2]
In-Reply-To: <IOkoG3g5LxQ8r5nLffpalIh8FpAq9pIs-Cd2X4MYwEw=.c42fc1d4-d27d-401e-9242-5299e1d16c71@github.com>
References: <NsNjYNzFGw8eZWTVHf09YPmlKECvSZigBjmEX3Lh004=.7c56bfc5-6dfd-4051-865e-b25e43f5339a@github.com>
 <IOkoG3g5LxQ8r5nLffpalIh8FpAq9pIs-Cd2X4MYwEw=.c42fc1d4-d27d-401e-9242-5299e1d16c71@github.com>
Message-ID: <arDofC0R0GpZ3BFCh11uNWI9-wjDOnSjQtcAgO_m3D0=.1698a996-f6ae-470a-9459-7442cbda4c53@github.com>

On Fri, 23 Jul 2021 04:16:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This is not required..Need to be removed.

Done.

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

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

From psadhukhan at openjdk.java.net  Fri Jul 23 06:06:07 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 23 Jul 2021 06:06:07 GMT
Subject: <AWT Dev> [jdk17] RFR: 8269984: [macos] JTabbedPane title looks
 like disabled [v2]
In-Reply-To: <j_cfCAQaC-q6ya5cxSELGYMxC6BYCm00JhEyNYvnAg0=.c36c74f1-b65c-440e-89a9-c46af1dc542d@github.com>
References: <NsNjYNzFGw8eZWTVHf09YPmlKECvSZigBjmEX3Lh004=.7c56bfc5-6dfd-4051-865e-b25e43f5339a@github.com>
 <j_cfCAQaC-q6ya5cxSELGYMxC6BYCm00JhEyNYvnAg0=.c36c74f1-b65c-440e-89a9-c46af1dc542d@github.com>
Message-ID: <QX-v8KdgLltI5Z2YM8k2RC9Wkv2rys6m6S_I6bvjBZs=.23fbb7e8-52b9-4f4e-b4aa-cde131cf1615@github.com>

On Fri, 23 Jul 2021 05:49:25 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Fixed the version string parsing to work correctly on macOS 11.x and beyond
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Demoved isBigSurOrAbove variable that was never used in the code

Marked as reviewed by psadhukhan (Reviewer).

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

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

From kcr at openjdk.java.net  Fri Jul 23 11:06:06 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 23 Jul 2021 11:06:06 GMT
Subject: <AWT Dev> [jdk17] RFR: 8269984: [macos] JTabbedPane title looks
 like disabled [v2]
In-Reply-To: <j_cfCAQaC-q6ya5cxSELGYMxC6BYCm00JhEyNYvnAg0=.c36c74f1-b65c-440e-89a9-c46af1dc542d@github.com>
References: <NsNjYNzFGw8eZWTVHf09YPmlKECvSZigBjmEX3Lh004=.7c56bfc5-6dfd-4051-865e-b25e43f5339a@github.com>
 <j_cfCAQaC-q6ya5cxSELGYMxC6BYCm00JhEyNYvnAg0=.c36c74f1-b65c-440e-89a9-c46af1dc542d@github.com>
Message-ID: <CGThftZZkoDf4c-1JTAeEVM-svTcURCnePzchW3fKoc=.4db8eada-3505-4ec2-b9dc-5318a8f67fa4@github.com>

On Fri, 23 Jul 2021 05:49:25 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Fixed the version string parsing to work correctly on macOS 11.x and beyond
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Demoved isBigSurOrAbove variable that was never used in the code

Updated fix looks good.

> > ALso, please add noreg-demo to JBS since I guess SwingSet2 is used to test.
> 
> Done.

That's not what `noreg-demo` means (that label means that the change itself is limited to a demo).

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

Marked as reviewed by kcr (Author).

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

From azvegint at openjdk.java.net  Fri Jul 23 11:33:35 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 23 Jul 2021 11:33:35 GMT
Subject: <AWT Dev> [jdk17] RFR: 8015886:
 java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java
 sometimes failed on ubuntu [v3]
In-Reply-To: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
References: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
Message-ID: <D47h62vNjjmV80UBTe6BfO1JPNglDm8RvkzP0yVr_Jg=.9eb373db-8e63-4bee-98ba-496e3539582b@github.com>

> This test can fail pretty consistently on some slow systems. Increased delay fixes the issue. 
> We do have similar fix in #260

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

  increased delay

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/272/files
  - new: https://git.openjdk.java.net/jdk17/pull/272/files/10ca677e..cbe6f219

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

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/272.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/272/head:pull/272

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

From psadhukhan at openjdk.java.net  Fri Jul 23 11:57:05 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 23 Jul 2021 11:57:05 GMT
Subject: <AWT Dev> [jdk17] RFR: 8015886:
 java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java
 sometimes failed on ubuntu [v3]
In-Reply-To: <D47h62vNjjmV80UBTe6BfO1JPNglDm8RvkzP0yVr_Jg=.9eb373db-8e63-4bee-98ba-496e3539582b@github.com>
References: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
 <D47h62vNjjmV80UBTe6BfO1JPNglDm8RvkzP0yVr_Jg=.9eb373db-8e63-4bee-98ba-496e3539582b@github.com>
Message-ID: <sEjInWJSdmhYyJ_gyhsXLGmULgJzYNRfckAhxsodmVo=.5f536264-a1dc-455f-81b6-062fe0a700d7@github.com>

On Fri, 23 Jul 2021 11:33:35 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This test can fail pretty consistently on some slow systems. Increased delay fixes the issue. 
>> We do have similar fix in #260
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   increased delay

Looks good. BTW, normally in swing we also do dispose of the frame after test is over in finally block...Not sure in awt Frame...It may not be required if you are running standalone but in a group of CI run, it might prove effective..

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

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

From azvegint at openjdk.java.net  Fri Jul 23 12:56:32 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 23 Jul 2021 12:56:32 GMT
Subject: <AWT Dev> [jdk17] RFR: 8015886:
 java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java
 sometimes failed on ubuntu [v4]
In-Reply-To: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
References: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
Message-ID: <mZqPexx5wAtLD7gVv8OQpi3NKVMP2HTGvVYyda4A5cA=.9be3179c-269a-46f0-b88d-1e48f6e6d92b@github.com>

> This test can fail pretty consistently on some slow systems. Increased delay fixes the issue. 
> We do have similar fix in #260

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

  finally dispose

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/272/files
  - new: https://git.openjdk.java.net/jdk17/pull/272/files/cbe6f219..df2a2aa3

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

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

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

From azvegint at openjdk.java.net  Fri Jul 23 12:56:32 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 23 Jul 2021 12:56:32 GMT
Subject: <AWT Dev> [jdk17] RFR: 8015886:
 java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java
 sometimes failed on ubuntu [v3]
In-Reply-To: <sEjInWJSdmhYyJ_gyhsXLGmULgJzYNRfckAhxsodmVo=.5f536264-a1dc-455f-81b6-062fe0a700d7@github.com>
References: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
 <D47h62vNjjmV80UBTe6BfO1JPNglDm8RvkzP0yVr_Jg=.9eb373db-8e63-4bee-98ba-496e3539582b@github.com>
 <sEjInWJSdmhYyJ_gyhsXLGmULgJzYNRfckAhxsodmVo=.5f536264-a1dc-455f-81b6-062fe0a700d7@github.com>
Message-ID: <gophcuI7v4POok0XspzWVg23SqnD_YUUGZM8_L7kVzA=.d1a189ce-3b19-4a5c-af0b-dc60abe9b42b@github.com>

On Fri, 23 Jul 2021 11:53:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Looks good. BTW, normally in swing we also do dispose of the frame after test is over in finally block...Not sure in awt Frame...It may not be required if you are running standalone but in a group of CI run, it might prove effective..

looks like jtreg handles this, but this might be helpful specially for standalone run.

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

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

From azvegint at openjdk.java.net  Fri Jul 23 14:44:01 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 23 Jul 2021 14:44:01 GMT
Subject: <AWT Dev> [jdk17] RFR: 8015886:
 java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java
 sometimes failed on ubuntu [v4]
In-Reply-To: <mZqPexx5wAtLD7gVv8OQpi3NKVMP2HTGvVYyda4A5cA=.9be3179c-269a-46f0-b88d-1e48f6e6d92b@github.com>
References: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
 <mZqPexx5wAtLD7gVv8OQpi3NKVMP2HTGvVYyda4A5cA=.9be3179c-269a-46f0-b88d-1e48f6e6d92b@github.com>
Message-ID: <vA-_Op_mz6YmFnuYHKOU171tXqYuaTeHxaPr1N6zhys=.5a9041bf-d7aa-4e2b-843d-6f00860e233c@github.com>

On Fri, 23 Jul 2021 12:56:32 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This test can fail pretty consistently on some slow systems. Increased delay fixes the issue. 
>> We do have similar fix in #260
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   finally dispose

CI job run is green.

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

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

From kizune at openjdk.java.net  Fri Jul 23 17:40:02 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 23 Jul 2021 17:40:02 GMT
Subject: <AWT Dev> [jdk17] Integrated: 8269984: [macos] JTabbedPane title
 looks like disabled
In-Reply-To: <NsNjYNzFGw8eZWTVHf09YPmlKECvSZigBjmEX3Lh004=.7c56bfc5-6dfd-4051-865e-b25e43f5339a@github.com>
References: <NsNjYNzFGw8eZWTVHf09YPmlKECvSZigBjmEX3Lh004=.7c56bfc5-6dfd-4051-865e-b25e43f5339a@github.com>
Message-ID: <H4sWPbhmHRVRUg3B_3GcAA_owIYdPnG8926VXx6xNY8=.68918acb-5c09-4b70-b0b6-f7d699639f58@github.com>

On Thu, 22 Jul 2021 16:25:40 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Fixed the version string parsing to work correctly on macOS 11.x and beyond

This pull request has now been integrated.

Changeset: 8adf008b
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/8adf008b150bfda783ae615965198edb4d196016
Stats:     27 lines in 1 file changed: 17 ins; 3 del; 7 mod

8269984: [macos] JTabbedPane title looks like  disabled

Reviewed-by: kcr, psadhukhan

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

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

From jwilhelm at openjdk.java.net  Fri Jul 23 22:33:08 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 23 Jul 2021 22:33:08 GMT
Subject: <AWT Dev> RFR: Merge jdk17
Message-ID: <4aCK96JpOk6n9yrXLvEWrdmsSVnhjAmJBRnTaJUACRM=.7566713a-7bdb-478a-b206-1e21d20c435e@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8269984: [macos] JTabbedPane title looks like  disabled
 - 8271173: serviceability/jvmti/GetObjectSizeClass.java doesn't check exit code
 - 8271189: runtime/handshake/HandshakeTimeoutTest.java can be run in driver mode

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4896/files
  Stats: 29 lines in 3 files changed: 18 ins; 3 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4896.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4896/head:pull/4896

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

From jwilhelm at openjdk.java.net  Sat Jul 24 01:11:08 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Sat, 24 Jul 2021 01:11:08 GMT
Subject: <AWT Dev> Integrated: Merge jdk17
In-Reply-To: <4aCK96JpOk6n9yrXLvEWrdmsSVnhjAmJBRnTaJUACRM=.7566713a-7bdb-478a-b206-1e21d20c435e@github.com>
References: <4aCK96JpOk6n9yrXLvEWrdmsSVnhjAmJBRnTaJUACRM=.7566713a-7bdb-478a-b206-1e21d20c435e@github.com>
Message-ID: <KmXzKbCwFQSOq0SS0IN2BTxajl6WBgXYYljQidzFcL0=.69f22959-2d9d-4a92-96bd-d0c553449f99@github.com>

On Fri, 23 Jul 2021 22:24:14 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 0dcfc42f
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0dcfc42f230a4958c9349f4145093c5b02e06ad4
Stats:     29 lines in 3 files changed: 18 ins; 3 del; 8 mod

Merge

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

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

From serb at openjdk.java.net  Sat Jul 24 03:08:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 24 Jul 2021 03:08:05 GMT
Subject: <AWT Dev> [jdk17] RFR: 8015886:
 java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java
 sometimes failed on ubuntu [v4]
In-Reply-To: <mZqPexx5wAtLD7gVv8OQpi3NKVMP2HTGvVYyda4A5cA=.9be3179c-269a-46f0-b88d-1e48f6e6d92b@github.com>
References: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
 <mZqPexx5wAtLD7gVv8OQpi3NKVMP2HTGvVYyda4A5cA=.9be3179c-269a-46f0-b88d-1e48f6e6d92b@github.com>
Message-ID: <GnCzssNRThdsOogu5QcRetSQFqcopvcCreqXg9MPgAc=.5c20a9e2-78fd-4473-a0ed-e1fd8af289ea@github.com>

On Fri, 23 Jul 2021 12:56:32 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This test can fail pretty consistently on some slow systems. Increased delay fixes the issue. 
>> We do have similar fix in #260
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   finally dispose

Marked as reviewed by serb (Reviewer).

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

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

From azvegint at openjdk.java.net  Sat Jul 24 08:17:06 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Sat, 24 Jul 2021 08:17:06 GMT
Subject: <AWT Dev> [jdk17] Integrated: 8015886:
 java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java
 sometimes failed on ubuntu
In-Reply-To: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
References: <Uy0j2YVJACiQ06PkbqR-aMvsx9b9lzOhGwh8mYlw6X8=.7d11ea13-618b-4662-89a0-a57228837d24@github.com>
Message-ID: <-pz20G__aVq-kExPcL5OBSHHa_E1SbxvVztugv6AgTM=.108c3bb9-bcb0-4f69-8b1c-1fc8f27c0566@github.com>

On Thu, 22 Jul 2021 19:53:37 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test can fail pretty consistently on some slow systems. Increased delay fixes the issue. 
> We do have similar fix in #260

This pull request has now been integrated.

Changeset: 049b2ad4
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/049b2ad4dfbc13d21fd58467a0975097a17e8681
Stats:     12 lines in 1 file changed: 9 ins; 0 del; 3 mod

8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu

Reviewed-by: kizune, serb

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Jul 26 08:27:14 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: Mon, 26 Jul 2021 08:27:14 GMT
Subject: <AWT Dev> RFR: 8268113: Re-use Long.hashCode() where possible
 [v11]
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <bxpkAvClK09ExpSL7KeZj9nZqCKHj-b7thCYa75EfuE=.2ad4ad96-2529-47d8-96ea-d90db7fc0e12@github.com>

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

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

 - Merge branch 'master' into 8268113
 - 8270160 Revert changes in BitSet.hashCode
 - Merge branch 'master' into 8268113
 - 8270160 Revert changes in BitSet.hashCode
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/441e382b...bd762b7d

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4309/files
  - new: https://git.openjdk.java.net/jdk/pull/4309/files/1d619c73..bd762b7d

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

  Stats: 7986 lines in 302 files changed: 5011 ins; 1046 del; 1929 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Jul 26 11:30:21 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 26 Jul 2021 11:30:21 GMT
Subject: <AWT Dev> RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
Message-ID: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>

I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

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

Commit messages:
 - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying
 - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying
 - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Jul 26 11:30:21 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: Mon, 26 Jul 2021 11:30:21 GMT
Subject: <AWT Dev> RFR: 8269130: Replace usages of Collection.toArray()
 with Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <RGdfH15SqrmAJ_F_lJsXWPgDXASBawZa6STmTw79O0M=.9a0479b0-2555-4541-95ba-665960ab4fbe@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

I think the same simlification can be done for some classes affected by your previous PR https://github.com/openjdk/jdk/pull/4482, e.g. `HttpsClient`, lines 154-157 and 177-180 and `PKCS7`, so I'd wait for https://github.com/openjdk/jdk/pull/4482 and then add one more commit here.

@turbanoff I've filed a ticket for this: https://bugs.openjdk.java.net/browse/JDK-8269130. Also I think you can integrate https://github.com/openjdk/jdk/pull/4482

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

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

From github.com+114367+mbien at openjdk.java.net  Mon Jul 26 11:30:21 2021
From: github.com+114367+mbien at openjdk.java.net (Michael Bien)
Date: Mon, 26 Jul 2021 11:30:21 GMT
Subject: <AWT Dev> RFR: 8269130: Replace usages of Collection.toArray()
 with Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/java.base/share/classes/java/security/Security.java line 656:

> 654:             return null;
> 655: 
> 656:         return candidates.toArray(new Provider[0]);

`candidates.toArray(new Provider[candidates.size()]);`

would use the fast path of the toArray() implementation. Performance probably doesn't matter much in a lot of this cases, but since its only a few characters more, its still worth considering IMO.

The only places I would leave this out are on the HashTable and on the Vector collections in this PR, since calling one synchronized method is not the same as calling two - concurrency wise.

(i am no reviewer)

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Jul 26 11:30:22 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 26 Jul 2021 11:30:22 GMT
Subject: <AWT Dev> RFR: 8269130: Replace usages of Collection.toArray()
 with Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
 <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>
Message-ID: <HbAuDh-MFnpUrGAxHJTKJX9_0ybK5EbYuHoTI3s2MPE=.6104a076-442a-4c67-9805-5c4008905d10@github.com>

On Tue, 15 Jun 2021 12:06:43 GMT, Michael Bien <github.com+114367+mbien at openjdk.org> wrote:

>> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
>> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.
>
> src/java.base/share/classes/java/security/Security.java line 656:
> 
>> 654:             return null;
>> 655: 
>> 656:         return candidates.toArray(new Provider[0]);
> 
> `candidates.toArray(new Provider[candidates.size()]);`
> 
> would use the fast path of the toArray() implementation. Performance probably doesn't matter much in a lot of this cases, but since its only a few characters more, its still worth considering IMO.
> 
> The only places I would leave this out are on the HashTable and on the Vector collections in this PR, since calling one synchronized method is not the same as calling two - concurrency wise.
> 
> (i am no reviewer)

Actually it's not _the fast path_ - see https://shipilev.net/blog/2016/arrays-wisdom-ancients/

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

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

From github.com+114367+mbien at openjdk.java.net  Mon Jul 26 11:30:22 2021
From: github.com+114367+mbien at openjdk.java.net (Michael Bien)
Date: Mon, 26 Jul 2021 11:30:22 GMT
Subject: <AWT Dev> RFR: 8269130: Replace usages of Collection.toArray()
 with Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <HbAuDh-MFnpUrGAxHJTKJX9_0ybK5EbYuHoTI3s2MPE=.6104a076-442a-4c67-9805-5c4008905d10@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
 <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>
 <HbAuDh-MFnpUrGAxHJTKJX9_0ybK5EbYuHoTI3s2MPE=.6104a076-442a-4c67-9805-5c4008905d10@github.com>
Message-ID: <XMK9iClcp3uF-aORRgwlw0r7X9TGNvP12JYZSFESnwc=.4ee3292e-f9f0-4fb2-b039-8f4f2b97df34@github.com>

On Tue, 15 Jun 2021 12:34:50 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 656:
>> 
>>> 654:             return null;
>>> 655: 
>>> 656:         return candidates.toArray(new Provider[0]);
>> 
>> `candidates.toArray(new Provider[candidates.size()]);`
>> 
>> would use the fast path of the toArray() implementation. Performance probably doesn't matter much in a lot of this cases, but since its only a few characters more, its still worth considering IMO.
>> 
>> The only places I would leave this out are on the HashTable and on the Vector collections in this PR, since calling one synchronized method is not the same as calling two - concurrency wise.
>> 
>> (i am no reviewer)
>
> Actually it's not _the fast path_ - see https://shipilev.net/blog/2016/arrays-wisdom-ancients/

oh I am sorry my mistake - I actually now remember reading the article. (It would be interesting to rerun the benchmark on modern JDKs since I would expect the gap to be smaller now)
Please disregard my suggestion.

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

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

From serb at openjdk.java.net  Mon Jul 26 11:30:23 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 26 Jul 2021 11:30:23 GMT
Subject: <AWT Dev> RFR: 8269130: Replace usages of Collection.toArray()
 with Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <522sj45K-E26GUke0gp6dDoq_4dpwfLMytNVmg5V2k8=.2d5a1a6c-4191-4f63-a83e-af35c69cb6e4@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line 191:

> 189:                         installed[i]);
> 190:             }
> 191:             String[] retval = map.keySet().toArray(new String[0]);

Looks like previously the code returns values, and now it will return keys, please recheck.

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

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

From mullan at openjdk.java.net  Mon Jul 26 19:10:35 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 26 Jul 2021 19:10:35 GMT
Subject: <AWT Dev> RFR: 8269130: Replace usages of Collection.toArray()
 with Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <w-b3bQRsyksOmZlapJ8a175cxPbajxOHPK5bP2mmfJ0=.dbc900f7-9a03-4233-90dd-8853e410adb2@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

The changes to the security classes look good.

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

Marked as reviewed by mullan (Reviewer).

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

From github.com+2996845+bokken at openjdk.java.net  Mon Jul 26 19:18:33 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Mon, 26 Jul 2021 19:18:33 GMT
Subject: <AWT Dev> RFR: 8269130: Replace usages of Collection.toArray()
 with Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <amB5jIt1-LyF6A8_OxgTfO6tDKhujRwvnM1QYqPbzkU=.17cd1c88-0ff5-42f6-ad9b-53d5cbdd74e5@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/java.base/share/classes/java/security/Security.java line 656:

> 654:             return null;
> 655: 
> 656:         return candidates.toArray(new Provider[0]);

Is this called often enough to warrant creating a constant of `new Provider[0]` (benefits of this covered in the _Wisdom of the Ancients_ blog linked)?

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

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

From github.com+2996845+bokken at openjdk.java.net  Mon Jul 26 19:58:30 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Mon, 26 Jul 2021 19:58:30 GMT
Subject: <AWT Dev> RFR: 8269130: Replace usages of Collection.toArray()
 with Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <FRn0jQHYWMJL5GTfhu4TWGlg8OaBHVpEoIQ_pCka3rs=.151177ce-ac88-4932-b8c9-c6e59a148b5c@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/SystemDictionaryHelper.java line 92:

> 90:       }
> 91: 
> 92:       InstanceKlass[] searchResult = tmp.toArray(new InstanceKlass[0]);

Is it too far outside the scope of these changes to make `tmp` an `ArrayList` rather than a `Vector`?

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

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

From jwilhelm at openjdk.java.net  Tue Jul 27 00:10:16 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 27 Jul 2021 00:10:16 GMT
Subject: <AWT Dev> RFR: Merge jdk17
Message-ID: <rmPYopow6m6qUeF0DP4i-acFnpQd0VTpcseIIAYs4wo=.0950f0ed-c54f-4863-9cec-64ddbd8d9525@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8269150: UnicodeReader not translating \u005c\\u005d to \\]
 - 8271175: runtime/jni/FindClassUtf8/FindClassUtf8.java doesn't have to be run in othervm
 - 8271222: two runtime/Monitor tests don't check exit code
 - 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4907&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4907&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4907/files
  Stats: 118 lines in 6 files changed: 103 ins; 4 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4907/head:pull/4907

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

From jwilhelm at openjdk.java.net  Tue Jul 27 01:01:43 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 27 Jul 2021 01:01:43 GMT
Subject: <AWT Dev> Integrated: Merge jdk17
In-Reply-To: <rmPYopow6m6qUeF0DP4i-acFnpQd0VTpcseIIAYs4wo=.0950f0ed-c54f-4863-9cec-64ddbd8d9525@github.com>
References: <rmPYopow6m6qUeF0DP4i-acFnpQd0VTpcseIIAYs4wo=.0950f0ed-c54f-4863-9cec-64ddbd8d9525@github.com>
Message-ID: <-OT6zWAEV5o2OgQis1sjbtEDQD35nUYjxdaevupzDsg=.31df5a31-e2ba-4d9c-a682-275625c83bec@github.com>

On Tue, 27 Jul 2021 00:00:03 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: eb6da888
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eb6da88817f7bc903a51130271c9a5de928c603d
Stats:     118 lines in 6 files changed: 103 ins; 4 del; 11 mod

Merge

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

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

From yyang at openjdk.java.net  Tue Jul 27 02:49:33 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 27 Jul 2021 02:49:33 GMT
Subject: <AWT Dev> RFR: 8270058: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.desktop [v2]
In-Reply-To: <OEX8bbCcVIs1FJEdd3HpYZpK_nyLud01L0PlAPS00GE=.a4d079b9-95a2-48b3-b010-845d8491beae@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
 <B7Le6fXQ1ROPzwlmajQeqQdmcUfw3ITgZBS1oLdu34w=.430e6c64-1a2d-4a69-b0ef-9890765d572b@github.com>
 <joyBDgpS3uc_k11i-puUWSS0CZEPxRGgKy_E4KmgSfA=.e0e3890c-d8ce-475e-8501-2d14edefcad0@github.com>
 <CIuwP2aJ_IOxyn5pqM_hc2S5JCsSYPe-2IMdlZTHwE0=.2897eaa2-6b53-4b9a-bcbe-64e537fc3e78@github.com>
 <OEX8bbCcVIs1FJEdd3HpYZpK_nyLud01L0PlAPS00GE=.a4d079b9-95a2-48b3-b010-845d8491beae@github.com>
Message-ID: <Zk2MZzWq0Isv6RKpplh_WVEUbJCN9dMc847-sHEMg0o=.dbbce492-c7b8-4078-9ba7-08581bd490e6@github.com>

On Thu, 22 Jul 2021 06:35:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> checkFromToIndex? has different semantice with checkIndex:
>> 
>> - checkFromToIndex
>> 
>>      * <ul>
>>      *  <li>{@code fromIndex < 0}</li>
>>      *  <li>{@code fromIndex > toIndex}</li>
>>      *  <li>{@code toIndex > length}</li>
>>      *  <li>{@code length < 0}, which is implied from the former inequalities</li>
>>      * </ul>
>> 
>> - checkIndex
>> 
>>      * <ul>
>>      *  <li>{@code index < 0}</li>
>>      *  <li>{@code index >= length}</li>
>>      *  <li>{@code length < 0}, which is implied from the former inequalities</li>
>>      * </ul>
>> 
>> ---
>> 
>> The following tests are passed after applying this patch:
>> 
>> test/jdk/javax/imageio/AppletResourceTest.java
>> test/jdk/javax/imageio/ImageReaderReadAll.java
>> test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java
>> 
>> 
>> ClippedImages.java is a manual test, I have no environment to test it, but since it's a trivial replacement, I think it's okay..
>
> I meant 
> 
> if (imageIndex < minIndex)
>                     throw new IndexOutOfBoundsException();
> 
> can't it be replaced with Objects.checkFromToIndex(minIndex, imageIndex, ..

Hi, sorry for the late response. checkFromToIndex has many constraints, this code may not satisfy those constraints, so I don't think we should do that in this PR.(Maybe we can file a new PR to do replacement carefully)

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

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

From weijun at openjdk.java.net  Tue Jul 27 17:37:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 27 Jul 2021 17:37:34 GMT
Subject: <AWT Dev> Integrated: 8270859: Post JEP 411 refactoring: client
 libs with maximum covering > 10K
In-Reply-To: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
References: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
Message-ID: <262eSH5uEXtLA0bGhGMYjyvPH95AjMNDmIW0DIYp2Ao=.5cc95f00-e0b4-44fb-bf39-5077c10c96bc@github.com>

On Fri, 16 Jul 2021 20:52:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This is the last part of Post JEP 411 refactoring that makes `@SuppressWarnings("removal")` more fine grained. This fix deals with all client libs annotations that cover more than 10K bytes of code.

This pull request has now been integrated.

Changeset: 90cd2fa1
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/90cd2fa16458dcc3e36171fa4bf21f26bc92b168
Stats:     283 lines in 22 files changed: 147 ins; 98 del; 38 mod

8270859: Post JEP 411 refactoring: client libs with maximum covering > 10K

Reviewed-by: serb

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

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

From github.com+54304+ebourg at openjdk.java.net  Wed Jul 28 15:39:47 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Wed, 28 Jul 2021 15:39:47 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors
Message-ID: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>

This PR fixes the following spelling errors:

 choosen  -> chosen
 commad   -> command
 hiearchy -> hierarchy
 leagacy  -> legacy
 minium   -> minimum
 subsytem -> subsystem
 unamed   -> unnamed

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

Commit messages:
 - 8271396: Fix spelling errors

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

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

From tschatzl at openjdk.java.net  Wed Jul 28 15:39:47 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 28 Jul 2021 15:39:47 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <qaXW0F5RvHQkbBOCClYDaM8g9-AwsGvhfPZT1ALfL8I=.eefdf486-3f44-42bf-a004-c379b6b3c666@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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

From yyang at openjdk.java.net  Wed Jul 28 15:39:48 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 28 Jul 2021 15:39:48 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <QVfb9Ia0KIhLqsqLTdMA1CU7UWY_o9DK_5BZaQt5oxs=.2f3b25f4-3f0d-42ca-b56a-109c2a1c2349@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Hi, I've filed https://bugs.openjdk.java.net/browse/JDK-8271396 for this PR, you can change the title to "8271396: Spelling errors", openjdk bot will link this PR to the corresponding issue. Also you should resolve conflicts and pass jcheck before integrating it.

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

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

From chegar at openjdk.java.net  Wed Jul 28 15:39:48 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Jul 2021 15:39:48 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <XjTat5FN7Pxw0RoEY4EmHVk_ItIxt5MZllXtrHVCQvc=.e4dcfdb0-4c77-4723-a216-4e4eb87d5340@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Trivially, looks ok to me.

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

Marked as reviewed by chegar (Reviewer).

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

From github.com+54304+ebourg at openjdk.java.net  Wed Jul 28 15:39:48 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Wed, 28 Jul 2021 15:39:48 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <10SItkPG_iJXTz8Ya0h8wBgoiXRl-aki9ADR8U_jaj8=.f3b7b05e-2b91-4522-9f7f-4b2ea97c8a50@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

.

.

Thank you!

The PR has been updated

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

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

From psadhukhan at openjdk.java.net  Wed Jul 28 16:17:31 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 28 Jul 2021 16:17:31 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <Bq3Nm1ILzw1TRD2bA2FpFLsnzuNxAffRspEOokAcBrs=.3c5c2746-d279-4db6-9c7a-47c551e8a1c1@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Thanks for awt/swing correction.

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

Marked as reviewed by psadhukhan (Reviewer).

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

From iris at openjdk.java.net  Wed Jul 28 16:17:31 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 28 Jul 2021 16:17:31 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <IzhHnS2Nir_azY-2MIv9m9UHxi2pQHE1mNxQw2f9nW4=.6a615f55-a7b1-4a81-9c91-57bd6e3fa7fa@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Marked as reviewed by iris (Reviewer).

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

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

From cjplummer at openjdk.java.net  Wed Jul 28 16:25:32 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 28 Jul 2021 16:25:32 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <mF8f_Z4TdIttsMV7_J2yms_a3_eM2qHCbjnHs3XYpwI=.caae749d-6dfa-4be0-b459-2e69cd4d1662@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

jdi, jvmti, and dcmd related changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

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

From jboes at openjdk.java.net  Wed Jul 28 16:29:29 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Wed, 28 Jul 2021 16:29:29 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

I'm happy to sponsor this change, but could you please update the copyright year where necessary, e.g. in 
src/java.desktop/unix/classes/sun/awt/X11/XMSelection.java: 
`Copyright (c) 2003, 2018, Oracle...` -> `Copyright (c) 2003, 2021, Oracle...`

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

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

From github.com+54304+ebourg at openjdk.java.net  Wed Jul 28 17:12:04 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Wed, 28 Jul 2021 17:12:04 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors [v2]
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <axOY0lG3CInpykz-_Ur_wY8dRvr4QsfktJ9gD0vvirA=.c8302d67-79c3-4e99-853c-65701d049c4a@github.com>

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

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

  8271396: Fix spelling errors
  
   choosen  -> chosen
   commad   -> command
   hiearchy -> hierarchy
   leagacy  -> legacy
   minium   -> minimum
   subsytem -> subsystem
   unamed   -> unnamed

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2385/files
  - new: https://git.openjdk.java.net/jdk/pull/2385/files/31cfcba7..6e1be4f6

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

  Stats: 61642 lines in 1361 files changed: 29147 ins; 26026 del; 6469 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2385.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2385/head:pull/2385

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

From github.com+54304+ebourg at openjdk.java.net  Wed Jul 28 17:12:05 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Wed, 28 Jul 2021 17:12:05 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors
In-Reply-To: <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>
Message-ID: <ECY56wmiBbQOh06b4r_yI7IykEom57iFFgIQNnhQMGY=.a16517dc-67bc-43a6-b0ef-d1eab0d6970a@github.com>

On Wed, 28 Jul 2021 16:26:49 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> This PR fixes the following spelling errors:
>> 
>>  choosen  -> chosen
>>  commad   -> command
>>  hiearchy -> hierarchy
>>  leagacy  -> legacy
>>  minium   -> minimum
>>  subsytem -> subsystem
>>  unamed   -> unnamed
>
> I'm happy to sponsor this change, but could you please update the copyright year where necessary, e.g. in 
> src/java.desktop/unix/classes/sun/awt/X11/XMSelection.java: 
> `Copyright (c) 2003, 2018, Oracle...` -> `Copyright (c) 2003, 2021, Oracle...`

@FrauBoes thank you, the PR has been updated to modify the copyright year

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

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

From github.com+42199859+nikolaytach at openjdk.java.net  Wed Jul 28 17:21:30 2021
From: github.com+42199859+nikolaytach at openjdk.java.net (NikolayTach)
Date: Wed, 28 Jul 2021 17:21:30 GMT
Subject: <AWT Dev> RFR: 8181571: printing to CUPS fails on mac sandbox
 app
In-Reply-To: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
Message-ID: <63JwCGX6p50e5FOnMIuUEOUKrfIm4HkJXEO55VBeHWg=.ea74605e-ff56-4526-b2f8-a5d5f1fd8995@github.com>

On Wed, 21 Jul 2021 15:45:55 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
> 
> Create a native macOS app from the Hello.java file, sign and run it in sandbox:
> 
> import javax.print.*;
> import javax.swing.*;
> 
> public class Hello {
> 
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeAndWait(() -> {
>             boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null;
>             PrintService defaultPrinter = PrintServiceLookup.lookupDefaultPrintService();
>             PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null);
> 
>             StringBuilder builder = new StringBuilder();
>             builder.append("is sandboxed: ").append(isSandboxed).append("\n");
>             builder.append("default printer: ").append(defaultPrinter).append("\n");
>             int size = services.length;
>             for (int i = 0; i < size; i++) {
>                 builder.append("printer[").append(i).append("]=").append(services[i]).append("\n");
>             }
>             JOptionPane.showMessageDialog(null, builder.toString());
>         });
>     }
> }
> 
> The signed app in sandbox shows null default printer and PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp".
> ![PrintSandboxedApp](https://bugs.openjdk.java.net/secure/attachment/95629/PrintSandboxedApp.png)
> 
> The problem has been discussed on  2d-dev mail list:
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html
> 
> According to the discussion:
> 
>> I've submitted a DTS incident to Apple and a friend there has followed-up.
>> Their unofficial position is that java should be connecting to the cups interface returned
>> by the cupsServer() function and not changing the interface string to "localhost".
>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>> network-client access with print access.  They don't seem interested in loosening that change.
> 
> 
> The proposed solution is to use the domain socket pathname in httpConnect(...) cups function and cupsGetDests(...) to get list of printers from cups  when the app is signed and is run in sandbox on MacOs.

[JDK-8247768 ](https://bugs.openjdk.java.net/browse/JDK-8247768)
Same here played 6 times yet moved, 8 issues missed.

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

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

From kcr at openjdk.java.net  Wed Jul 28 17:26:35 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 28 Jul 2021 17:26:35 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors
In-Reply-To: <ECY56wmiBbQOh06b4r_yI7IykEom57iFFgIQNnhQMGY=.a16517dc-67bc-43a6-b0ef-d1eab0d6970a@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>
 <ECY56wmiBbQOh06b4r_yI7IykEom57iFFgIQNnhQMGY=.a16517dc-67bc-43a6-b0ef-d1eab0d6970a@github.com>
Message-ID: <c8D3av6T1vVqUc0YgytVzPMZoVwmk3pAQwgCU9OaTGY=.88b57352-b1a0-4563-b651-6f624560dbe7@github.com>

On Wed, 28 Jul 2021 17:08:01 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

>> I'm happy to sponsor this change, but could you please update the copyright year where necessary, e.g. in 
>> src/java.desktop/unix/classes/sun/awt/X11/XMSelection.java: 
>> `Copyright (c) 2003, 2018, Oracle...` -> `Copyright (c) 2003, 2021, Oracle...`
>
> @FrauBoes thank you, the PR has been updated to modify the copyright year

@ebourg for future PRs please do not force push after the PR is out for review. Just push incremental commits normally. The Skara tooling will squash them all into a single commit.

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

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

From iris at openjdk.java.net  Wed Jul 28 17:26:34 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 28 Jul 2021 17:26:34 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors [v2]
In-Reply-To: <axOY0lG3CInpykz-_Ur_wY8dRvr4QsfktJ9gD0vvirA=.c8302d67-79c3-4e99-853c-65701d049c4a@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <axOY0lG3CInpykz-_Ur_wY8dRvr4QsfktJ9gD0vvirA=.c8302d67-79c3-4e99-853c-65701d049c4a@github.com>
Message-ID: <creDetfFbVTSBqmvtf65RTiUEBDK2hFEh5ESw38QR-4=.3c2ecc4a-82a8-4aa7-ae79-efe2363e68d6@github.com>

On Wed, 28 Jul 2021 17:12:04 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

>> This PR fixes the following spelling errors:
>> 
>>  choosen  -> chosen
>>  commad   -> command
>>  hiearchy -> hierarchy
>>  leagacy  -> legacy
>>  minium   -> minimum
>>  subsytem -> subsystem
>>  unamed   -> unnamed
>
> Emmanuel Bourg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
> 
>   8271396: Fix spelling errors
>   
>    choosen  -> chosen
>    commad   -> command
>    hiearchy -> hierarchy
>    leagacy  -> legacy
>    minium   -> minimum
>    subsytem -> subsystem
>    unamed   -> unnamed

Marked as reviewed by iris (Reviewer).

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

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

From github.com+54304+ebourg at openjdk.java.net  Wed Jul 28 17:26:35 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Wed, 28 Jul 2021 17:26:35 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors
In-Reply-To: <c8D3av6T1vVqUc0YgytVzPMZoVwmk3pAQwgCU9OaTGY=.88b57352-b1a0-4563-b651-6f624560dbe7@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>
 <ECY56wmiBbQOh06b4r_yI7IykEom57iFFgIQNnhQMGY=.a16517dc-67bc-43a6-b0ef-d1eab0d6970a@github.com>
 <c8D3av6T1vVqUc0YgytVzPMZoVwmk3pAQwgCU9OaTGY=.88b57352-b1a0-4563-b651-6f624560dbe7@github.com>
Message-ID: <al0SRVpmZ3Jta5hZkVrGWCBNM9X330njP-87Gtj2Xrk=.d7a1bea3-1b54-4084-be08-831b4eff898b@github.com>

On Wed, 28 Jul 2021 17:20:37 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @FrauBoes thank you, the PR has been updated to modify the copyright year
>
> @ebourg for future PRs please do not force push after the PR is out for review. Just push incremental commits normally. The Skara tooling will squash them all into a single commit.

@kevinrushforth I'll do that, thank you for the hint

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

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

From avu at openjdk.java.net  Wed Jul 28 17:39:32 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 28 Jul 2021 17:39:32 GMT
Subject: <AWT Dev> [jdk17] Withdrawn: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <-RHSKRSUc959ZIAuVN8HO1tafeIJasE93vWBC5q631E=.38c3347e-61c5-4f77-a2fa-3e08a40164df@github.com>

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

> Implemented blit via compute kernel

This pull request has been closed without being integrated.

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

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

From avu at openjdk.java.net  Wed Jul 28 17:39:32 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 28 Jul 2021 17:39:32 GMT
Subject: <AWT Dev> [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL [v5]
In-Reply-To: <pppqA2YSjwiNvZPnUOul1cXtmDA_w0kgxkfv6rvV87A=.18e56cea-d453-4e6d-b87b-15fd696c3ea0@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <pppqA2YSjwiNvZPnUOul1cXtmDA_w0kgxkfv6rvV87A=.18e56cea-d453-4e6d-b87b-15fd696c3ea0@github.com>
Message-ID: <raRHKGVqYa7QUwKy_5ooFVkTQ4EiXr_FTMLrF3Ku_OQ=.ea6fccd4-fc3a-4022-8da6-8fb775bed634@github.com>

On Mon, 5 Jul 2021 15:55:20 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Minor cleanup

Moving this request to jdk18

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

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

From jboes at openjdk.java.net  Thu Jul 29 15:58:29 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Thu, 29 Jul 2021 15:58:29 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors
In-Reply-To: <al0SRVpmZ3Jta5hZkVrGWCBNM9X330njP-87Gtj2Xrk=.d7a1bea3-1b54-4084-be08-831b4eff898b@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>
 <ECY56wmiBbQOh06b4r_yI7IykEom57iFFgIQNnhQMGY=.a16517dc-67bc-43a6-b0ef-d1eab0d6970a@github.com>
 <c8D3av6T1vVqUc0YgytVzPMZoVwmk3pAQwgCU9OaTGY=.88b57352-b1a0-4563-b651-6f624560dbe7@github.com>
 <al0SRVpmZ3Jta5hZkVrGWCBNM9X330njP-87Gtj2Xrk=.d7a1bea3-1b54-4084-be08-831b4eff898b@github.com>
Message-ID: <6pKjSeljbRVUY95MMl6XydDzNvJde-Pa1DSN6OfM7mM=.8b5ea3f5-dce4-49d3-8090-023734e19061@github.com>

On Wed, 28 Jul 2021 17:23:51 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

>> @ebourg for future PRs please do not force push after the PR is out for review. Just push incremental commits normally. The Skara tooling will squash them all into a single commit.
>
> @kevinrushforth I'll do that, thank you for the hint

@ebourg Thanks for updating the copyright. If you integrate again, I can sponsor.

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

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

From github.com+54304+ebourg at openjdk.java.net  Thu Jul 29 16:06:37 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Thu, 29 Jul 2021 16:06:37 GMT
Subject: <AWT Dev> Integrated: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <9uAMUJBjsby1KkwiwU8wrYEw0ozGjXD7Xnjil0nLoXg=.fd3b9a16-c42a-4806-a174-8b6b0b565abb@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

This pull request has now been integrated.

Changeset: d09b0284
Author:    Emmanuel Bourg <ebourg at apache.org>
Committer: Julia Boes <jboes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d09b028407ff9d0e8c2dfd9cc5d0dca19c4497e3
Stats:     103 lines in 34 files changed: 0 ins; 0 del; 103 mod

8271396: Spelling errors

Reviewed-by: tschatzl, chegar, iris, psadhukhan, cjplummer

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

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

From github.com+54304+ebourg at openjdk.java.net  Thu Jul 29 16:11:36 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Thu, 29 Jul 2021 16:11:36 GMT
Subject: <AWT Dev> RFR: 8271396: Spelling errors [v2]
In-Reply-To: <axOY0lG3CInpykz-_Ur_wY8dRvr4QsfktJ9gD0vvirA=.c8302d67-79c3-4e99-853c-65701d049c4a@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <axOY0lG3CInpykz-_Ur_wY8dRvr4QsfktJ9gD0vvirA=.c8302d67-79c3-4e99-853c-65701d049c4a@github.com>
Message-ID: <1IourDXaaOqLbUP1_8BfEui3NErozrWkUoBcYUmYAx8=.82ca7fd0-732d-41ab-ad90-8e77412b8ac2@github.com>

On Wed, 28 Jul 2021 17:12:04 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

>> This PR fixes the following spelling errors:
>> 
>>  choosen  -> chosen
>>  commad   -> command
>>  hiearchy -> hierarchy
>>  leagacy  -> legacy
>>  minium   -> minimum
>>  subsytem -> subsystem
>>  unamed   -> unnamed
>
> Emmanuel Bourg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
> 
>   8271396: Fix spelling errors
>   
>    choosen  -> chosen
>    commad   -> command
>    hiearchy -> hierarchy
>    leagacy  -> legacy
>    minium   -> minimum
>    subsytem -> subsystem
>    unamed   -> unnamed

Thank you, glad to land my first commit to OpenJDK

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

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

From rriggs at openjdk.java.net  Thu Jul 29 16:44:55 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 29 Jul 2021 16:44:55 GMT
Subject: <AWT Dev> [jdk17] RFR: 8271489: (doc) Clarify Filter Factory example
Message-ID: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com>

Improve the clarity of comments in the ObjectInputFilter FilterInThread example.

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

Commit messages:
 - 8271489: (doc) Clarify Filter Factory example
 - 8270398: Enhance canonicalization
 - 8270404: Better canonicalization
 - Merge
 - Merge
 - 8263531: Remove unused buffer int
 - 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print"
 - 8269763: The JEditorPane is blank after JDK-8265167
 - 8265580: Enhanced style for RTF kit
 - 8265574: Improve handling of sheets
 - ... and 15 more: https://git.openjdk.java.net/jdk17/compare/c1304519...650e1561

Changes: https://git.openjdk.java.net/jdk17/pull/292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=292&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271489
  Stats: 1001 lines in 42 files changed: 625 ins; 181 del; 195 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/292/head:pull/292

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

From rriggs at openjdk.java.net  Thu Jul 29 17:46:36 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 29 Jul 2021 17:46:36 GMT
Subject: <AWT Dev> [jdk17] Withdrawn: 8271489: (doc) Clarify Filter Factory
 example
In-Reply-To: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com>
References: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com>
Message-ID: <4o8A0bH9cVUSjB1lO6rW6Z3QT1KTxpu9Z0IaWK3c_-g=.25c55618-f4b9-46d6-9e4e-39674df24ca9@github.com>

On Thu, 29 Jul 2021 16:36:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Improve the clarity of comments in the ObjectInputFilter FilterInThread example.

This pull request has been closed without being integrated.

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

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

From github.com+79671271+rajamah at openjdk.java.net  Thu Jul 29 20:37:40 2021
From: github.com+79671271+rajamah at openjdk.java.net (rajat mahajan)
Date: Thu, 29 Jul 2021 20:37:40 GMT
Subject: <AWT Dev> RFR: 8270116: Expand ButtonGroupLayoutTraversalTest.java
 to run in all LaFs, including Aqua on macOS
Message-ID: <W674uo89BrLgg2_mYlucUaK2SN4GYUhZ2ZHQ9DL-UfA=.609b27fb-1fa5-4740-95de-c56913c32f01@github.com>

Summary: Expanded ButtonGroupLayoutTraversalTest.java to run in all LAFs on all OS. Added synchronization for focusCnt.

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

Commit messages:
 - 8270116: Expand ButtonGroupLayoutTraversalTest.java to run in all LaFs, including Aqua on macOS

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

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

From psadhukhan at openjdk.java.net  Fri Jul 30 05:43:27 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 30 Jul 2021 05:43:27 GMT
Subject: <AWT Dev> RFR: 8270116: Expand
 ButtonGroupLayoutTraversalTest.java to run in all LaFs,
 including Aqua on macOS
In-Reply-To: <W674uo89BrLgg2_mYlucUaK2SN4GYUhZ2ZHQ9DL-UfA=.609b27fb-1fa5-4740-95de-c56913c32f01@github.com>
References: <W674uo89BrLgg2_mYlucUaK2SN4GYUhZ2ZHQ9DL-UfA=.609b27fb-1fa5-4740-95de-c56913c32f01@github.com>
Message-ID: <pVnN4MnA9T8p44os16WOK9Oh-Pe5RGLzuMmgSTcqMVM=.1e602fa4-684e-4df6-82b5-278660f86b43@github.com>

On Thu, 29 Jul 2021 20:29:31 GMT, rajat mahajan <github.com+79671271+rajamah at openjdk.org> wrote:

> Summary: Expanded ButtonGroupLayoutTraversalTest.java to run in all LAFs on all OS. Added synchronization for focusCnt.

Also, please give a CI run of this test running for several iterations(20+) for all platforms since it's supposed to be run in all L&Fs and post in JBS.

test/jdk/java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java line 54:

> 52: public class ButtonGroupLayoutTraversalTest {
> 53: 
> 54:     private static final int nx = 3;

Normally, as per coding standard, for static final modifier, the variable should be named in CAPS...but is there any need of making it final?

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

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

From psadhukhan at openjdk.java.net  Fri Jul 30 06:26:31 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 30 Jul 2021 06:26:31 GMT
Subject: <AWT Dev> RFR: 8270058: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.desktop [v2]
In-Reply-To: <Zk2MZzWq0Isv6RKpplh_WVEUbJCN9dMc847-sHEMg0o=.dbbce492-c7b8-4078-9ba7-08581bd490e6@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
 <B7Le6fXQ1ROPzwlmajQeqQdmcUfw3ITgZBS1oLdu34w=.430e6c64-1a2d-4a69-b0ef-9890765d572b@github.com>
 <joyBDgpS3uc_k11i-puUWSS0CZEPxRGgKy_E4KmgSfA=.e0e3890c-d8ce-475e-8501-2d14edefcad0@github.com>
 <CIuwP2aJ_IOxyn5pqM_hc2S5JCsSYPe-2IMdlZTHwE0=.2897eaa2-6b53-4b9a-bcbe-64e537fc3e78@github.com>
 <OEX8bbCcVIs1FJEdd3HpYZpK_nyLud01L0PlAPS00GE=.a4d079b9-95a2-48b3-b010-845d8491beae@github.com>
 <Zk2MZzWq0Isv6RKpplh_WVEUbJCN9dMc847-sHEMg0o=.dbbce492-c7b8-4078-9ba7-08581bd490e6@github.com>
Message-ID: <dz4S3m8te2ooSPdzIxbJEF_5Z7A09_kuaQzIWN0hHF0=.05c8f028-28ab-4350-80e8-0998048512de@github.com>

On Tue, 27 Jul 2021 02:46:53 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> I meant 
>> 
>> if (imageIndex < minIndex)
>>                     throw new IndexOutOfBoundsException();
>> 
>> can't it be replaced with Objects.checkFromToIndex(minIndex, imageIndex, ..
>
> Hi, sorry for the late response. checkFromToIndex has many constraints, this code may not satisfy those constraints, so I don't think we should do that in this PR.(Maybe we can file a new PR to do replacement carefully)

OK...The subject line of this PR states that checkFromToIndex will also be used but I see only checkIndex so I intervened. Anyways, the code in question is in test so not much of an issue.

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

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

From psadhukhan at openjdk.java.net  Fri Jul 30 06:26:31 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 30 Jul 2021 06:26:31 GMT
Subject: <AWT Dev> RFR: 8270058: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.desktop [v3]
In-Reply-To: <FBiKIDgqehM1qVz94eqqkPEyXPKzc-X9qY6lz_zIXsU=.65ecec40-aa0a-4682-9c48-83a1b638abb5@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
 <FBiKIDgqehM1qVz94eqqkPEyXPKzc-X9qY6lz_zIXsU=.65ecec40-aa0a-4682-9c48-83a1b638abb5@github.com>
Message-ID: <RckbR8wluUnw_71iYHGrV42dISnT7_tXv9OrCJistqA=.0aa8f384-b062-4c42-9747-889a785c8e15@github.com>

On Thu, 22 Jul 2021 06:29:13 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>> 
>> As Mandy suggested, I create this PR for changes involving client code:
>> 
>> src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java
>> src/java.desktop/share/classes/javax/swing/JTabbedPane.java
>> test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
>> test/jdk/javax/imageio/AppletResourceTest.java
>> test/jdk/javax/imageio/ImageReaderReadAll.java
>> test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Marked as reviewed by psadhukhan (Reviewer).

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

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

From yyang at openjdk.java.net  Fri Jul 30 07:21:29 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 30 Jul 2021 07:21:29 GMT
Subject: <AWT Dev> RFR: 8270058: Use Objects.check{Index,
 FromIndexSize} for java.desktop [v2]
In-Reply-To: <dz4S3m8te2ooSPdzIxbJEF_5Z7A09_kuaQzIWN0hHF0=.05c8f028-28ab-4350-80e8-0998048512de@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
 <B7Le6fXQ1ROPzwlmajQeqQdmcUfw3ITgZBS1oLdu34w=.430e6c64-1a2d-4a69-b0ef-9890765d572b@github.com>
 <joyBDgpS3uc_k11i-puUWSS0CZEPxRGgKy_E4KmgSfA=.e0e3890c-d8ce-475e-8501-2d14edefcad0@github.com>
 <CIuwP2aJ_IOxyn5pqM_hc2S5JCsSYPe-2IMdlZTHwE0=.2897eaa2-6b53-4b9a-bcbe-64e537fc3e78@github.com>
 <OEX8bbCcVIs1FJEdd3HpYZpK_nyLud01L0PlAPS00GE=.a4d079b9-95a2-48b3-b010-845d8491beae@github.com>
 <Zk2MZzWq0Isv6RKpplh_WVEUbJCN9dMc847-sHEMg0o=.dbbce492-c7b8-4078-9ba7-08581bd490e6@github.com>
 <dz4S3m8te2ooSPdzIxbJEF_5Z7A09_kuaQzIWN0hHF0=.05c8f028-28ab-4350-80e8-0998048512de@github.com>
Message-ID: <kp9K4KnMSn7ys_DvkXpEYppimDwEDi5MIBppCc0G9C0=.7bcdca48-0dfd-4dc2-b230-5e34f5cb1140@github.com>

On Fri, 30 Jul 2021 06:23:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Hi, sorry for the late response. checkFromToIndex has many constraints, this code may not satisfy those constraints, so I don't think we should do that in this PR.(Maybe we can file a new PR to do replacement carefully)
>
> OK...The subject line of this PR states that checkFromToIndex will also be used but I see only checkIndex so I intervened. Anyways, the code in question is in test so not much of an issue.

Thanks @prsadhuk for review! I've updated the title to exclude checkFromToIndex.

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

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

From jdv at openjdk.java.net  Fri Jul 30 08:20:32 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Fri, 30 Jul 2021 08:20:32 GMT
Subject: <AWT Dev> RFR: 8270058: Use Objects.check{Index,
 FromIndexSize} for java.desktop [v3]
In-Reply-To: <FBiKIDgqehM1qVz94eqqkPEyXPKzc-X9qY6lz_zIXsU=.65ecec40-aa0a-4682-9c48-83a1b638abb5@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
 <FBiKIDgqehM1qVz94eqqkPEyXPKzc-X9qY6lz_zIXsU=.65ecec40-aa0a-4682-9c48-83a1b638abb5@github.com>
Message-ID: <kD-P18tO8LtPFWAUjFH8yQ7aq_L6h_0i8hQVYfXcdsg=.87d4c55d-f688-4dcf-b415-1bd20410a952@github.com>

On Thu, 22 Jul 2021 06:29:13 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>> 
>> As Mandy suggested, I create this PR for changes involving client code:
>> 
>> src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java
>> src/java.desktop/share/classes/javax/swing/JTabbedPane.java
>> test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
>> test/jdk/javax/imageio/AppletResourceTest.java
>> test/jdk/javax/imageio/ImageReaderReadAll.java
>> test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

src/java.desktop/share/classes/javax/swing/JTabbedPane.java line 1793:

> 1791: 
> 1792:     private void checkIndex(int index) {
> 1793:         Objects.checkIndex(index, pages.size());

I think we should not replace IOOBE checks with messages. Its better to keep it old way.

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

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

From pbansal at openjdk.java.net  Fri Jul 30 08:44:31 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 30 Jul 2021 08:44:31 GMT
Subject: <AWT Dev> RFR: 8270058: Use Objects.check{Index,
 FromIndexSize} for java.desktop [v3]
In-Reply-To: <kD-P18tO8LtPFWAUjFH8yQ7aq_L6h_0i8hQVYfXcdsg=.87d4c55d-f688-4dcf-b415-1bd20410a952@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
 <FBiKIDgqehM1qVz94eqqkPEyXPKzc-X9qY6lz_zIXsU=.65ecec40-aa0a-4682-9c48-83a1b638abb5@github.com>
 <kD-P18tO8LtPFWAUjFH8yQ7aq_L6h_0i8hQVYfXcdsg=.87d4c55d-f688-4dcf-b415-1bd20410a952@github.com>
Message-ID: <P2bSP34audQsf17W2PG7hwz4kpBsCA3eeFPTuskBLhU=.e169a20e-8ca8-422c-877e-9fadb0e219ef@github.com>

On Fri, 30 Jul 2021 08:17:29 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo
>
> src/java.desktop/share/classes/javax/swing/JTabbedPane.java line 1793:
> 
>> 1791: 
>> 1792:     private void checkIndex(int index) {
>> 1793:         Objects.checkIndex(index, pages.size());
> 
> I think we should not replace IOOBE checks with messages. Its better to keep it old way.

Objects.checkIndex itself throws exceptions for wrong values. So this should be ok. No?

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

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

From pbansal at openjdk.java.net  Fri Jul 30 08:44:29 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 30 Jul 2021 08:44:29 GMT
Subject: <AWT Dev> RFR: 8270058: Use Objects.check{Index,
 FromIndexSize} for java.desktop [v3]
In-Reply-To: <FBiKIDgqehM1qVz94eqqkPEyXPKzc-X9qY6lz_zIXsU=.65ecec40-aa0a-4682-9c48-83a1b638abb5@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
 <FBiKIDgqehM1qVz94eqqkPEyXPKzc-X9qY6lz_zIXsU=.65ecec40-aa0a-4682-9c48-83a1b638abb5@github.com>
Message-ID: <WvB9Q3sZA1YFMVnipNmz2TAXWW3jpu_WFf_9H2_sEwY=.01647cef-4d83-4db1-8d7b-3d9981805ab9@github.com>

On Thu, 22 Jul 2021 06:29:13 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>> 
>> As Mandy suggested, I create this PR for changes involving client code:
>> 
>> src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java
>> src/java.desktop/share/classes/javax/swing/JTabbedPane.java
>> test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
>> test/jdk/javax/imageio/AppletResourceTest.java
>> test/jdk/javax/imageio/ImageReaderReadAll.java
>> test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Looks ok to me

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

Marked as reviewed by pbansal (Reviewer).

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

From jdv at openjdk.java.net  Fri Jul 30 09:02:32 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Fri, 30 Jul 2021 09:02:32 GMT
Subject: <AWT Dev> RFR: 8270058: Use Objects.check{Index,
 FromIndexSize} for java.desktop [v3]
In-Reply-To: <P2bSP34audQsf17W2PG7hwz4kpBsCA3eeFPTuskBLhU=.e169a20e-8ca8-422c-877e-9fadb0e219ef@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
 <FBiKIDgqehM1qVz94eqqkPEyXPKzc-X9qY6lz_zIXsU=.65ecec40-aa0a-4682-9c48-83a1b638abb5@github.com>
 <kD-P18tO8LtPFWAUjFH8yQ7aq_L6h_0i8hQVYfXcdsg=.87d4c55d-f688-4dcf-b415-1bd20410a952@github.com>
 <P2bSP34audQsf17W2PG7hwz4kpBsCA3eeFPTuskBLhU=.e169a20e-8ca8-422c-877e-9fadb0e219ef@github.com>
Message-ID: <Sj1ctbhJEOMTbZQwEdJmjz28i0AAbwNoUnXm9a6fOxA=.90f0249c-06f9-40fb-8fcf-40351a82b919@github.com>

On Fri, 30 Jul 2021 08:40:34 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JTabbedPane.java line 1793:
>> 
>>> 1791: 
>>> 1792:     private void checkIndex(int index) {
>>> 1793:         Objects.checkIndex(index, pages.size());
>> 
>> I think we should not replace IOOBE checks with messages. Its better to keep it old way.
>
> Objects.checkIndex itself throws exceptions for wrong values. So this should be ok. No?

We have specific message here like "Tab count" which we are not passing and will be helpful for debugging in future.

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

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

From avu at openjdk.java.net  Fri Jul 30 15:48:50 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 30 Jul 2021 15:48:50 GMT
Subject: <AWT Dev> RFR: 8266079: Lanai: AlphaComposite shows differences on
 Metal compared to OpenGL
Message-ID: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com>

Keep MTLLayer opacity in sync with window content view
Keep layer translucent for translucent windows

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

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

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

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

From aivanov at openjdk.java.net  Fri Jul 30 19:14:30 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 30 Jul 2021 19:14:30 GMT
Subject: <AWT Dev> RFR: 8270116: Expand
 ButtonGroupLayoutTraversalTest.java to run in all LaFs,
 including Aqua on macOS
In-Reply-To: <W674uo89BrLgg2_mYlucUaK2SN4GYUhZ2ZHQ9DL-UfA=.609b27fb-1fa5-4740-95de-c56913c32f01@github.com>
References: <W674uo89BrLgg2_mYlucUaK2SN4GYUhZ2ZHQ9DL-UfA=.609b27fb-1fa5-4740-95de-c56913c32f01@github.com>
Message-ID: <Wmb2ZwzXkvXsbBuM8ENeGqNOp5reSxSO_8AoCjt0ApE=.069484ef-702b-48cb-97b7-0ba5f410a778@github.com>

On Thu, 29 Jul 2021 20:29:31 GMT, rajat mahajan <github.com+79671271+rajamah at openjdk.org> wrote:

> Summary: Expanded ButtonGroupLayoutTraversalTest.java to run in all LAFs on all OS. Added synchronization for focusCnt.

Looks good to me.

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

Marked as reviewed by aivanov (Reviewer).

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

From github.com+79671271+rajamah at openjdk.java.net  Fri Jul 30 19:48:31 2021
From: github.com+79671271+rajamah at openjdk.java.net (rajat mahajan)
Date: Fri, 30 Jul 2021 19:48:31 GMT
Subject: <AWT Dev> RFR: 8270116: Expand
 ButtonGroupLayoutTraversalTest.java to run in all LaFs,
 including Aqua on macOS
In-Reply-To: <pVnN4MnA9T8p44os16WOK9Oh-Pe5RGLzuMmgSTcqMVM=.1e602fa4-684e-4df6-82b5-278660f86b43@github.com>
References: <W674uo89BrLgg2_mYlucUaK2SN4GYUhZ2ZHQ9DL-UfA=.609b27fb-1fa5-4740-95de-c56913c32f01@github.com>
 <pVnN4MnA9T8p44os16WOK9Oh-Pe5RGLzuMmgSTcqMVM=.1e602fa4-684e-4df6-82b5-278660f86b43@github.com>
Message-ID: <9UbJnz-s7pS5x_kKR-7i0HNbEN_DV8L_F-sBncyqEaI=.25159e10-dbb5-47ec-a2a7-dc1c44d1dc99@github.com>

On Fri, 30 Jul 2021 05:35:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Summary: Expanded ButtonGroupLayoutTraversalTest.java to run in all LAFs on all OS. Added synchronization for focusCnt.
>
> test/jdk/java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java line 54:
> 
>> 52: public class ButtonGroupLayoutTraversalTest {
>> 53: 
>> 54:     private static final int nx = 3;
> 
> Normally, as per coding standard, for static final modifier, the variable should be named in CAPS...but is there any need of making it final?

Ran test 20 times on all OS and it passed, posted link in JBS. I avoided changing to CAPS to prevent code change noise and final is done since these variable values don't change or are constant throughout the code and we want it that way.

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

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