From serb at openjdk.java.net  Mon Nov  2 09:18:04 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 09:18:04 GMT
Subject: <AWT Dev> RFR: 8211958: Broken links in java.desktop files
In-Reply-To: <sFnwpabh_Xf5-cpvaIRcW_5pBNaLYnPikdMBjWNrhgU=.86892be0-c298-4c4e-9c7a-504521d638f8@github.com>
References: <sFnwpabh_Xf5-cpvaIRcW_5pBNaLYnPikdMBjWNrhgU=.86892be0-c298-4c4e-9c7a-504521d638f8@github.com>
Message-ID: <419qL9UPahnCzXx_oOMJVGD_ZT3xVzvYCz7M4m0hTBE=.0cd2c408-3de5-4baf-866c-407219a4c96c@github.com>

On Mon, 2 Nov 2020 09:04:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Most of the broken links were fixed already by the JDK-8225368 and JDK-8214817
> This change fix just a few.
> 
> Also two cleanups are applied:
>  - The `../../java/awt/doc-files/` in some cases simplified to `doc-files/`
>  - The html links to the java classes via `<a href>` replaced by the `{@link }`

src/java.desktop/share/classes/java/awt/doc-files/DesktopProperties.html line 101:

> 99: 
> 100: The return value is a
> 101: <a href="../../util/Map.html"> Map</a> of

Broken link to Map.

src/java.desktop/share/classes/javax/print/DocFlavor.java line 159:

> 157:  * common flavors, the pre-defined *HOST {@code DocFlavors} may be used.
> 158:  * <p>
> 159:  * See <a href="../../java/lang/package-summary.html#charenc">character

Broken link to the java.base module

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

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

From serb at openjdk.java.net  Mon Nov  2 09:18:03 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 09:18:03 GMT
Subject: <AWT Dev> RFR: 8211958: Broken links in java.desktop files
Message-ID: <sFnwpabh_Xf5-cpvaIRcW_5pBNaLYnPikdMBjWNrhgU=.86892be0-c298-4c4e-9c7a-504521d638f8@github.com>

Most of the broken links were fixed already by the JDK-8225368 and JDK-8214817
This change fix just a few.

Also two cleanups are applied:
 - The `../../java/awt/doc-files/` in some cases simplified to `doc-files/`
 - The html links to the java classes via `<a href>` replaced by the `{@link }`

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

Commit messages:
 - Initial fix

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

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

From aivanov at openjdk.java.net  Mon Nov  2 13:17:58 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 2 Nov 2020 13:17:58 GMT
Subject: <AWT Dev> RFR: 8211958: Broken links in java.desktop files
In-Reply-To: <sFnwpabh_Xf5-cpvaIRcW_5pBNaLYnPikdMBjWNrhgU=.86892be0-c298-4c4e-9c7a-504521d638f8@github.com>
References: <sFnwpabh_Xf5-cpvaIRcW_5pBNaLYnPikdMBjWNrhgU=.86892be0-c298-4c4e-9c7a-504521d638f8@github.com>
Message-ID: <e150Fw1azLiOoLczKaGo1EmMsl9Y7yniB2-H644GjN0=.f3b03022-715e-4afa-8e17-7121229fcc0f@github.com>

On Mon, 2 Nov 2020 09:04:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Most of the broken links were fixed already by the JDK-8225368 and JDK-8214817
> This change fix just a few.
> 
> Also two cleanups are applied:
>  - The `../../java/awt/doc-files/` in some cases simplified to `doc-files/`
>  - The html links to the java classes via `<a href>` replaced by the `{@link }`

Marked as reviewed by aivanov (Reviewer).

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

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

From serb at openjdk.java.net  Mon Nov  2 19:38:04 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 19:38:04 GMT
Subject: <AWT Dev> Integrated: 8211958: Broken links in java.desktop files
In-Reply-To: <sFnwpabh_Xf5-cpvaIRcW_5pBNaLYnPikdMBjWNrhgU=.86892be0-c298-4c4e-9c7a-504521d638f8@github.com>
References: <sFnwpabh_Xf5-cpvaIRcW_5pBNaLYnPikdMBjWNrhgU=.86892be0-c298-4c4e-9c7a-504521d638f8@github.com>
Message-ID: <DPYAPjZp3Opiz6Bx1F0D-CNkfLD99KzeQJfcys48tDw=.cadfd814-ceba-459b-9c07-6c08debcc85a@github.com>

On Mon, 2 Nov 2020 09:04:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Most of the broken links were fixed already by the JDK-8225368 and JDK-8214817
> This change fix just a few.
> 
> Also two cleanups are applied:
>  - The `../../java/awt/doc-files/` in some cases simplified to `doc-files/`
>  - The html links to the java classes via `<a href>` replaced by the `{@link }`

This pull request has now been integrated.

Changeset: acb5f654
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/acb5f654
Stats:     43 lines in 9 files changed: 0 ins; 4 del; 39 mod

8211958: Broken links in java.desktop files

Reviewed-by: aivanov

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

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

From jdv at openjdk.java.net  Tue Nov  3 08:10:58 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 3 Nov 2020 08:10:58 GMT
Subject: <AWT Dev> RFR: 8196087:
 java/awt/image/DrawImage/IncorrectUnmanagedImageRotatedClip.java fails
In-Reply-To: <AfxfD044OBqv6NXYlvZghgIX3ZlHypT2z6gdjq52nck=.0905b42a-3639-424d-9181-2948595c640f@github.com>
References: <AfxfD044OBqv6NXYlvZghgIX3ZlHypT2z6gdjq52nck=.0905b42a-3639-424d-9181-2948595c640f@github.com>
Message-ID: <LF09wzZuqhJVZcnJhvnKTHFjt7b02WeOMA4aasgJVyo=.15cd50df-bdba-4beb-87d0-67fdf63874e1@github.com>

On Thu, 29 Oct 2020 04:12:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The test draws some specific pattern to the VolatileImage and to the BufferedImage, and then compare pixels.
> 
> The test uses the getSnapshot() method to get the pixels from VolatileImage, and this method produces some interpolation "artifacts" if the fractional scale is used in the system(like 125%).
> 
> The solution is to use some predefined scale factors.

Marked as reviewed by jdv (Reviewer).

Please add CI test link in JBS. Looks good to me.

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

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

From jdv at openjdk.java.net  Tue Nov  3 08:19:56 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 3 Nov 2020 08:19:56 GMT
Subject: <AWT Dev> RFR: 8241806: The
 sun/awt/shell/FileSystemViewMemoryLeak.java is unstable
In-Reply-To: <-62q8bXBE3DGDVHdXcYWl8PFyJCSGy5Azl9pV_Vp2Dk=.7afc01be-f018-4051-a7a4-b9acf8756db0@github.com>
References: <-62q8bXBE3DGDVHdXcYWl8PFyJCSGy5Azl9pV_Vp2Dk=.7afc01be-f018-4051-a7a4-b9acf8756db0@github.com>
Message-ID: <iqcdgJ778FGVotto7tOcOMVyYJCAou6qqURt0_JAjgw=.31481a7f-6777-4e93-a5ac-23f1174a080c@github.com>

On Thu, 29 Oct 2020 05:29:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The test may work up to 15 minutes on some systems.
> The solution is to limit the time execution to 90 seconds.

Marked as reviewed by jdv (Reviewer).

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

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

From mbaesken at openjdk.java.net  Tue Nov  3 08:54:02 2020
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 3 Nov 2020 08:54:02 GMT
Subject: <AWT Dev> RFR: JDK-8255681: print callstack in error case in
 runAWTLoopWithApp
Message-ID: <oxbaRwOxzh8uCsmsEyLapCbNIlZBYAHkhharILDABn8=.c4fe33f6-cfe4-44fc-a403-7c923c472f71@github.com>

Currently in case of occurences of an NSException in runAWTLoopWithApp we catch the exception just print a simple error message like this :

2020-10-30 15:28:33.027 java[634:8435] Apple AWT Startup Exception: Cannot lock focus on image <NSImage 0x7fd350d7f9f0 Size={0, 0} RepProvider=(null)>, because it is size zero.
2020-10-30 15:28:33.306 java[634:8435] Apple AWT Restarting Native Event Thread

But we omit the callstack and loose valuable information. This change  adds the callstack to the output.

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

Commit messages:
 - JDK-8255681

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

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

From shade at openjdk.java.net  Tue Nov  3 09:18:52 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 3 Nov 2020 09:18:52 GMT
Subject: <AWT Dev> RFR: 8255798: Remove dead headless code in
 CompileJavaModules.gmk
In-Reply-To: <5Gi8FSVPAw7OmK6bq4YjYDWyCGr23IgedicITWsO0CE=.bfa58da7-69c2-472c-9a5f-1b6fa9dd2d36@github.com>
References: <5Gi8FSVPAw7OmK6bq4YjYDWyCGr23IgedicITWsO0CE=.bfa58da7-69c2-472c-9a5f-1b6fa9dd2d36@github.com>
Message-ID: <2PuJi3AuTvUKfC8pHGD7-wx0D4H34VknAKmoTfC9ipA=.7ff085eb-f25d-4b62-bb27-aff05d389eda@github.com>

On Tue, 3 Nov 2020 08:21:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The variable BUILD_HEADLESS_ONLY is no longer set. And sun/applet does not exist anymore.

Looks fine and trivial.

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

Marked as reviewed by shade (Reviewer).

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

From aivanov at openjdk.java.net  Tue Nov  3 11:57:58 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 3 Nov 2020 11:57:58 GMT
Subject: <AWT Dev> RFR: 8241806: The
 sun/awt/shell/FileSystemViewMemoryLeak.java is unstable
In-Reply-To: <iqcdgJ778FGVotto7tOcOMVyYJCAou6qqURt0_JAjgw=.31481a7f-6777-4e93-a5ac-23f1174a080c@github.com>
References: <-62q8bXBE3DGDVHdXcYWl8PFyJCSGy5Azl9pV_Vp2Dk=.7afc01be-f018-4051-a7a4-b9acf8756db0@github.com>
 <iqcdgJ778FGVotto7tOcOMVyYJCAou6qqURt0_JAjgw=.31481a7f-6777-4e93-a5ac-23f1174a080c@github.com>
Message-ID: <XUYFin6ds9RkvXNeCELWZr_ce8F19ylYIz-El0hgqBc=.91c766bd-335c-44c0-9237-88a844c80e25@github.com>

On Tue, 3 Nov 2020 08:17:29 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> The test may work up to 15 minutes on some systems.
>> The solution is to limit the time execution to 90 seconds.
>
> Marked as reviewed by jdv (Reviewer).

The test fails if OutOfMemoryError is thrown, right?
Is the reduced execution time enough to catch the original bug?

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

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

From clanger at openjdk.java.net  Tue Nov  3 13:43:05 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 3 Nov 2020 13:43:05 GMT
Subject: <AWT Dev> RFR: JDK-8255681: print callstack in error case in
 runAWTLoopWithApp
In-Reply-To: <oxbaRwOxzh8uCsmsEyLapCbNIlZBYAHkhharILDABn8=.c4fe33f6-cfe4-44fc-a403-7c923c472f71@github.com>
References: <oxbaRwOxzh8uCsmsEyLapCbNIlZBYAHkhharILDABn8=.c4fe33f6-cfe4-44fc-a403-7c923c472f71@github.com>
Message-ID: <Q2VL3GmzGwyVzxWRHF5CJUhNaq2DjBACuBSuTB-KCMc=.b6604c73-09e9-4202-88c9-2c030017c430@github.com>

On Tue, 3 Nov 2020 08:45:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently in case of occurences of an NSException in runAWTLoopWithApp we catch the exception just print a simple error message like this :
> 
> 2020-10-30 15:28:33.027 java[634:8435] Apple AWT Startup Exception: Cannot lock focus on image <NSImage 0x7fd350d7f9f0 Size={0, 0} RepProvider=(null)>, because it is size zero.
> 2020-10-30 15:28:33.306 java[634:8435] Apple AWT Restarting Native Event Thread
> 
> But we omit the callstack and loose valuable information. This change  adds the callstack to the output.

To me this looks like a good idea. In our current customer case this information would have greatly helped analysis. However, I'd like to see an opinion from one of the experts in that area on whether that's appropriate here.

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

Marked as reviewed by clanger (Reviewer).

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

From erikj at openjdk.java.net  Tue Nov  3 13:54:00 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 3 Nov 2020 13:54:00 GMT
Subject: <AWT Dev> RFR: 8255798: Remove dead headless code in
 CompileJavaModules.gmk
In-Reply-To: <5Gi8FSVPAw7OmK6bq4YjYDWyCGr23IgedicITWsO0CE=.bfa58da7-69c2-472c-9a5f-1b6fa9dd2d36@github.com>
References: <5Gi8FSVPAw7OmK6bq4YjYDWyCGr23IgedicITWsO0CE=.bfa58da7-69c2-472c-9a5f-1b6fa9dd2d36@github.com>
Message-ID: <_dNefpiWfKR-zi8TELcmEiO8Sx_C9dnqDF_nhHu2N0I=.6ba7cf21-0a69-4049-af5c-d73e1d5decde@github.com>

On Tue, 3 Nov 2020 08:21:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The variable BUILD_HEADLESS_ONLY is no longer set. And sun/applet does not exist anymore.

Marked as reviewed by erikj (Reviewer).

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

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

From ihse at openjdk.java.net  Tue Nov  3 14:58:57 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 3 Nov 2020 14:58:57 GMT
Subject: <AWT Dev> Integrated: 8255798: Remove dead headless code in
 CompileJavaModules.gmk
In-Reply-To: <5Gi8FSVPAw7OmK6bq4YjYDWyCGr23IgedicITWsO0CE=.bfa58da7-69c2-472c-9a5f-1b6fa9dd2d36@github.com>
References: <5Gi8FSVPAw7OmK6bq4YjYDWyCGr23IgedicITWsO0CE=.bfa58da7-69c2-472c-9a5f-1b6fa9dd2d36@github.com>
Message-ID: <WSppL1CKC2FxT_O6dxCFdX_enCEJBE77ko5DovYbJ5A=.989e2fcd-bcbf-4227-bfe0-cef3c6afe19b@github.com>

On Tue, 3 Nov 2020 08:21:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The variable BUILD_HEADLESS_ONLY is no longer set. And sun/applet does not exist anymore.

This pull request has now been integrated.

Changeset: 64a98112
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/64a98112
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

8255798: Remove dead headless code in CompileJavaModules.gmk

Reviewed-by: shade, erikj

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

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

From serb at openjdk.java.net  Tue Nov  3 17:04:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Nov 2020 17:04:58 GMT
Subject: <AWT Dev> RFR: 8241806: The
 sun/awt/shell/FileSystemViewMemoryLeak.java is unstable
In-Reply-To: <XUYFin6ds9RkvXNeCELWZr_ce8F19ylYIz-El0hgqBc=.91c766bd-335c-44c0-9237-88a844c80e25@github.com>
References: <-62q8bXBE3DGDVHdXcYWl8PFyJCSGy5Azl9pV_Vp2Dk=.7afc01be-f018-4051-a7a4-b9acf8756db0@github.com>
 <iqcdgJ778FGVotto7tOcOMVyYJCAou6qqURt0_JAjgw=.31481a7f-6777-4e93-a5ac-23f1174a080c@github.com>
 <XUYFin6ds9RkvXNeCELWZr_ce8F19ylYIz-El0hgqBc=.91c766bd-335c-44c0-9237-88a844c80e25@github.com>
Message-ID: <wxS_Ray9SHfD_C6h9CGTRmg3lkxrxVXRJqy4cPHV8HU=.6eaa5b4a-4f7f-48fd-8de5-7fe5beda1ac1@github.com>

On Tue, 3 Nov 2020 11:55:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test fails if OutOfMemoryError is thrown, right?
> Is the reduced execution time enough to catch the original bug?

It depends on the system, if it is really slow and just a few iterations out of 5000 will be done then the original bug will not be caught. If the system is fast and all 5000 iterations will be done, then the bug will be found.

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

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

From serb at openjdk.java.net  Tue Nov  3 18:32:02 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Nov 2020 18:32:02 GMT
Subject: <AWT Dev> Integrated: 8196087:
 java/awt/image/DrawImage/IncorrectUnmanagedImageRotatedClip.java fails
In-Reply-To: <AfxfD044OBqv6NXYlvZghgIX3ZlHypT2z6gdjq52nck=.0905b42a-3639-424d-9181-2948595c640f@github.com>
References: <AfxfD044OBqv6NXYlvZghgIX3ZlHypT2z6gdjq52nck=.0905b42a-3639-424d-9181-2948595c640f@github.com>
Message-ID: <L6PZEHYa8F4dLHstsUO0TJkvullSDqMOkXLhNxCaXhk=.7b2a5d14-37bc-461c-b4db-fa6e9d8a1ba9@github.com>

On Thu, 29 Oct 2020 04:12:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The test draws some specific pattern to the VolatileImage and to the BufferedImage, and then compare pixels.
> 
> The test uses the getSnapshot() method to get the pixels from VolatileImage, and this method produces some interpolation "artifacts" if the fractional scale is used in the system(like 125%).
> 
> The solution is to use some predefined scale factors.

This pull request has now been integrated.

Changeset: 83f3cf42
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/83f3cf42
Stats:     4 lines in 2 files changed: 2 ins; 1 del; 1 mod

8196087: java/awt/image/DrawImage/IncorrectUnmanagedImageRotatedClip.java fails

Reviewed-by: jdv

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

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

From serb at openjdk.java.net  Tue Nov  3 18:52:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Nov 2020 18:52:57 GMT
Subject: <AWT Dev> RFR: JDK-8255681: print callstack in error case in
 runAWTLoopWithApp
In-Reply-To: <oxbaRwOxzh8uCsmsEyLapCbNIlZBYAHkhharILDABn8=.c4fe33f6-cfe4-44fc-a403-7c923c472f71@github.com>
References: <oxbaRwOxzh8uCsmsEyLapCbNIlZBYAHkhharILDABn8=.c4fe33f6-cfe4-44fc-a403-7c923c472f71@github.com>
Message-ID: <zyR3YaXQmyc3RwjAPdJKRHy3PdDbTMY0JMqBqLqK1dE=.eade7d19-7a23-4e7e-b396-3ee8c47b5395@github.com>

On Tue, 3 Nov 2020 08:45:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently in case of occurences of an NSException in runAWTLoopWithApp we catch the exception just print a simple error message like this :
> 
> 2020-10-30 15:28:33.027 java[634:8435] Apple AWT Startup Exception: Cannot lock focus on image <NSImage 0x7fd350d7f9f0 Size={0, 0} RepProvider=(null)>, because it is size zero.
> 2020-10-30 15:28:33.306 java[634:8435] Apple AWT Restarting Native Event Thread
> 
> But we omit the callstack and loose valuable information. This change  adds the callstack to the output.

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Tue Nov  3 19:09:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Nov 2020 19:09:55 GMT
Subject: <AWT Dev> RFR: JDK-8244088: [Regression] Switch of Gnome theme
 ends up in deadlocked UI
In-Reply-To: <Fxp2TcPqYP--nPpafnEjm87kaovQc6uKyZ67NsWpbYs=.26705240-5d74-4783-bf28-355488c6a217@github.com>
References: <Fxp2TcPqYP--nPpafnEjm87kaovQc6uKyZ67NsWpbYs=.26705240-5d74-4783-bf28-355488c6a217@github.com>
Message-ID: <N4YPzJU3y2Nialp-JBKXTrm3fWlSyxD96PxS0ewcde0=.cb6d2eb8-86a2-4a4a-b18f-ec844e2b7129@github.com>

On Thu, 29 Oct 2020 13:14:49 GMT, Jayashree S Kumar <github.com+31532647+jaysk1 at openjdk.org> wrote:

> Issue
> 
> https://bugs.openjdk.java.net/browse/JDK-8244088
> 
> Problem
> 
> While using GTK3 java implementation,  User sees a deadlock issue in UI while trying to switch themes in gnome-tweak-tool.

I'll run the tests for the proposed fix.

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

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

From mbaesken at openjdk.java.net  Wed Nov  4 07:51:55 2020
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 4 Nov 2020 07:51:55 GMT
Subject: <AWT Dev> Integrated: JDK-8255681: print callstack in error case in
 runAWTLoopWithApp
In-Reply-To: <oxbaRwOxzh8uCsmsEyLapCbNIlZBYAHkhharILDABn8=.c4fe33f6-cfe4-44fc-a403-7c923c472f71@github.com>
References: <oxbaRwOxzh8uCsmsEyLapCbNIlZBYAHkhharILDABn8=.c4fe33f6-cfe4-44fc-a403-7c923c472f71@github.com>
Message-ID: <fQfO9G5wJgl_WvcJqox_uvqmeoE7vRAtXNFJxt3LSqc=.c5405466-dd85-438c-ba11-b0243d8d6dbc@github.com>

On Tue, 3 Nov 2020 08:45:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently in case of occurences of an NSException in runAWTLoopWithApp we catch the exception just print a simple error message like this :
> 
> 2020-10-30 15:28:33.027 java[634:8435] Apple AWT Startup Exception: Cannot lock focus on image <NSImage 0x7fd350d7f9f0 Size={0, 0} RepProvider=(null)>, because it is size zero.
> 2020-10-30 15:28:33.306 java[634:8435] Apple AWT Restarting Native Event Thread
> 
> But we omit the callstack and loose valuable information. This change  adds the callstack to the output.

This pull request has now been integrated.

Changeset: ab9192e4
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ab9192e4
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8255681: print callstack in error case in runAWTLoopWithApp

Reviewed-by: clanger, serb

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

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

From gnu.andrew at redhat.com  Wed Nov  4 19:57:32 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 4 Nov 2020 19:57:32 +0000
Subject: <AWT Dev> [hohensee@amazon.com: RFO: 8068228: Test
 closed/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest fails with
 GTKLookAndFeel]
Message-ID: <20201104195732.GC152012@stopbrexit>

Forwarding to awt-dev for attention of Oracle AWT developers.

----- Forwarded message from "Hohensee, Paul" <hohensee at amazon.com> -----

Date: Wed, 4 Nov 2020 00:36:16 +0000
From: "Hohensee, Paul" <hohensee at amazon.com>
To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: RFO: 8068228: Test closed/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest fails with GTKLookAndFeel

I?d like to backport https://bugs.openjdk.java.net/browse/JDK-8068228 from jdk9 to jdk8u as part of https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3077, and tag the issue appropriately so the backport can be tracked. The issue is closed, though the patch is open. Oracle folks, would it be possible to open the issue?

Thanks,
Paul


----- End forwarded message -----

-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20201104/502d9c8c/signature.asc>

From github.com+1538227+arodionov at openjdk.java.net  Wed Nov  4 23:11:58 2020
From: github.com+1538227+arodionov at openjdk.java.net (Andrii Rodionov)
Date: Wed, 4 Nov 2020 23:11:58 GMT
Subject: <AWT Dev> RFR: 8254024: Enhance native libs for AWT and Swing
 to work with GraalVM Native Image
In-Reply-To: <MLCPQ7F1i88ra5xzd1BRcBbMTRxArgfxu6tc-s1o4ZM=.294480d9-043e-4e56-bfad-4d06c83c445b@github.com>
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>
 <wTu1KYcM4mGcl9vJo1801bSz7TjmPfJe0qcdTGk2VLw=.0f813dd3-1a65-4981-8366-015c53afa6de@github.com>
 <nuRBeOsQfK-e8AlOYqbNCkA5PBvq2fkn3ajD5qO6EEA=.af41b9fe-d3be-4daf-b9be-c995fa6dd655@github.com>
 <ntRWXDeM6dkIdJY35CONCg8CorrhGmOvGpoq4j-OnSg=.69e9f9c2-754f-438b-960f-0a13daca0309@github.com>
 <o5PqI-0JlvEgEy-KXilJvFKyX3vNJnMH9nAgcBoABdg=.80d5f6a9-d68b-4a26-97ac-3b66bfb5d313@github.com>
 <p75sm7bljXhbCvv_co0gnczxO_sAYfDjwmYDBRRZKsg=.f33ca87f-4700-4348-8ffd-137c00b2395b@github.com>
 <v2MRHheWZJuZyYs2e7HHYTWGFd-MQplZco5JPcvPPCs=.02ffe15c-4b94-45ab-96fa-ac8e5de450ef@github.com>
 <QzfezoU2Z6pAhQPucs_Tj7qhCp-pnT1xJNeGaY8ZIIs=.1a8f82c9-2ee5-482b-b2a7-c76e03359a1f@github.com>
 <2hFTjMReXMfiNjTWswTV5EyEA7zFoEIbepsyelAcPeU=.fe56a018-3429-420c-b47f-274a400cc989@github.com>
 <QrK00iKoap7foOlhN2iMP2db0Rzae-oOB0FQBlZpHIk=.c61d95ae-bdae-4f58-a6c1-ee0e610ee442@github.com>
 <uKRfxak1vC1q-Gq_wT-SZewnJECciGLipTz
 Szgsp5_4=.2ee8c653-ab49-4be9-a7e9-5013d35676f3@github.com>
 <eDjJrOr_NkjJe4_vziRSrGby_Y0JZ6WIAioNPfY2pCM=.b67111ed-896f-4096-84c2-53f51290ad94@github.com>
 <MLCPQ7F1i88ra5xzd1BRcBbMTRxArgfxu6tc-s1o4ZM=.294480d9-043e-4e56-bfad-4d06c83c445b@github.com>
Message-ID: <jbxDix7bNUsNqPh0BQDqNqqSkXXPax4ut8fS5odCrqI=.82c96792-e691-46ab-9756-d444adb6b186@github.com>

On Fri, 16 Oct 2020 04:49:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> > > How it is possible to test the current changes?
>>> > 
>>> > 
>>> > For GraalVM native image, we run JCK tests `api/java_awt` and `api/javax_swing`. Those tests built as a native image.
>>> 
>>> I meant some "steps to reproduce" the current bug, and which can be used to verify the current fix.
>> 
>> Actually, we have found this issue during JCK tests execution that was built as a native image. The fix criteria are the successful tests run.
>
>> Actually, we have found this issue during JCK tests execution that was built as a native image. The fix criteria are the successful tests run.
> 
> But what exact steps should be done to reproduce this bug w/o using jck or any external tools? Something like:
>  - Clone JDK
>  - Build JDK using some specific options.
>  - Create some small test case
>  - Somehow create the native image
>  - Run the app -> boom -> bug is reproduced

@mrserb With the last dev build of GraalVM based on JDK 11.09, the bug can be reproduced by the approach that I've mentioned above.
The general steps: 
- download the [last dev build](https://github.com/graalvm/graalvm-ce-dev-builds/releases) of GraalVM + Native image 
- build the native image for AWTFixExample class (ziped configs for reflection and JNI is attached): 
`$ ~/graalvm-ce-java11-21.0.0-dev/bin/native-image -H:ConfigurationFileDirectories=./configs -Djava.awt.headless=true --native-image-info AWTFixExample`
- run built image - it should be executed successfully
- clone any version of the OpenJDK (11.09 - 16)
- build static libraries by executing `make static-libs-image` target 
- replace `libawt.a` in GraalVM on built static library from OpenJDK
- try to build example again and run it - it should be failed
- clone OpenJDK with the proposed fix
- build static libraries
- replace `libawt.a` in GraalVM on built static library with the fix
- build example and run it - it should be executed successfully

public class AWTFixExample {
    public static void main(String[] args) {
        float[] data = new float[]{0.0f, 1.1f, 2.2f, 3.3f, 4.4f, 5.5f, 6.6f, 7.7f, 8.8f};
        Kernel kernel = new Kernel(3, 3, data);
        ConvolveOp op = new ConvolveOp(kernel);

        BufferedImage src = new BufferedImage(10, 10, BufferedImage.TYPE_INT_ARGB);
        BufferedImage dest = new BufferedImage(10, 10, BufferedImage.TYPE_INT_ARGB);

        BufferedImage image = op.filter(src, dest);
        System.out.println(image);
    }
}

[configs.zip](https://github.com/openjdk/jdk/files/5490906/configs.zip)

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

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

From serb at openjdk.java.net  Thu Nov  5 01:40:04 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 5 Nov 2020 01:40:04 GMT
Subject: <AWT Dev> RFR: 8255575: java.awt.color.ICC_ColorSpace is not
 thread-safe
Message-ID: <fU0w2RBy57-Sqdka2SuWY_QuNi2eOckaDUfusUeAksw=.35893f1d-64e7-41f3-a81d-54a5d7f5f785@github.com>

The ICC_ColorSpace class uses a couple of internal data caches that might be used w/o any synchronization by different threads.

The solution is to wrap the initialization of the cached data by the DLC. I have checked performance impact by the J2DBench and it seems no big difference before/after the fix.

BTW jdk16 in some cases x10 times faster than 8u and 11u. Probably we should backport something, will check that.

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

Commit messages:
 - Update ICC_ColorSpace.java
 - Update MTICC_ColorSpaceToFrom.java
 - Update ICC_ColorSpace.java
 - Initial fix

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

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

From serb at openjdk.java.net  Thu Nov  5 01:46:56 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 5 Nov 2020 01:46:56 GMT
Subject: <AWT Dev> RFR: JDK-8244088: [Regression] Switch of Gnome theme
 ends up in deadlocked UI
In-Reply-To: <Fxp2TcPqYP--nPpafnEjm87kaovQc6uKyZ67NsWpbYs=.26705240-5d74-4783-bf28-355488c6a217@github.com>
References: <Fxp2TcPqYP--nPpafnEjm87kaovQc6uKyZ67NsWpbYs=.26705240-5d74-4783-bf28-355488c6a217@github.com>
Message-ID: <xJQ-hlLlQmtohszkWPfQzSiLKUkjtdrtwoyp0-D759E=.4a0a294c-abfa-459b-b27a-3807c477ca05@github.com>

On Thu, 29 Oct 2020 13:14:49 GMT, Jayashree S Kumar <github.com+31532647+jaysk1 at openjdk.org> wrote:

> Issue
> 
> https://bugs.openjdk.java.net/browse/JDK-8244088
> 
> Problem
> 
> While using GTK3 java implementation,  User sees a deadlock issue in UI while trying to switch themes in gnome-tweak-tool.

src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c line 353:

> 351:         JNIEnv *env, jobject this)
> 352: {
> 353:     // Note that gtk->flush_event_loop takes care of locks (7053002)

Different people used these methods (gdk_threads_enter/gdk_threads_leave) here twice which caused two regressions. Looks like the comment about locks is not enough. Could you please update the comment and state that gdk_threads_enter/gdk_threads_leave must not be used here?

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

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

From aivanov at openjdk.java.net  Thu Nov  5 12:37:55 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 5 Nov 2020 12:37:55 GMT
Subject: <AWT Dev> RFR: 8241806: The
 sun/awt/shell/FileSystemViewMemoryLeak.java is unstable
In-Reply-To: <wxS_Ray9SHfD_C6h9CGTRmg3lkxrxVXRJqy4cPHV8HU=.6eaa5b4a-4f7f-48fd-8de5-7fe5beda1ac1@github.com>
References: <-62q8bXBE3DGDVHdXcYWl8PFyJCSGy5Azl9pV_Vp2Dk=.7afc01be-f018-4051-a7a4-b9acf8756db0@github.com>
 <iqcdgJ778FGVotto7tOcOMVyYJCAou6qqURt0_JAjgw=.31481a7f-6777-4e93-a5ac-23f1174a080c@github.com>
 <XUYFin6ds9RkvXNeCELWZr_ce8F19ylYIz-El0hgqBc=.91c766bd-335c-44c0-9237-88a844c80e25@github.com>
 <wxS_Ray9SHfD_C6h9CGTRmg3lkxrxVXRJqy4cPHV8HU=.6eaa5b4a-4f7f-48fd-8de5-7fe5beda1ac1@github.com>
Message-ID: <XuWhM0Tqj4dOYH2HaFEL1EeykkxNib3NiMQYpwUhtag=.eaae48a2-4df7-4c27-bcf8-e95179faaf71@github.com>

On Tue, 3 Nov 2020 17:02:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > The test fails if OutOfMemoryError is thrown, right?
> > Is the reduced execution time enough to catch the original bug?
> 
> It depends on the system, if it is really slow and just a few iterations out of 5000 will be done then the original bug will not be caught. If the system is fast and all 5000 iterations will be done, then the bug will be found.

I agree with the idea of minimising the time spent to run the test. But the test is useless if it has no time to fail.

I just ran the test on my laptop with 10+22 where the original bug [JDK-8175015](https://bugs.openjdk.java.net/browse/JDK-8175015) isn't fixed. It fails as one would expect. It took about 12 minutes with `-Xmx8m` (less than 8500 iterations). After reducing the heap size to 4m, the test failed in 3 minutes (less than 2500 iterations).

But the modified test times out after 1.5 minutes and the test does not fail. Thus 90 seconds limit seems too short.

Shall we increase the timeout to 5 minutes at least and reduce the heap size to make the test fail faster. The number of iterations can be reduced as well, say to 10,000.

The test runs quickly on a recent build, it takes less than 10 seconds to perform 50,000 iterations. To be precise, it took 5.5 seconds with `-Xmx8m` and a little longer around 6 seconds with `-Xmx4m`. Obviously the run time depends on the hardware and can fluctuate significantly. On the other hand, it does no good if the test always exits by timeout without catching the original bug.

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

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

From serb at openjdk.java.net  Thu Nov  5 18:03:09 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 5 Nov 2020 18:03:09 GMT
Subject: <AWT Dev> RFR: 8241806: The
 sun/awt/shell/FileSystemViewMemoryLeak.java is unstable [v2]
In-Reply-To: <-62q8bXBE3DGDVHdXcYWl8PFyJCSGy5Azl9pV_Vp2Dk=.7afc01be-f018-4051-a7a4-b9acf8756db0@github.com>
References: <-62q8bXBE3DGDVHdXcYWl8PFyJCSGy5Azl9pV_Vp2Dk=.7afc01be-f018-4051-a7a4-b9acf8756db0@github.com>
Message-ID: <0vNTzwDX5uc_ps9b1WMQtVJASCmNysbudhH7Ae12sOs=.b08392f9-ca69-4d22-8a2e-48daa13b9619@github.com>

> The test may work up to 15 minutes on some systems.
> The solution is to limit the time execution to 90 seconds.

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

  Timeout increased

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/923/files
  - new: https://git.openjdk.java.net/jdk/pull/923/files/7ad4ed44..71307a3e

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

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

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

From serb at openjdk.java.net  Thu Nov  5 18:03:10 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 5 Nov 2020 18:03:10 GMT
Subject: <AWT Dev> RFR: 8241806: The
 sun/awt/shell/FileSystemViewMemoryLeak.java is unstable [v2]
In-Reply-To: <XuWhM0Tqj4dOYH2HaFEL1EeykkxNib3NiMQYpwUhtag=.eaae48a2-4df7-4c27-bcf8-e95179faaf71@github.com>
References: <-62q8bXBE3DGDVHdXcYWl8PFyJCSGy5Azl9pV_Vp2Dk=.7afc01be-f018-4051-a7a4-b9acf8756db0@github.com>
 <iqcdgJ778FGVotto7tOcOMVyYJCAou6qqURt0_JAjgw=.31481a7f-6777-4e93-a5ac-23f1174a080c@github.com>
 <XUYFin6ds9RkvXNeCELWZr_ce8F19ylYIz-El0hgqBc=.91c766bd-335c-44c0-9237-88a844c80e25@github.com>
 <wxS_Ray9SHfD_C6h9CGTRmg3lkxrxVXRJqy4cPHV8HU=.6eaa5b4a-4f7f-48fd-8de5-7fe5beda1ac1@github.com>
 <XuWhM0Tqj4dOYH2HaFEL1EeykkxNib3NiMQYpwUhtag=.eaae48a2-4df7-4c27-bcf8-e95179faaf71@github.com>
Message-ID: <WJWS4LnXiouE8mdxv8GcZjcf-njXQnrA0VOra7SeNIo=.f99f7cfa-ea53-4108-944a-1d73800be252@github.com>

On Thu, 5 Nov 2020 12:35:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> The test fails if OutOfMemoryError is thrown, right?
>>> Is the reduced execution time enough to catch the original bug?
>> 
>> It depends on the system, if it is really slow and just a few iterations out of 5000 will be done then the original bug will not be caught. If the system is fast and all 5000 iterations will be done, then the bug will be found.
>
>> > The test fails if OutOfMemoryError is thrown, right?
>> > Is the reduced execution time enough to catch the original bug?
>> 
>> It depends on the system, if it is really slow and just a few iterations out of 5000 will be done then the original bug will not be caught. If the system is fast and all 5000 iterations will be done, then the bug will be found.
> 
> I agree with the idea of minimising the time spent to run the test. But the test is useless if it has no time to fail.
> 
> I just ran the test on my laptop with 10+22 where the original bug [JDK-8175015](https://bugs.openjdk.java.net/browse/JDK-8175015) isn't fixed. It fails as one would expect. It took about 12 minutes with `-Xmx8m` (less than 8500 iterations). After reducing the heap size to 4m, the test failed in 3 minutes (less than 2500 iterations).
> 
> But the modified test times out after 1.5 minutes and the test does not fail. Thus 90 seconds limit seems too short.
> 
> Shall we increase the timeout to 5 minutes at least and reduce the heap size to make the test fail faster. The number of iterations can be reduced as well, say to 10,000.
> 
> The test runs quickly on a recent build, it takes less than 10 seconds to perform 50,000 iterations. To be precise, it took 5.5 seconds with `-Xmx8m` and a little longer around 6 seconds with `-Xmx4m`. Obviously the run time depends on the hardware and can fluctuate significantly. On the other hand, it does no good if the test always exits by timeout without catching the original bug.

I have increase timeout, but still use the xmx8m, it is the safest value, for the less value the java sometimes cannot be started using some options/configs.

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

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

From aivanov at openjdk.java.net  Thu Nov  5 19:17:57 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 5 Nov 2020 19:17:57 GMT
Subject: <AWT Dev> RFR: 8241806: The
 sun/awt/shell/FileSystemViewMemoryLeak.java is unstable [v2]
In-Reply-To: <0vNTzwDX5uc_ps9b1WMQtVJASCmNysbudhH7Ae12sOs=.b08392f9-ca69-4d22-8a2e-48daa13b9619@github.com>
References: <-62q8bXBE3DGDVHdXcYWl8PFyJCSGy5Azl9pV_Vp2Dk=.7afc01be-f018-4051-a7a4-b9acf8756db0@github.com>
 <0vNTzwDX5uc_ps9b1WMQtVJASCmNysbudhH7Ae12sOs=.b08392f9-ca69-4d22-8a2e-48daa13b9619@github.com>
Message-ID: <dO5lH4a4aNUZOKpB_4MV5L1tb96zNw0zs_xa7Ts9Gzs=.1ae66745-4ab2-44d7-8b97-581b50f3a431@github.com>

On Thu, 5 Nov 2020 18:03:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The test may work up to 15 minutes on some systems.
>> The solution is to limit the time execution to 90 seconds.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Timeout increased

Marked as reviewed by aivanov (Reviewer).

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

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

From aivanov at openjdk.java.net  Thu Nov  5 19:17:57 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 5 Nov 2020 19:17:57 GMT
Subject: <AWT Dev> RFR: 8241806: The
 sun/awt/shell/FileSystemViewMemoryLeak.java is unstable [v2]
In-Reply-To: <dO5lH4a4aNUZOKpB_4MV5L1tb96zNw0zs_xa7Ts9Gzs=.1ae66745-4ab2-44d7-8b97-581b50f3a431@github.com>
References: <-62q8bXBE3DGDVHdXcYWl8PFyJCSGy5Azl9pV_Vp2Dk=.7afc01be-f018-4051-a7a4-b9acf8756db0@github.com>
 <0vNTzwDX5uc_ps9b1WMQtVJASCmNysbudhH7Ae12sOs=.b08392f9-ca69-4d22-8a2e-48daa13b9619@github.com>
 <dO5lH4a4aNUZOKpB_4MV5L1tb96zNw0zs_xa7Ts9Gzs=.1ae66745-4ab2-44d7-8b97-581b50f3a431@github.com>
Message-ID: <Md3No9yqcMRBbKdTgKcdyWLgUM3BvIfo27WiddjteLE=.a579068e-3372-4c3e-b76d-02280bd5b1e1@github.com>

On Thu, 5 Nov 2020 19:12:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Timeout increased
>
> Marked as reviewed by aivanov (Reviewer).

> I have increase timeout, but still use the xmx8m, it is the safest value, for the less value the java sometimes cannot be started using some options/configs.

Makes sense.

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

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

From serb at openjdk.java.net  Fri Nov  6 00:32:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 6 Nov 2020 00:32:58 GMT
Subject: <AWT Dev> Integrated: 8241806: The
 sun/awt/shell/FileSystemViewMemoryLeak.java is unstable
In-Reply-To: <-62q8bXBE3DGDVHdXcYWl8PFyJCSGy5Azl9pV_Vp2Dk=.7afc01be-f018-4051-a7a4-b9acf8756db0@github.com>
References: <-62q8bXBE3DGDVHdXcYWl8PFyJCSGy5Azl9pV_Vp2Dk=.7afc01be-f018-4051-a7a4-b9acf8756db0@github.com>
Message-ID: <YYfDLPRHRarynSIaMyFO7knzlpzVQX6fLsBuQA2qIC8=.f1b9a835-1915-449a-89a8-270275c8bf8c@github.com>

On Thu, 29 Oct 2020 05:29:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The test may work up to 15 minutes on some systems.
> The solution is to limit the time execution to 90 seconds.

This pull request has now been integrated.

Changeset: e730e8b6
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e730e8b6
Stats:     16 lines in 2 files changed: 13 ins; 1 del; 2 mod

8241806: The sun/awt/shell/FileSystemViewMemoryLeak.java is unstable

Reviewed-by: jdv, aivanov

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

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

From serb at openjdk.java.net  Fri Nov  6 09:02:08 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 6 Nov 2020 09:02:08 GMT
Subject: <AWT Dev> RFR: 6422025: ThemeReader.cpp can be updated for VC7
Message-ID: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>

Some of the type definitions have been imported from `UxTheme.h` to the `ThemeReader.cpp` because at that time we supported the windows OS below XP as well as VC6.

It is time to use `UxTheme.h ` directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly.

mach5 is green

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

Commit messages:
 - 6422025: ThemeReader.cpp can be updated for VC7

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

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

From serb at openjdk.java.net  Fri Nov  6 09:02:09 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 6 Nov 2020 09:02:09 GMT
Subject: <AWT Dev> RFR: 6422025: ThemeReader.cpp can be updated for VC7
In-Reply-To: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
References: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
Message-ID: <FVgCy5-LPxdwQws3DoouDkR55jumA4jo9GMi5K5JbhU=.b946291c-c3ef-486d-9966-b29408d82c16@github.com>

On Fri, 6 Nov 2020 08:51:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some of the type definitions have been imported from `UxTheme.h` to the `ThemeReader.cpp` because at that time we supported the windows OS below XP as well as VC6.
> 
> It is time to use `UxTheme.h ` directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly.
> 
> mach5 is green

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 38:

> 36: import java.util.concurrent.locks.ReentrantReadWriteLock;
> 37: 
> 38: /* !!!! WARNING !!!!

The comment is outdated we do not support win L&F on any Unix.

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 302:

> 300:     }
> 301: 
> 302:     public static native boolean isGetThemeTransitionDurationDefined();

This method was added in Vista so we guarded it by the runtime check.

src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 177:

> 175:            && SetWindowThemeFunc
> 176:            && IsThemeBackgroundPartiallyTransparentFunc
> 177:            && GetThemeTransitionDurationFunc

Now we check `GetThemeTransitionDurationFunc` as well.

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

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

From aivanov at openjdk.java.net  Fri Nov  6 18:21:00 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 6 Nov 2020 18:21:00 GMT
Subject: <AWT Dev> RFR: 6422025: ThemeReader.cpp can be updated for VC7
In-Reply-To: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
References: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
Message-ID: <VqGLFNav6xIYe9LsqpJhdop4zngd5Y-H4e5-lcxXA2A=.0ce782dd-f10e-4391-8fe7-beec2e4de0d8@github.com>

On Fri, 6 Nov 2020 08:51:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some of the type definitions have been imported from `UxTheme.h` to the `ThemeReader.cpp` because at that time we supported the windows OS below XP as well as VC6.
> 
> It is time to use `UxTheme.h ` directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly.
> 
> mach5 is green

Changes requested by aivanov (Reviewer).

src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 126:

> 124:         DTRACE_PRINTLN("Loaded UxTheme.dll\n");
> 125:         OpenThemeDataFunc = (PFNOPENTHEMEDATA)GetProcAddress(hModThemes,
> 126:                                                         "OpenThemeData");

Can't we use the functions directly? I mean we can link to `UxTheme.lib` and load the `UxTheme.dll` automatically.
Dynamic loading was necessary for Windows versions before Windows XP where `UxTheme.dll` doesn't exist.

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

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

From serb at openjdk.java.net  Fri Nov  6 22:13:00 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 6 Nov 2020 22:13:00 GMT
Subject: <AWT Dev> RFR: 6422025: ThemeReader.cpp can be updated for VC7
In-Reply-To: <VqGLFNav6xIYe9LsqpJhdop4zngd5Y-H4e5-lcxXA2A=.0ce782dd-f10e-4391-8fe7-beec2e4de0d8@github.com>
References: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
 <VqGLFNav6xIYe9LsqpJhdop4zngd5Y-H4e5-lcxXA2A=.0ce782dd-f10e-4391-8fe7-beec2e4de0d8@github.com>
Message-ID: <Cc_GQmYiWFFcbRDnxtJiFm0Z2gCIIxrMJqKncx4MRHw=.7ce10673-c4d7-4b3a-9b2d-5f3eac2a0f18@github.com>

On Fri, 6 Nov 2020 18:17:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Some of the type definitions have been imported from `UxTheme.h` to the `ThemeReader.cpp` because at that time we supported the windows OS below XP as well as VC6.
>> 
>> It is time to use `UxTheme.h ` directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly.
>> 
>> mach5 is green
>
> src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 126:
> 
>> 124:         DTRACE_PRINTLN("Loaded UxTheme.dll\n");
>> 125:         OpenThemeDataFunc = (PFNOPENTHEMEDATA)GetProcAddress(hModThemes,
>> 126:                                                         "OpenThemeData");
> 
> Can't we use the functions directly? I mean we can link to `UxTheme.lib` and load the `UxTheme.dll` automatically.
> Dynamic loading was necessary for Windows versions before Windows XP where `UxTheme.dll` doesn't exist.

That's was my comment in the description about:

>  It is time to use UxTheme.h directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly,

 also, the native win L&F is an optional thing.

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

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

From aivanov at openjdk.java.net  Fri Nov  6 22:45:57 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 6 Nov 2020 22:45:57 GMT
Subject: <AWT Dev> RFR: 6422025: ThemeReader.cpp can be updated for VC7
In-Reply-To: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
References: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
Message-ID: <guA_eD8edIvIFnkJMpyA5ajngrEDQeqpovpgxJmXAxg=.4d6d0a93-2607-4ffa-86e3-40497bb06f61@github.com>

On Fri, 6 Nov 2020 08:51:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some of the type definitions have been imported from `UxTheme.h` to the `ThemeReader.cpp` because at that time we supported the windows OS below XP as well as VC6.
> 
> It is time to use `UxTheme.h ` directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly.
> 
> mach5 is green

Marked as reviewed by aivanov (Reviewer).

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

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

From aivanov at openjdk.java.net  Fri Nov  6 22:45:58 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 6 Nov 2020 22:45:58 GMT
Subject: <AWT Dev> RFR: 6422025: ThemeReader.cpp can be updated for VC7
In-Reply-To: <Cc_GQmYiWFFcbRDnxtJiFm0Z2gCIIxrMJqKncx4MRHw=.7ce10673-c4d7-4b3a-9b2d-5f3eac2a0f18@github.com>
References: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
 <VqGLFNav6xIYe9LsqpJhdop4zngd5Y-H4e5-lcxXA2A=.0ce782dd-f10e-4391-8fe7-beec2e4de0d8@github.com>
 <Cc_GQmYiWFFcbRDnxtJiFm0Z2gCIIxrMJqKncx4MRHw=.7ce10673-c4d7-4b3a-9b2d-5f3eac2a0f18@github.com>
Message-ID: <Dd6IYKsl2aZ2jDTuFJbRz3S2xBi_-QBf0ji1FKgCgJM=.d45069f4-aea4-46a8-b7a9-7932df30c662@github.com>

On Fri, 6 Nov 2020 22:09:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 126:
>> 
>>> 124:         DTRACE_PRINTLN("Loaded UxTheme.dll\n");
>>> 125:         OpenThemeDataFunc = (PFNOPENTHEMEDATA)GetProcAddress(hModThemes,
>>> 126:                                                         "OpenThemeData");
>> 
>> Can't we use the functions directly? I mean we can link to `UxTheme.lib` and load the `UxTheme.dll` automatically.
>> Dynamic loading was necessary for Windows versions before Windows XP where `UxTheme.dll` doesn't exist.
>
> That's was my comment in the description about:
> 
>>  It is time to use UxTheme.h directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly,
> 
>  also, the native win L&F is an optional thing.

Thank you for the clarification. I must have missed this note. Yes, I later realised that it could be the reason why you didn't update how the DLL is loaded.
Delay-load is another option, on the other hand there's already the code to load the library and get the function pointers.

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

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

From serb at openjdk.java.net  Sat Nov  7 06:13:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 7 Nov 2020 06:13:57 GMT
Subject: <AWT Dev> Integrated: 6422025: ThemeReader.cpp can be updated for
 VC7
In-Reply-To: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
References: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
Message-ID: <penvlmKBvXq0noIPfljh6Sntm2b6qMjJ2hPfhVlV0r0=.674b9373-415e-47f6-a4a7-d5ff299b29d6@github.com>

On Fri, 6 Nov 2020 08:51:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some of the type definitions have been imported from `UxTheme.h` to the `ThemeReader.cpp` because at that time we supported the windows OS below XP as well as VC6.
> 
> It is time to use `UxTheme.h ` directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly.
> 
> mach5 is green

This pull request has now been integrated.

Changeset: 358f5d2b
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/358f5d2b
Stats:     145 lines in 3 files changed: 2 ins; 63 del; 80 mod

6422025: ThemeReader.cpp can be updated for VC7

Reviewed-by: aivanov

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

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

From serb at openjdk.java.net  Sat Nov  7 07:09:05 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 7 Nov 2020 07:09:05 GMT
Subject: <AWT Dev> RFR: 8225116: Test OwnedWindowsLeak.java intermittently
 fails
Message-ID: <qPlC_DmjwuVspEaqf4DZPkmB_3Tb6sRoZ53I_V6CcXU=.0dcc1c31-22cb-4f72-8686-42886fb4d733@github.com>

This test rarely fails in the past on some configurations but was never a problem listed, and according to the history of CI, it fails 2 times on its own this year.

There are two possible reasons for the failure:
1. At that time we had a memory leak, which was fixed.
2. The test works too fast and it was not enough time for GC to eliminate 1000 windows.

To make the future evaluation simpler I enhanced the test and make it stricter, see some comments inline.

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

Commit messages:
 - Update OwnedWindowsLeak.java
 - Update OwnedWindowsLeak.java

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

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

From serb at openjdk.java.net  Sat Nov  7 07:09:06 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 7 Nov 2020 07:09:06 GMT
Subject: <AWT Dev> RFR: 8225116: Test OwnedWindowsLeak.java
 intermittently fails
In-Reply-To: <qPlC_DmjwuVspEaqf4DZPkmB_3Tb6sRoZ53I_V6CcXU=.0dcc1c31-22cb-4f72-8686-42886fb4d733@github.com>
References: <qPlC_DmjwuVspEaqf4DZPkmB_3Tb6sRoZ53I_V6CcXU=.0dcc1c31-22cb-4f72-8686-42886fb4d733@github.com>
Message-ID: <HrOnKvr1sI-mN3IvjimlM2Kpt-TI9re0r6XyCOu3iFM=.5a728af7-eae5-4a0a-926f-0e0b10060386@github.com>

On Sat, 7 Nov 2020 06:55:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This test rarely fails in the past on some configurations but was never a problem listed, and according to the history of CI, it fails 2 times on its own this year.
> 
> There are two possible reasons for the failure:
> 1. At that time we had a memory leak, which was fixed.
> 2. The test works too fast and it was not enough time for GC to eliminate 1000 windows.
> 
> To make the future evaluation simpler I enhanced the test and make it stricter, see some comments inline.

test/jdk/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java line 74:

> 72:         for (WeakReference<Window> ref : children)
> 73:         {
> 74:             while (ref.get() != null) {

Will wait till the end of the test and log what window is leaked. If it fails then it will be 100% product bug.

test/jdk/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java line 92:

> 90:         }
> 91:         catch (Exception z)
> 92:         {

If the field will be removed/renamed the test should be reworked.

test/jdk/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java line 87:

> 85:         while (ownersChildren.size() > 0)
> 86:         {
> 87:             System.out.println("ownersChildren = " + ownersChildren);

This private list is cleared via the DIsposer mechanism, which may require additional time. If it fails then it will be 100% product bug.

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

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

From serb at openjdk.java.net  Sat Nov  7 07:37:03 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 7 Nov 2020 07:37:03 GMT
Subject: <AWT Dev> RFR: 6278172: TextComponent.getSelectedText() throws
 StringIndexOutOfBoundsException
Message-ID: <5vcukZV00bZ1bAzji0LuUn5sTYIEVCyz3OzEOLeOMpM=.000ffc24-3aa7-481c-b7c8-3105867474e3@github.com>

The text components are implements as wrappers over the "native" peers. Most of the functionality is provided by the peers not wrappers like TextArea/TextField. The current bug occurs in the TextArea/TextField when the native peer was created yet.

The steps to reproduce:
 1. Sets the long text to the component
 2. Select all text in the component
 3. Sets the short text to the component
 4. Request the selected text -> BOOM

The bug on step 4 occurred because we request a long substring of the short text. To eliminate an exception we have two choices:
 1. Preserve the selection in the setText(), but limit it by the length of the current text.
 2. Resets the selection.

I tried both solutions, the second caused some TCK tests to fail, so I selected the first one.

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

Commit messages:
 - Merge branch 'master' into JDK-6278172
 - Initial fix

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

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

From github.com+654217+bastie at openjdk.java.net  Sat Nov  7 10:50:00 2020
From: github.com+654217+bastie at openjdk.java.net (Sebastian Ritter)
Date: Sat, 7 Nov 2020 10:50:00 GMT
Subject: <AWT Dev> RFR: 8066622 8066637: remove deprecated using
 java.io.File.toURL() in internal classes
Message-ID: <EbSZJq5R0_NZWXVivUsn-nJoOwHQCtYwUrUrPOeKa0c=.5877af1b-0db2-4064-bc35-638151ecc774@github.com>

In result of Javadoc to do not use java.io.File.toURL()
Change use  java.io.File.toURL().toURI() instead.

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

Commit messages:
 - in result of Javadoc to java.io.File.toURL do use internal java.io.File.toURL().toURI instead

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

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

From github.com+654217+bastie at openjdk.java.net  Sat Nov  7 10:50:00 2020
From: github.com+654217+bastie at openjdk.java.net (Sebastian Ritter)
Date: Sat, 7 Nov 2020 10:50:00 GMT
Subject: <AWT Dev> RFR: 8066622 8066637: remove deprecated using
 java.io.File.toURL() in internal classes
In-Reply-To: <EbSZJq5R0_NZWXVivUsn-nJoOwHQCtYwUrUrPOeKa0c=.5877af1b-0db2-4064-bc35-638151ecc774@github.com>
References: <EbSZJq5R0_NZWXVivUsn-nJoOwHQCtYwUrUrPOeKa0c=.5877af1b-0db2-4064-bc35-638151ecc774@github.com>
Message-ID: <imS0Kd5rFXVv5L3eOf2S-1e2MGrtAWGIc_U7Y7s-UZo=.6c74ca73-f6b5-4b3d-a6a2-3c710db25bfd@github.com>

On Sat, 7 Nov 2020 07:55:03 GMT, Sebastian Ritter <github.com+654217+bastie at openjdk.org> wrote:

> In result of Javadoc to do not use java.io.File.toURL()
> Change use  java.io.File.toURL().toURI() instead.

8066622 8066637: only for java.io.File.toURL

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

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

From prr at openjdk.java.net  Sun Nov  8 17:00:55 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 8 Nov 2020 17:00:55 GMT
Subject: <AWT Dev> RFR: 8066622 8066637: remove deprecated using
 java.io.File.toURL() in internal classes
In-Reply-To: <EbSZJq5R0_NZWXVivUsn-nJoOwHQCtYwUrUrPOeKa0c=.5877af1b-0db2-4064-bc35-638151ecc774@github.com>
References: <EbSZJq5R0_NZWXVivUsn-nJoOwHQCtYwUrUrPOeKa0c=.5877af1b-0db2-4064-bc35-638151ecc774@github.com>
Message-ID: <JyzlXMPWtFSGD9k-MTyqrK4EOw_ju8VVXO3niuy66ag=.d8d9124d-c831-4879-a44d-13412ce4da64@github.com>

On Sat, 7 Nov 2020 07:55:03 GMT, Sebastian Ritter <github.com+654217+bastie at openjdk.org> wrote:

> In result of Javadoc to do not use java.io.File.toURL()
> Change use  java.io.File.toURL().toURI() instead.

You reference a desktop bug that discusses many, many deprecations
and skara has identified https://bugs.openjdk.java.net/browse/JDK-8066622
as the issue being fixed.
Yet you propose to fix precisely one of these.
But when this is integrated that bug will be closed out as resolved.
I think you need a new bug about JUST the changes you are making.
So I don't think you should use that bug id any where in this PR.
And I'd like to hear whether you actually *tested* splashscreen with your change ? I see no sign that you did.

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

Changes requested by prr (Reviewer).

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

From github.com+31532647+jaysk1 at openjdk.java.net  Mon Nov  9 06:28:55 2020
From: github.com+31532647+jaysk1 at openjdk.java.net (Jayashree S Kumar)
Date: Mon, 9 Nov 2020 06:28:55 GMT
Subject: <AWT Dev> RFR: JDK-8244088: [Regression] Switch of Gnome theme
 ends up in deadlocked UI
In-Reply-To: <xJQ-hlLlQmtohszkWPfQzSiLKUkjtdrtwoyp0-D759E=.4a0a294c-abfa-459b-b27a-3807c477ca05@github.com>
References: <Fxp2TcPqYP--nPpafnEjm87kaovQc6uKyZ67NsWpbYs=.26705240-5d74-4783-bf28-355488c6a217@github.com>
 <xJQ-hlLlQmtohszkWPfQzSiLKUkjtdrtwoyp0-D759E=.4a0a294c-abfa-459b-b27a-3807c477ca05@github.com>
Message-ID: <-jK7gIo9Yt2ykU24L6hqDQatHxp3DFqKT4Hwq2JUe5s=.3157174c-08d7-484c-bda3-0a3e3614fd6e@github.com>

On Thu, 5 Nov 2020 01:44:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Issue
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8244088
>> 
>> Problem
>> 
>> While using GTK3 java implementation,  User sees a deadlock issue in UI while trying to switch themes in gnome-tweak-tool.
>
> src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c line 353:
> 
>> 351:         JNIEnv *env, jobject this)
>> 352: {
>> 353:     // Note that gtk->flush_event_loop takes care of locks (7053002)
> 
> Different people used these methods (gdk_threads_enter/gdk_threads_leave) here twice which caused two regressions. Looks like the comment about locks is not enough. Could you please update the comment and state that gdk_threads_enter/gdk_threads_leave must not be used here?

@mrserb: Yes will add the additional comment here. 

Like you have rightly said, Yes there are 2 regression here: 
1. For GTK3's g_main_context_iteration they have included an extra lock (gdk_threads_enter/gdk_threads_leave) which was causing a deadlock
2.  The definition of g_main_context_iteration module in new ?gtk3_interface.h? is defined using a single parameter causing the hang in XToolkit_waitForEvents 

So
1. In Java_com_sun_java_swing_plaf_gtk_GTKEngine_native_1switch_1theme () method removed the extra lock. 
2. Corrected the g_main_context_iteration module definaition accordingly https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-main-context-iteration

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

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

From github.com+31532647+jaysk1 at openjdk.java.net  Mon Nov  9 09:26:14 2020
From: github.com+31532647+jaysk1 at openjdk.java.net (Jayashree S Kumar)
Date: Mon, 9 Nov 2020 09:26:14 GMT
Subject: <AWT Dev> RFR: JDK-8244088: [Regression] Switch of Gnome theme
 ends up in deadlocked UI [v2]
In-Reply-To: <Fxp2TcPqYP--nPpafnEjm87kaovQc6uKyZ67NsWpbYs=.26705240-5d74-4783-bf28-355488c6a217@github.com>
References: <Fxp2TcPqYP--nPpafnEjm87kaovQc6uKyZ67NsWpbYs=.26705240-5d74-4783-bf28-355488c6a217@github.com>
Message-ID: <X00i0aRRQ_eoaiEPnLPE1yidnRIcOL1cHsgFlmMgKSM=.3689e13a-1cb1-4964-abbb-ebd787dd779f@github.com>

> Issue
> 
> https://bugs.openjdk.java.net/browse/JDK-8244088
> 
> Problem
> 
> While using GTK3 java implementation,  User sees a deadlock issue in UI while trying to switch themes in gnome-tweak-tool.

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

  Code Review: Improved comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/932/files
  - new: https://git.openjdk.java.net/jdk/pull/932/files/02247bfb..fc2d36b1

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

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

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

From github.com+31532647+jaysk1 at openjdk.java.net  Mon Nov  9 09:26:15 2020
From: github.com+31532647+jaysk1 at openjdk.java.net (Jayashree S Kumar)
Date: Mon, 9 Nov 2020 09:26:15 GMT
Subject: <AWT Dev> RFR: JDK-8244088: [Regression] Switch of Gnome theme
 ends up in deadlocked UI [v2]
In-Reply-To: <xJQ-hlLlQmtohszkWPfQzSiLKUkjtdrtwoyp0-D759E=.4a0a294c-abfa-459b-b27a-3807c477ca05@github.com>
References: <Fxp2TcPqYP--nPpafnEjm87kaovQc6uKyZ67NsWpbYs=.26705240-5d74-4783-bf28-355488c6a217@github.com>
 <xJQ-hlLlQmtohszkWPfQzSiLKUkjtdrtwoyp0-D759E=.4a0a294c-abfa-459b-b27a-3807c477ca05@github.com>
Message-ID: <kVnwnK--1lR_-wP38zy7FtFXmsaP114-1KFavgBC2pE=.3844f30b-1e3c-4adc-b529-959f85b7abfb@github.com>

On Thu, 5 Nov 2020 01:44:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Jayashree S Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Code Review: Improved comment
>
> src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c line 353:
> 
>> 351:         JNIEnv *env, jobject this)
>> 352: {
>> 353:     // Note that gtk->flush_event_loop takes care of locks (7053002)
> 
> Different people used these methods (gdk_threads_enter/gdk_threads_leave) here twice which caused two regressions. Looks like the comment about locks is not enough. Could you please update the comment and state that gdk_threads_enter/gdk_threads_leave must not be used here?

@mrserb:  I have addressed the review comment. Thanks!

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

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

From serb at openjdk.java.net  Mon Nov  9 22:38:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 9 Nov 2020 22:38:57 GMT
Subject: <AWT Dev> RFR: JDK-8244088: [Regression] Switch of Gnome theme
 ends up in deadlocked UI
In-Reply-To: <N4YPzJU3y2Nialp-JBKXTrm3fWlSyxD96PxS0ewcde0=.cb6d2eb8-86a2-4a4a-b18f-ec844e2b7129@github.com>
References: <Fxp2TcPqYP--nPpafnEjm87kaovQc6uKyZ67NsWpbYs=.26705240-5d74-4783-bf28-355488c6a217@github.com>
 <N4YPzJU3y2Nialp-JBKXTrm3fWlSyxD96PxS0ewcde0=.cb6d2eb8-86a2-4a4a-b18f-ec844e2b7129@github.com>
Message-ID: <CpXB3YkZGiKdWlUs_nz-84VC6kPa_NiXVC07XPIfl3o=.4e54a362-5b2d-4725-af78-836f99aa3143@github.com>

On Tue, 3 Nov 2020 19:06:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Issue
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8244088
>> 
>> Problem
>> 
>> While using GTK3 java implementation,  User sees a deadlock issue in UI while trying to switch themes in gnome-tweak-tool.
>
> I'll run the tests for the proposed fix.

The testing of the patch is in-progress.

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

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

From serb at openjdk.java.net  Tue Nov 10 01:11:59 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 10 Nov 2020 01:11:59 GMT
Subject: <AWT Dev> RFR: 8254024: Enhance native libs for AWT and Swing
 to work with GraalVM Native Image
In-Reply-To: <jbxDix7bNUsNqPh0BQDqNqqSkXXPax4ut8fS5odCrqI=.82c96792-e691-46ab-9756-d444adb6b186@github.com>
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>
 <wTu1KYcM4mGcl9vJo1801bSz7TjmPfJe0qcdTGk2VLw=.0f813dd3-1a65-4981-8366-015c53afa6de@github.com>
 <nuRBeOsQfK-e8AlOYqbNCkA5PBvq2fkn3ajD5qO6EEA=.af41b9fe-d3be-4daf-b9be-c995fa6dd655@github.com>
 <ntRWXDeM6dkIdJY35CONCg8CorrhGmOvGpoq4j-OnSg=.69e9f9c2-754f-438b-960f-0a13daca0309@github.com>
 <o5PqI-0JlvEgEy-KXilJvFKyX3vNJnMH9nAgcBoABdg=.80d5f6a9-d68b-4a26-97ac-3b66bfb5d313@github.com>
 <p75sm7bljXhbCvv_co0gnczxO_sAYfDjwmYDBRRZKsg=.f33ca87f-4700-4348-8ffd-137c00b2395b@github.com>
 <v2MRHheWZJuZyYs2e7HHYTWGFd-MQplZco5JPcvPPCs=.02ffe15c-4b94-45ab-96fa-ac8e5de450ef@github.com>
 <QzfezoU2Z6pAhQPucs_Tj7qhCp-pnT1xJNeGaY8ZIIs=.1a8f82c9-2ee5-482b-b2a7-c76e03359a1f@github.com>
 <2hFTjMReXMfiNjTWswTV5EyEA7zFoEIbepsyelAcPeU=.fe56a018-3429-420c-b47f-274a400cc989@github.com>
 <QrK00iKoap7foOlhN2iMP2db0Rzae-oOB0FQBlZpHIk=.c61d95ae-bdae-4f58-a6c1-ee0e610ee442@github.com>
 <uKRfxak1vC1q-Gq_wT-SZewnJECciGLipTz
 Szgsp5_4=.2ee8c653-ab49-4be9-a7e9-5013d35676f3@github.com>
 <eDjJrOr_NkjJe4_vziRSrGby_Y0JZ6WIAioNPfY2pCM=.b67111ed-896f-4096-84c2-53f51290ad94@github.com>
 <MLCPQ7F1i88ra5xzd1BRcBbMTRxArgfxu6tc-s1o4ZM=.294480d9-043e-4e56-bfad-4d06c83c445b@github.com>
 <jbxDix7bNUsNqPh0BQDqNqqSkXXPax4ut8fS5odCrqI=.82c96792-e691-46ab-9756-d444adb6b186@github.com>
Message-ID: <KdtSni2r8p8F3aKOPKeoBxUK6dmLQZ-ZYvlppfZWrN4=.77af7a43-eadf-45ed-bc2b-d0ecf74a8489@github.com>

On Wed, 4 Nov 2020 23:09:14 GMT, Andrii Rodionov <github.com+1538227+arodionov at openjdk.org> wrote:

>>> Actually, we have found this issue during JCK tests execution that was built as a native image. The fix criteria are the successful tests run.
>> 
>> But what exact steps should be done to reproduce this bug w/o using jck or any external tools? Something like:
>>  - Clone JDK
>>  - Build JDK using some specific options.
>>  - Create some small test case
>>  - Somehow create the native image
>>  - Run the app -> boom -> bug is reproduced
>
> @mrserb With the last dev build of GraalVM based on JDK 11.09, the bug can be reproduced by the approach that I've mentioned above.
> The general steps: 
> - download the [last dev build](https://github.com/graalvm/graalvm-ce-dev-builds/releases) of GraalVM + Native image 
> - build the native image for AWTFixExample class (ziped configs for reflection and JNI is attached): 
> `$ ~/graalvm-ce-java11-21.0.0-dev/bin/native-image -H:ConfigurationFileDirectories=./configs -Djava.awt.headless=true --native-image-info AWTFixExample`
> - run built image - it should be executed successfully
> - clone any version of the OpenJDK (11.09 - 16)
> - build static libraries by executing `make static-libs-image` target 
> - replace `libawt.a` in GraalVM on built static library from OpenJDK
> - try to build example again and run it - it should be failed
> - clone OpenJDK with the proposed fix
> - build static libraries
> - replace `libawt.a` in GraalVM on built static library with the fix
> - build example and run it - it should be executed successfully
> 
> public class AWTFixExample {
>     public static void main(String[] args) {
>         float[] data = new float[]{0.0f, 1.1f, 2.2f, 3.3f, 4.4f, 5.5f, 6.6f, 7.7f, 8.8f};
>         Kernel kernel = new Kernel(3, 3, data);
>         ConvolveOp op = new ConvolveOp(kernel);
> 
>         BufferedImage src = new BufferedImage(10, 10, BufferedImage.TYPE_INT_ARGB);
>         BufferedImage dest = new BufferedImage(10, 10, BufferedImage.TYPE_INT_ARGB);
> 
>         BufferedImage image = op.filter(src, dest);
>         System.out.println(image);
>     }
> }
> 
> [configs.zip](https://github.com/openjdk/jdk/files/5490906/configs.zip)

I think part of the changed code is actually dead code and can be removed, I'll take a look.

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

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

From serb at openjdk.java.net  Tue Nov 10 02:36:59 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 10 Nov 2020 02:36:59 GMT
Subject: <AWT Dev> RFR: JDK-8244088: [Regression] Switch of Gnome theme
 ends up in deadlocked UI [v2]
In-Reply-To: <X00i0aRRQ_eoaiEPnLPE1yidnRIcOL1cHsgFlmMgKSM=.3689e13a-1cb1-4964-abbb-ebd787dd779f@github.com>
References: <Fxp2TcPqYP--nPpafnEjm87kaovQc6uKyZ67NsWpbYs=.26705240-5d74-4783-bf28-355488c6a217@github.com>
 <X00i0aRRQ_eoaiEPnLPE1yidnRIcOL1cHsgFlmMgKSM=.3689e13a-1cb1-4964-abbb-ebd787dd779f@github.com>
Message-ID: <s2ArAzmA32ZyLSCHmi6ulfulr7MAObt5yyVm2OmhQfw=.2b954d5c-7b22-4c7b-a6f6-8db554a1cfc4@github.com>

On Mon, 9 Nov 2020 09:26:14 GMT, Jayashree S Kumar <github.com+31532647+jaysk1 at openjdk.org> wrote:

>> Issue
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8244088
>> 
>> Problem
>> 
>> While using GTK3 java implementation,  User sees a deadlock issue in UI while trying to switch themes in gnome-tweak-tool.
>
> Jayashree S Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code Review: Improved comment

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Tue Nov 10 08:31:04 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 10 Nov 2020 08:31:04 GMT
Subject: <AWT Dev> RFR: 8251854: [macosx] Java forces the use of discrete GPU
Message-ID: <Nf052gV_cPeWE9lYgIOeus5BZZXi_Pc-BFICzqLVO4A=.8fb05764-e448-4c82-91a6-cecbb2ed6b2e@github.com>

This is a review request for the bug particularly fixed some time ago:
https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html

In that review request it was found that the old fix does not work well in all cases, see:
https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html

The current fix updates an embedded plist.info, so the java will not require
discrete graphics by default, same as for any other applications. 

The discrete card will be used:
 1. If macOS decided to enable it for some reason
 2. If the java app sets/uses a full-screen window
 3. If the user disable "automatic graphics switching" in the system preferences
 4. If an external monitor is connected to the laptop

In other cases, the integrated graphics will be used, which should be fine in most cases since this graphic is used/tested in the mbp 13/etc. This is not only about rendering performance but also about startup performance, on my current new laptop mbp 16 + Cataline 10.15.7 the switching discrete/integrated causes unexpected delays up to 10 seconds.


Note that the new "metal" pipeline also does not require discrete graphics.

The documentation for NSSupportsAutomaticGraphicsSwitching:
https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching

I'll create a release note after approval.

Performance numbers:
https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html
Old review request:
https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html

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

Commit messages:
 - Initial fix

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

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

From kizune at openjdk.java.net  Tue Nov 10 09:19:59 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 10 Nov 2020 09:19:59 GMT
Subject: <AWT Dev> RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
In-Reply-To: <GNK5tQ1JknvAOBjO-IA2tvR-u9hI8s1pjtoTAtWvj0I=.24099e9b-dc10-4fc9-b4d3-9b167f299721@github.com>
References: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
 <GNK5tQ1JknvAOBjO-IA2tvR-u9hI8s1pjtoTAtWvj0I=.24099e9b-dc10-4fc9-b4d3-9b167f299721@github.com>
Message-ID: <h-K5JrIf9IRUTge0QEyI65ruTZAATMr0K-NmYrnoi2k=.84bda56a-5d89-43a1-a6d7-009033cf7873@github.com>

On Wed, 28 Oct 2020 23:46:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Hello.
>> Please review the fix for jdk.
>> 
>> Old review request:
>> https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html
>> 
>> 
>> (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it should be fine for
>> Windows 7, because it does not support different DPI for different monitors)
>> 
>> ========================================================
>> Short description:
>>      In the multi-screen configurations when each screen have different DPI
>>      we calculate the bounds of each monitor by these formulas:
>> 
>>          userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / scaleX, deviceH / scaleY
>>          devSpaceBounds  = userX * scaleX, userY * scaleY, userW * scaleX, userH * scaleY
>> 
>>   This formula makes the next configuration completely broken:
>>     - The main screen on the left and 100% DPI
>>     - The second screen on the right and 200% DPI
>>   When we translate the bounds of the config from the device space to the user's space,
>>      the bounds of both screen overlap in the user's space, because we use bounds of
>>      the main screen as-is, and the X/Y of the second screen are divided by the scaleX/Y.
>> 
>>   Since the screens are overlapped we cannot be sure how to translate the user's space
>>    coordinates to device space in the overlapped zone.
>>   As a result => we use the wrong screen
>>                    => got wrong coordinates in the device space
>>                      => show top-level windows/popups/tooltips/menus/etc on the wrong screen
>> 
>>    The proposed solution for this bug is to change the formulas to these:
>> 
>>          userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / scaleY
>>          devSpaceBounds  = userX, userY, userW * scaleX, userH * scaleY
>> 
>>    In other words, we should not transform the X and Y coordinates of the screen(the top/left corner). This will
>>    complicate the way of how we transform coordinates on the screen: user's <--> device spaces:
>> 
>>    Before the fix:
>> 
>>          userX = deviceX * scaleX;
>>          deviceX = userX / scaleX;
>> 
>>    After the fix(only the part appeared on this screen should be scaled)
>> 
>>          userX = screenX + (deviceX - screenX) * scaleX
>>          deviceX = screenX + (userX - screenX) / scaleX
>> 
>>    Note that these new formulas are applicable only for the coordinates on the screen such as X and Y.
>>    If we will need to calculate the "size" such as W and H then the old formula should be used.
>> 
>>    The main changes for the problem above are:
>>    - Skip transformation of X and Y of the screen bounds:
>>        http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html
>>    - A number of utility methods in java and native:
>> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html
>> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html
>>    
>> 
>> ========================================================
>> Long description:
>>      Unfortunately, the changes above are not enough to fix the problem when different monitors
>>      have different DPI, even if the bounds are *NOT* overlapped.
>> 
>>    - Currently, when we try to set the bounds of the window, we manually convert it in "java" to the
>>      expected device position based on the current GraphicsConfiguration of the peer, and then
>>      additionally, tweak it in native using the device scale stored in native code. Unfortunately
>>      this two scale might not be in sync:(after we use the GraphicsConfiguration scale in peer,
>>      the config might be changed and the tweak in native will use a different screen).
>> 
>>      As a fix I have moved all transformation from the peer to the native code, it will be executed
>>      on the toolkit thread:
>>      See the change in WWindowPeer.setBounds() and awt_Window.cpp AwtWindow::Reshape
>>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html
>>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>>      I think at some point we should delete all transformation in java, and apply it in the native code only.
>>      
>> 
>>    - We had a special code that tracked the dragging of the window by the user from one screen to another,
>>      and change the size of the window only when the user stops the drag operation. I've proposed to use standard Windows
>>      machinery for that via WM_DPICHANGED: https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged
>>      As a result, Windows will provide the "best" windows bounds on the new screen. Note that the code has a
>>      workaround for https://bugs.openjdk.java.net/browse/JDK-8249164
>>   
>>    - I've also fix a variation of the bug previously fixed on macOS https://hg.openjdk.java.net/jdk/jdk/rev/b5cdba232fca
>>      If we try to change the position of the window, and Windows ignores this request then we need to call all "callbacks" manually, otherwise, the shared code will use the bounds ignored by the Windows.
>>      See the end of void AwtWindow::Reshape():
>>      http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>> 
>>   -  Currently the HW componets such as Canvas scales everything based on such code:
>> 
>>           770 int AwtComponent::ScaleUpX(int x) {
>>           4771     int screen = AwtWin32GraphicsDevice::DeviceIndexForWindow(GetHWnd());
>>           4772     Devices::InstanceAccess devices;
>>           4773     AwtWin32GraphicsDevice* device = devices->GetDevice(screen);
>>           4774     return device == NULL ? x : device->ScaleUpX(x);
>>           4775 }
>> 
>>   But it does not work well if the smaller part of the top-level window is located on one screen1(DPI=100) but
>>      the biggest part is located on the screen2(DPI=200). If the Canvas is located on the "smaller" part of the
>>      window, then the canvas will use DPI=100 for scale, but the whole window will use DPI=200
>> 
>>    As a fix, all HW components will try to use the scale factor of the top-level window, see AwtComponent::GetScreenImOn:
>> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp.sdiff.html
>> 
>>    - Our current implementation does not take care of the case when the HW component bounds are updated when the top-level
>>      the window is moved to another screen. For example, if the window does not use LayoutManager and the user sets some specific bounds for the Canvas. It is expected that the size of the Canvas will be updated when the window will be moved to another screen, but only HW top-level window and Swing components will update its size.
>> 
>>      As a fix I suggest to resync the bounds of the HW components if the GraphicsCOnfiguration is changed, see WComponentPeer.syncBounds():
>>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java.sdiff.html
>> 
>>    - Note that the current fix is for Windows only, but the bug exists on Linux as well, so I have to create a kind of "ifdef" in the
>>      Robot class, on windows we will use the new logic, on other platforms the old logic will be used.
>> 
>>    - The win32GraphicsDevice incorrectly sets the size of the full-screen window. It uses the display mode width/height(which are stored in pixels), but the bounds of the graphics config(which are stored in user's space) should be used.
>> 
>> ========================================================
>> Some other bugs which are not fixed.
>> 
>>     - We have a lot of places where we mix(unintentionally) the coordinate in user's space and device space.
>>       For example when we create the component we read x/y/width/height by the JNI(of course in a user's space)
>>       but pass this coordinates as-is to the ::CreateWindowEx() which is incorrect. It works currently
>>       because later we reshape the component to the correct bounds. Will fix it later.
>> 
>>     - When the frame is iconized and we try to save a new bounds for the future use, we store the
>>       coordinates in the user's space to the field which use device space:
>>       https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664
>> 
>> Probably there are some other bugs and possibility to cleanups, but I would like to do that in separate issues.
>>      
>> 
>> ========================================================
>> The tests
>>     - I have updated a couple of the tests to check multiple screens if possible, it helps to found some bugs
>>       in my initial implementation
>>     - Four new tests were added: SetComponentsBounds, SlowMotion, WindowSizeDifferentScreens, FullscreenWindowProps
>>     - One test is moved from the closed repo(I made a small cleanup of it): ListMultipleSelectTest
>> 
>> ========================================================
>> I have run jck, regression tests in different configurations, when the main screen is on the left, up, down,
>> right, and have different DPI such as 100, 125, 150, and 200. No new issues were found so far.
>> 
>> The mach5 is also green.
>> 
>> PS: hope I did not forget some important information, will send it later if any.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Update WindowSizeDifferentScreens.java
>  - Update ListMultipleSelectTest.java
>  - syncBounds code reformat
>  - javadoc fix for SunGraphicsEnvironment#toDeviceSpace
>  - Merge branch 'master' into JDK-8211999
>  - Apply suggestions from code review
>    
>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8211999
>  - Update FullscreenWindowProps.java
>  - Merge branch 'master' into JDK-8211999
>  - Fix fullscreen in HiDPI mode
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/1a5e6c98...636b7cc4

Marked as reviewed by kizune (Reviewer).

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

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

From aivanov at openjdk.java.net  Tue Nov 10 09:54:59 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 10 Nov 2020 09:54:59 GMT
Subject: <AWT Dev> RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
In-Reply-To: <GNK5tQ1JknvAOBjO-IA2tvR-u9hI8s1pjtoTAtWvj0I=.24099e9b-dc10-4fc9-b4d3-9b167f299721@github.com>
References: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
 <GNK5tQ1JknvAOBjO-IA2tvR-u9hI8s1pjtoTAtWvj0I=.24099e9b-dc10-4fc9-b4d3-9b167f299721@github.com>
Message-ID: <5LNG6nKhwE5XoKjIS9E8Sr5x0IxcFYUcszeGcEck87s=.5d5bb638-c044-4b75-899d-758ed21b872e@github.com>

On Wed, 28 Oct 2020 23:46:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Hello.
>> Please review the fix for jdk.
>> 
>> Old review request:
>> https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html
>> 
>> 
>> (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it should be fine for
>> Windows 7, because it does not support different DPI for different monitors)
>> 
>> ========================================================
>> Short description:
>>      In the multi-screen configurations when each screen have different DPI
>>      we calculate the bounds of each monitor by these formulas:
>> 
>>          userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / scaleX, deviceH / scaleY
>>          devSpaceBounds  = userX * scaleX, userY * scaleY, userW * scaleX, userH * scaleY
>> 
>>   This formula makes the next configuration completely broken:
>>     - The main screen on the left and 100% DPI
>>     - The second screen on the right and 200% DPI
>>   When we translate the bounds of the config from the device space to the user's space,
>>      the bounds of both screen overlap in the user's space, because we use bounds of
>>      the main screen as-is, and the X/Y of the second screen are divided by the scaleX/Y.
>> 
>>   Since the screens are overlapped we cannot be sure how to translate the user's space
>>    coordinates to device space in the overlapped zone.
>>   As a result => we use the wrong screen
>>                    => got wrong coordinates in the device space
>>                      => show top-level windows/popups/tooltips/menus/etc on the wrong screen
>> 
>>    The proposed solution for this bug is to change the formulas to these:
>> 
>>          userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / scaleY
>>          devSpaceBounds  = userX, userY, userW * scaleX, userH * scaleY
>> 
>>    In other words, we should not transform the X and Y coordinates of the screen(the top/left corner). This will
>>    complicate the way of how we transform coordinates on the screen: user's <--> device spaces:
>> 
>>    Before the fix:
>> 
>>          userX = deviceX * scaleX;
>>          deviceX = userX / scaleX;
>> 
>>    After the fix(only the part appeared on this screen should be scaled)
>> 
>>          userX = screenX + (deviceX - screenX) * scaleX
>>          deviceX = screenX + (userX - screenX) / scaleX
>> 
>>    Note that these new formulas are applicable only for the coordinates on the screen such as X and Y.
>>    If we will need to calculate the "size" such as W and H then the old formula should be used.
>> 
>>    The main changes for the problem above are:
>>    - Skip transformation of X and Y of the screen bounds:
>>        http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html
>>    - A number of utility methods in java and native:
>> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html
>> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html
>>    
>> 
>> ========================================================
>> Long description:
>>      Unfortunately, the changes above are not enough to fix the problem when different monitors
>>      have different DPI, even if the bounds are *NOT* overlapped.
>> 
>>    - Currently, when we try to set the bounds of the window, we manually convert it in "java" to the
>>      expected device position based on the current GraphicsConfiguration of the peer, and then
>>      additionally, tweak it in native using the device scale stored in native code. Unfortunately
>>      this two scale might not be in sync:(after we use the GraphicsConfiguration scale in peer,
>>      the config might be changed and the tweak in native will use a different screen).
>> 
>>      As a fix I have moved all transformation from the peer to the native code, it will be executed
>>      on the toolkit thread:
>>      See the change in WWindowPeer.setBounds() and awt_Window.cpp AwtWindow::Reshape
>>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html
>>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>>      I think at some point we should delete all transformation in java, and apply it in the native code only.
>>      
>> 
>>    - We had a special code that tracked the dragging of the window by the user from one screen to another,
>>      and change the size of the window only when the user stops the drag operation. I've proposed to use standard Windows
>>      machinery for that via WM_DPICHANGED: https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged
>>      As a result, Windows will provide the "best" windows bounds on the new screen. Note that the code has a
>>      workaround for https://bugs.openjdk.java.net/browse/JDK-8249164
>>   
>>    - I've also fix a variation of the bug previously fixed on macOS https://hg.openjdk.java.net/jdk/jdk/rev/b5cdba232fca
>>      If we try to change the position of the window, and Windows ignores this request then we need to call all "callbacks" manually, otherwise, the shared code will use the bounds ignored by the Windows.
>>      See the end of void AwtWindow::Reshape():
>>      http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>> 
>>   -  Currently the HW componets such as Canvas scales everything based on such code:
>> 
>>           770 int AwtComponent::ScaleUpX(int x) {
>>           4771     int screen = AwtWin32GraphicsDevice::DeviceIndexForWindow(GetHWnd());
>>           4772     Devices::InstanceAccess devices;
>>           4773     AwtWin32GraphicsDevice* device = devices->GetDevice(screen);
>>           4774     return device == NULL ? x : device->ScaleUpX(x);
>>           4775 }
>> 
>>   But it does not work well if the smaller part of the top-level window is located on one screen1(DPI=100) but
>>      the biggest part is located on the screen2(DPI=200). If the Canvas is located on the "smaller" part of the
>>      window, then the canvas will use DPI=100 for scale, but the whole window will use DPI=200
>> 
>>    As a fix, all HW components will try to use the scale factor of the top-level window, see AwtComponent::GetScreenImOn:
>> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp.sdiff.html
>> 
>>    - Our current implementation does not take care of the case when the HW component bounds are updated when the top-level
>>      the window is moved to another screen. For example, if the window does not use LayoutManager and the user sets some specific bounds for the Canvas. It is expected that the size of the Canvas will be updated when the window will be moved to another screen, but only HW top-level window and Swing components will update its size.
>> 
>>      As a fix I suggest to resync the bounds of the HW components if the GraphicsCOnfiguration is changed, see WComponentPeer.syncBounds():
>>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java.sdiff.html
>> 
>>    - Note that the current fix is for Windows only, but the bug exists on Linux as well, so I have to create a kind of "ifdef" in the
>>      Robot class, on windows we will use the new logic, on other platforms the old logic will be used.
>> 
>>    - The win32GraphicsDevice incorrectly sets the size of the full-screen window. It uses the display mode width/height(which are stored in pixels), but the bounds of the graphics config(which are stored in user's space) should be used.
>> 
>> ========================================================
>> Some other bugs which are not fixed.
>> 
>>     - We have a lot of places where we mix(unintentionally) the coordinate in user's space and device space.
>>       For example when we create the component we read x/y/width/height by the JNI(of course in a user's space)
>>       but pass this coordinates as-is to the ::CreateWindowEx() which is incorrect. It works currently
>>       because later we reshape the component to the correct bounds. Will fix it later.
>> 
>>     - When the frame is iconized and we try to save a new bounds for the future use, we store the
>>       coordinates in the user's space to the field which use device space:
>>       https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664
>> 
>> Probably there are some other bugs and possibility to cleanups, but I would like to do that in separate issues.
>>      
>> 
>> ========================================================
>> The tests
>>     - I have updated a couple of the tests to check multiple screens if possible, it helps to found some bugs
>>       in my initial implementation
>>     - Four new tests were added: SetComponentsBounds, SlowMotion, WindowSizeDifferentScreens, FullscreenWindowProps
>>     - One test is moved from the closed repo(I made a small cleanup of it): ListMultipleSelectTest
>> 
>> ========================================================
>> I have run jck, regression tests in different configurations, when the main screen is on the left, up, down,
>> right, and have different DPI such as 100, 125, 150, and 200. No new issues were found so far.
>> 
>> The mach5 is also green.
>> 
>> PS: hope I did not forget some important information, will send it later if any.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Update WindowSizeDifferentScreens.java
>  - Update ListMultipleSelectTest.java
>  - syncBounds code reformat
>  - javadoc fix for SunGraphicsEnvironment#toDeviceSpace
>  - Merge branch 'master' into JDK-8211999
>  - Apply suggestions from code review
>    
>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8211999
>  - Update FullscreenWindowProps.java
>  - Merge branch 'master' into JDK-8211999
>  - Fix fullscreen in HiDPI mode
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/1a5e6c98...636b7cc4

Marked as reviewed by aivanov (Reviewer).

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

> 355:      * @param  config the graphics configuration which bounds are requested
> 356:      * @return the bounds of the area covered by this
> 357:      *         {@code GraphicsConfiguration} in device space(pixels).

Suggestion:

     *         {@code GraphicsConfiguration} in device space (pixels).
If changed here, all other similar places should be updated too to keep doc comments consistent.

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

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

From github.com+654217+bastie at openjdk.java.net  Tue Nov 10 11:47:55 2020
From: github.com+654217+bastie at openjdk.java.net (Sebastian Ritter)
Date: Tue, 10 Nov 2020 11:47:55 GMT
Subject: <AWT Dev> RFR: 8066622 8066637: remove deprecated using
 java.io.File.toURL() in internal classes
In-Reply-To: <JyzlXMPWtFSGD9k-MTyqrK4EOw_ju8VVXO3niuy66ag=.d8d9124d-c831-4879-a44d-13412ce4da64@github.com>
References: <EbSZJq5R0_NZWXVivUsn-nJoOwHQCtYwUrUrPOeKa0c=.5877af1b-0db2-4064-bc35-638151ecc774@github.com>
 <JyzlXMPWtFSGD9k-MTyqrK4EOw_ju8VVXO3niuy66ag=.d8d9124d-c831-4879-a44d-13412ce4da64@github.com>
Message-ID: <kbeKe8e0KYLcdTALuu35QXQQALktrXXoQ05kilJo8qQ=.b430e927-3454-4a39-8b67-b7926a3be016@github.com>

On Sun, 8 Nov 2020 16:58:24 GMT, Phil Race <prr at openjdk.org> wrote:

> You reference a desktop bug that discusses many, many deprecations ...
Yep. In my opinion this is a bot problem here and need other place to discuss. 

> Yet you propose to fix precisely one of these.
@prrace:  Not really. 
The way to work with problems differ. Both bugs - maybe these are more quality change requests than bugs - are bullet lists and are created on build process. The different is, I work on single quality tests and remove deprecated code from source base. So in my clean Java build the method java.io.File.toUrl() does not(!) exist. 
Because java.io.File.toURL() doesn't exist, also two patches are needed for JDK build process (internal I use diff-patch).

> And I'd like to hear whether you actually _tested_ splashscreen with your change ? I see no sign that you did.
I'm not sure, what you want to listen. I work with a clean Java build with patch to remove java.io.File.toURL() and change the collateral damages.

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

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

From kcr at openjdk.java.net  Tue Nov 10 12:53:55 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 10 Nov 2020 12:53:55 GMT
Subject: <AWT Dev> RFR: 8251854: [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <Nf052gV_cPeWE9lYgIOeus5BZZXi_Pc-BFICzqLVO4A=.8fb05764-e448-4c82-91a6-cecbb2ed6b2e@github.com>
References: <Nf052gV_cPeWE9lYgIOeus5BZZXi_Pc-BFICzqLVO4A=.8fb05764-e448-4c82-91a6-cecbb2ed6b2e@github.com>
Message-ID: <br9sKduwFZGaAY8Y2vD2_UOu8T6AB068YZWxahvCvQQ=.71169f1a-87ab-425b-9a3c-a9efca1483e6@github.com>

On Tue, 10 Nov 2020 08:19:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is a review request for the bug particularly fixed some time ago:
> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html
> 
> In that review request it was found that the old fix does not work well in all cases, see:
> https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html
> 
> The current fix updates an embedded plist.info, so the java will not require
> discrete graphics by default, same as for any other applications. 
> 
> The discrete card will be used:
>  1. If macOS decided to enable it for some reason
>  2. If the java app sets/uses a full-screen window
>  3. If the user disable "automatic graphics switching" in the system preferences
>  4. If an external monitor is connected to the laptop
> 
> In other cases, the integrated graphics will be used, which should be fine in most cases since this graphic is used/tested in the mbp 13/etc. This is not only about rendering performance but also about startup performance, on my current new laptop mbp 16 + Cataline 10.15.7 the switching discrete/integrated causes unexpected delays up to 10 seconds.
> 
> 
> Note that the new "metal" pipeline also does not require discrete graphics.
> 
> The documentation for NSSupportsAutomaticGraphicsSwitching:
> https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching
> 
> I'll create a release note after approval.
> 
> Performance numbers:
> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html
> Old review request:
> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html

I'm still somewhat unsure whether we want to do this in all cases. As mentioned offline, the discrete GPU will be unused (might as well not be there) for almost all Java applications when using a single screen. When the MacBook Pro is running on battery, this seems like a good thing, but when it is plugged in, it seems like we wasting the discrete GPU. It's too bad Apple doesn't provide a way for an application to hint whether they would like to use the discrete GPU if available.

I want to run some performance tests with JavaFX, since it will likely impact JavaFX applications.

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

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

From erikj at openjdk.java.net  Tue Nov 10 13:26:57 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 10 Nov 2020 13:26:57 GMT
Subject: <AWT Dev> RFR: 8251854: [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <Nf052gV_cPeWE9lYgIOeus5BZZXi_Pc-BFICzqLVO4A=.8fb05764-e448-4c82-91a6-cecbb2ed6b2e@github.com>
References: <Nf052gV_cPeWE9lYgIOeus5BZZXi_Pc-BFICzqLVO4A=.8fb05764-e448-4c82-91a6-cecbb2ed6b2e@github.com>
Message-ID: <epFJBT7ojxv5e7lJwX92LkMtHvFnWDTsiXg6SIcxFf8=.0b6d23db-89de-4521-89ef-5c0002968d90@github.com>

On Tue, 10 Nov 2020 08:19:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is a review request for the bug particularly fixed some time ago:
> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html
> 
> In that review request it was found that the old fix does not work well in all cases, see:
> https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html
> 
> The current fix updates an embedded plist.info, so the java will not require
> discrete graphics by default, same as for any other applications. 
> 
> The discrete card will be used:
>  1. If macOS decided to enable it for some reason
>  2. If the java app sets/uses a full-screen window
>  3. If the user disable "automatic graphics switching" in the system preferences
>  4. If an external monitor is connected to the laptop
> 
> In other cases, the integrated graphics will be used, which should be fine in most cases since this graphic is used/tested in the mbp 13/etc. This is not only about rendering performance but also about startup performance, on my current new laptop mbp 16 + Cataline 10.15.7 the switching discrete/integrated causes unexpected delays up to 10 seconds.
> 
> 
> Note that the new "metal" pipeline also does not require discrete graphics.
> 
> The documentation for NSSupportsAutomaticGraphicsSwitching:
> https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching
> 
> I'll create a release note after approval.
> 
> Performance numbers:
> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html
> Old review request:
> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html

Change looks ok from a build point of view, but I can't comment on the validity and implications of using this key.

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

Marked as reviewed by erikj (Reviewer).

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

From kcr at openjdk.java.net  Tue Nov 10 16:40:58 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 10 Nov 2020 16:40:58 GMT
Subject: <AWT Dev> RFR: 8251854: [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <epFJBT7ojxv5e7lJwX92LkMtHvFnWDTsiXg6SIcxFf8=.0b6d23db-89de-4521-89ef-5c0002968d90@github.com>
References: <Nf052gV_cPeWE9lYgIOeus5BZZXi_Pc-BFICzqLVO4A=.8fb05764-e448-4c82-91a6-cecbb2ed6b2e@github.com>
 <epFJBT7ojxv5e7lJwX92LkMtHvFnWDTsiXg6SIcxFf8=.0b6d23db-89de-4521-89ef-5c0002968d90@github.com>
Message-ID: <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com>

On Tue, 10 Nov 2020 13:24:21 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> This is a review request for the bug particularly fixed some time ago:
>> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html
>> 
>> In that review request it was found that the old fix does not work well in all cases, see:
>> https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html
>> 
>> The current fix updates an embedded plist.info, so the java will not require
>> discrete graphics by default, same as for any other applications. 
>> 
>> The discrete card will be used:
>>  1. If macOS decided to enable it for some reason
>>  2. If the java app sets/uses a full-screen window
>>  3. If the user disable "automatic graphics switching" in the system preferences
>>  4. If an external monitor is connected to the laptop
>> 
>> In other cases, the integrated graphics will be used, which should be fine in most cases since this graphic is used/tested in the mbp 13/etc. This is not only about rendering performance but also about startup performance, on my current new laptop mbp 16 + Cataline 10.15.7 the switching discrete/integrated causes unexpected delays up to 10 seconds.
>> 
>> 
>> Note that the new "metal" pipeline also does not require discrete graphics.
>> 
>> The documentation for NSSupportsAutomaticGraphicsSwitching:
>> https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching
>> 
>> I'll create a release note after approval.
>> 
>> Performance numbers:
>> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html
>> Old review request:
>> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html
>
> Change looks ok from a build point of view, but I can't comment on the validity and implications of using this key.

I ran a 3D lighting test that is designed to be a GPU stress test. It's a worst case, to be sure, but it take 10 times as long to render with the integrated GPU as it does with the discrete GPU:

**attenuation.LightingSample: 500 large quads**
discrete GPU: 23.5 fps
integrated GPU: 2.34 fps

In a more realistic example of drawing a large number of 2D vectors, it runs 35% slower with the integrated GPU:

**Vector charting test, oval clip**
discrete GPU: 41.1 fps
integrated GPU: 26.6 fps

I see similar results in the performance numbers you listed above.

An application developer who packages up their JDK, for example, using jpackage, can make the decision for themselves. Application developers who rely on the JDK as delivered will get whatever we choose as the default. So we need to be sure that the benefit of doing this justifies the performance hit.

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

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

From serb at openjdk.java.net  Tue Nov 10 17:17:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 10 Nov 2020 17:17:58 GMT
Subject: <AWT Dev> RFR: 8251854: [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com>
References: <Nf052gV_cPeWE9lYgIOeus5BZZXi_Pc-BFICzqLVO4A=.8fb05764-e448-4c82-91a6-cecbb2ed6b2e@github.com>
 <epFJBT7ojxv5e7lJwX92LkMtHvFnWDTsiXg6SIcxFf8=.0b6d23db-89de-4521-89ef-5c0002968d90@github.com>
 <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com>
Message-ID: <yOe4_tGWgwczS5Dz7BbMxXBb3eYRWiyTA56plTfV_WQ=.817ef1a8-a443-4514-8c0d-c9841ccc2b3b@github.com>

On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Change looks ok from a build point of view, but I can't comment on the validity and implications of using this key.
>
> I ran a 3D lighting test that is designed to be a GPU stress test. It's a worst case, to be sure, but it take 10 times as long to render with the integrated GPU as it does with the discrete GPU:
> 
> **attenuation.LightingSample: 500 large quads**
> discrete GPU: 23.5 fps
> integrated GPU: 2.34 fps
> 
> In a more realistic example of drawing a large number of 2D vectors, it runs 35% slower with the integrated GPU:
> 
> **Vector charting test, oval clip**
> discrete GPU: 41.1 fps
> integrated GPU: 26.6 fps
> 
> I see similar results in the performance numbers you listed above.
> 
> An application developer who packages up their JDK, for example, using jpackage, can make the decision for themselves. Application developers who rely on the JDK as delivered will get whatever we choose as the default. So we need to be sure that the benefit of doing this justifies the performance hit.

The difference between the two is that, if the integrated card is default then it is possible to force the discrete card if needed, but it is not possible to force the integrated card if discrete is the default. In the end, it is a laptop, it will work longer on an integrated card.

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

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

From serb at openjdk.java.net  Tue Nov 10 18:44:00 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 10 Nov 2020 18:44:00 GMT
Subject: <AWT Dev> RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
In-Reply-To: <5LNG6nKhwE5XoKjIS9E8Sr5x0IxcFYUcszeGcEck87s=.5d5bb638-c044-4b75-899d-758ed21b872e@github.com>
References: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
 <GNK5tQ1JknvAOBjO-IA2tvR-u9hI8s1pjtoTAtWvj0I=.24099e9b-dc10-4fc9-b4d3-9b167f299721@github.com>
 <5LNG6nKhwE5XoKjIS9E8Sr5x0IxcFYUcszeGcEck87s=.5d5bb638-c044-4b75-899d-758ed21b872e@github.com>
Message-ID: <QgMOABuFZJaZI2cFl_FpaSu26QY_hyWYq8wJQa7Wb1U=.7c630020-ca4f-4a20-8755-3fca5ef042c8@github.com>

On Tue, 10 Nov 2020 09:33:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Update WindowSizeDifferentScreens.java
>>  - Update ListMultipleSelectTest.java
>>  - syncBounds code reformat
>>  - javadoc fix for SunGraphicsEnvironment#toDeviceSpace
>>  - Merge branch 'master' into JDK-8211999
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Merge branch 'master' into JDK-8211999
>>  - Update FullscreenWindowProps.java
>>  - Merge branch 'master' into JDK-8211999
>>  - Fix fullscreen in HiDPI mode
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/1a5e6c98...636b7cc4
>
> src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line 357:
> 
>> 355:      * @param  config the graphics configuration which bounds are requested
>> 356:      * @return the bounds of the area covered by this
>> 357:      *         {@code GraphicsConfiguration} in device space(pixels).
> 
> Suggestion:
> 
>      *         {@code GraphicsConfiguration} in device space (pixels).
> If changed here, all other similar places should be updated too to keep doc comments consistent.

I'll fix it and also merge the master, then update the PR.

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

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

From aivanov at openjdk.java.net  Tue Nov 10 19:38:58 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 10 Nov 2020 19:38:58 GMT
Subject: <AWT Dev> RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
In-Reply-To: <QgMOABuFZJaZI2cFl_FpaSu26QY_hyWYq8wJQa7Wb1U=.7c630020-ca4f-4a20-8755-3fca5ef042c8@github.com>
References: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
 <GNK5tQ1JknvAOBjO-IA2tvR-u9hI8s1pjtoTAtWvj0I=.24099e9b-dc10-4fc9-b4d3-9b167f299721@github.com>
 <5LNG6nKhwE5XoKjIS9E8Sr5x0IxcFYUcszeGcEck87s=.5d5bb638-c044-4b75-899d-758ed21b872e@github.com>
 <QgMOABuFZJaZI2cFl_FpaSu26QY_hyWYq8wJQa7Wb1U=.7c630020-ca4f-4a20-8755-3fca5ef042c8@github.com>
Message-ID: <qdcQkl1PoiPVHcMc34ZuuhznQKyM3fnoK4bB0lJRwIw=.881b8fe9-7194-4a3c-9bf5-26874954dbec@github.com>

On Tue, 10 Nov 2020 18:40:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line 357:
>> 
>>> 355:      * @param  config the graphics configuration which bounds are requested
>>> 356:      * @return the bounds of the area covered by this
>>> 357:      *         {@code GraphicsConfiguration} in device space(pixels).
>> 
>> Suggestion:
>> 
>>      *         {@code GraphicsConfiguration} in device space (pixels).
>> If changed here, all other similar places should be updated too to keep doc comments consistent.
>
> I'll fix it and also merge the master, then update the PR.

In this case, also consider adding a space between the word and the opening parenthesis in these  _coordinates (x, y)_ and _size (w, h)_ and, probably, a space after comma.

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

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

From github.com+31532647+jaysk1 at openjdk.java.net  Tue Nov 10 19:39:56 2020
From: github.com+31532647+jaysk1 at openjdk.java.net (Jayashree S Kumar)
Date: Tue, 10 Nov 2020 19:39:56 GMT
Subject: <AWT Dev> Integrated: JDK-8244088: [Regression] Switch of Gnome
 theme ends up in deadlocked UI
In-Reply-To: <Fxp2TcPqYP--nPpafnEjm87kaovQc6uKyZ67NsWpbYs=.26705240-5d74-4783-bf28-355488c6a217@github.com>
References: <Fxp2TcPqYP--nPpafnEjm87kaovQc6uKyZ67NsWpbYs=.26705240-5d74-4783-bf28-355488c6a217@github.com>
Message-ID: <uZjy2SA2iWXC4c_zAhhYydJ_9NYgCLXlSEUKbZQWjMw=.7176385e-1480-49dc-9775-d982aac8c5ba@github.com>

On Thu, 29 Oct 2020 13:14:49 GMT, Jayashree S Kumar <github.com+31532647+jaysk1 at openjdk.org> wrote:

> Issue
> 
> https://bugs.openjdk.java.net/browse/JDK-8244088
> 
> Problem
> 
> While using GTK3 java implementation,  User sees a deadlock issue in UI while trying to switch themes in gnome-tweak-tool.

This pull request has now been integrated.

Changeset: a7f46919
Author:    Jayashree S Kumar <jayashreesk at in.ibm.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a7f46919
Stats:     5 lines in 3 files changed: 0 ins; 2 del; 3 mod

8244088: [Regression] Switch of Gnome theme ends up in deadlocked UI

Reviewed-by: serb

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

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

From serb at openjdk.java.net  Tue Nov 10 20:38:12 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 10 Nov 2020 20:38:12 GMT
Subject: <AWT Dev> RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v5]
In-Reply-To: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
References: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
Message-ID: <NinzK7ulPTguNc4frEeYSP8GtXcSOraq7g1zC5pZYLc=.0eaea1c0-2db9-4ea9-b5b8-134482be5085@github.com>

> Hello.
> Please review the fix for jdk.
> 
> Old review request:
> https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html
> 
> 
> (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it should be fine for
> Windows 7, because it does not support different DPI for different monitors)
> 
> ========================================================
> Short description:
>      In the multi-screen configurations when each screen have different DPI
>      we calculate the bounds of each monitor by these formulas:
> 
>          userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / scaleX, deviceH / scaleY
>          devSpaceBounds  = userX * scaleX, userY * scaleY, userW * scaleX, userH * scaleY
> 
>   This formula makes the next configuration completely broken:
>     - The main screen on the left and 100% DPI
>     - The second screen on the right and 200% DPI
>   When we translate the bounds of the config from the device space to the user's space,
>      the bounds of both screen overlap in the user's space, because we use bounds of
>      the main screen as-is, and the X/Y of the second screen are divided by the scaleX/Y.
> 
>   Since the screens are overlapped we cannot be sure how to translate the user's space
>    coordinates to device space in the overlapped zone.
>   As a result => we use the wrong screen
>                    => got wrong coordinates in the device space
>                      => show top-level windows/popups/tooltips/menus/etc on the wrong screen
> 
>    The proposed solution for this bug is to change the formulas to these:
> 
>          userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / scaleY
>          devSpaceBounds  = userX, userY, userW * scaleX, userH * scaleY
> 
>    In other words, we should not transform the X and Y coordinates of the screen(the top/left corner). This will
>    complicate the way of how we transform coordinates on the screen: user's <--> device spaces:
> 
>    Before the fix:
> 
>          userX = deviceX * scaleX;
>          deviceX = userX / scaleX;
> 
>    After the fix(only the part appeared on this screen should be scaled)
> 
>          userX = screenX + (deviceX - screenX) * scaleX
>          deviceX = screenX + (userX - screenX) / scaleX
> 
>    Note that these new formulas are applicable only for the coordinates on the screen such as X and Y.
>    If we will need to calculate the "size" such as W and H then the old formula should be used.
> 
>    The main changes for the problem above are:
>    - Skip transformation of X and Y of the screen bounds:
>        http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html
>    - A number of utility methods in java and native:
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html
>    
> 
> ========================================================
> Long description:
>      Unfortunately, the changes above are not enough to fix the problem when different monitors
>      have different DPI, even if the bounds are *NOT* overlapped.
> 
>    - Currently, when we try to set the bounds of the window, we manually convert it in "java" to the
>      expected device position based on the current GraphicsConfiguration of the peer, and then
>      additionally, tweak it in native using the device scale stored in native code. Unfortunately
>      this two scale might not be in sync:(after we use the GraphicsConfiguration scale in peer,
>      the config might be changed and the tweak in native will use a different screen).
> 
>      As a fix I have moved all transformation from the peer to the native code, it will be executed
>      on the toolkit thread:
>      See the change in WWindowPeer.setBounds() and awt_Window.cpp AwtWindow::Reshape
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>      I think at some point we should delete all transformation in java, and apply it in the native code only.
>      
> 
>    - We had a special code that tracked the dragging of the window by the user from one screen to another,
>      and change the size of the window only when the user stops the drag operation. I've proposed to use standard Windows
>      machinery for that via WM_DPICHANGED: https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged
>      As a result, Windows will provide the "best" windows bounds on the new screen. Note that the code has a
>      workaround for https://bugs.openjdk.java.net/browse/JDK-8249164
>   
>    - I've also fix a variation of the bug previously fixed on macOS https://hg.openjdk.java.net/jdk/jdk/rev/b5cdba232fca
>      If we try to change the position of the window, and Windows ignores this request then we need to call all "callbacks" manually, otherwise, the shared code will use the bounds ignored by the Windows.
>      See the end of void AwtWindow::Reshape():
>      http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
> 
>   -  Currently the HW componets such as Canvas scales everything based on such code:
> 
>           770 int AwtComponent::ScaleUpX(int x) {
>           4771     int screen = AwtWin32GraphicsDevice::DeviceIndexForWindow(GetHWnd());
>           4772     Devices::InstanceAccess devices;
>           4773     AwtWin32GraphicsDevice* device = devices->GetDevice(screen);
>           4774     return device == NULL ? x : device->ScaleUpX(x);
>           4775 }
> 
>   But it does not work well if the smaller part of the top-level window is located on one screen1(DPI=100) but
>      the biggest part is located on the screen2(DPI=200). If the Canvas is located on the "smaller" part of the
>      window, then the canvas will use DPI=100 for scale, but the whole window will use DPI=200
> 
>    As a fix, all HW components will try to use the scale factor of the top-level window, see AwtComponent::GetScreenImOn:
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp.sdiff.html
> 
>    - Our current implementation does not take care of the case when the HW component bounds are updated when the top-level
>      the window is moved to another screen. For example, if the window does not use LayoutManager and the user sets some specific bounds for the Canvas. It is expected that the size of the Canvas will be updated when the window will be moved to another screen, but only HW top-level window and Swing components will update its size.
> 
>      As a fix I suggest to resync the bounds of the HW components if the GraphicsCOnfiguration is changed, see WComponentPeer.syncBounds():
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java.sdiff.html
> 
>    - Note that the current fix is for Windows only, but the bug exists on Linux as well, so I have to create a kind of "ifdef" in the
>      Robot class, on windows we will use the new logic, on other platforms the old logic will be used.
> 
>    - The win32GraphicsDevice incorrectly sets the size of the full-screen window. It uses the display mode width/height(which are stored in pixels), but the bounds of the graphics config(which are stored in user's space) should be used.
> 
> ========================================================
> Some other bugs which are not fixed.
> 
>     - We have a lot of places where we mix(unintentionally) the coordinate in user's space and device space.
>       For example when we create the component we read x/y/width/height by the JNI(of course in a user's space)
>       but pass this coordinates as-is to the ::CreateWindowEx() which is incorrect. It works currently
>       because later we reshape the component to the correct bounds. Will fix it later.
> 
>     - When the frame is iconized and we try to save a new bounds for the future use, we store the
>       coordinates in the user's space to the field which use device space:
>       https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664
> 
> Probably there are some other bugs and possibility to cleanups, but I would like to do that in separate issues.
>      
> 
> ========================================================
> The tests
>     - I have updated a couple of the tests to check multiple screens if possible, it helps to found some bugs
>       in my initial implementation
>     - Four new tests were added: SetComponentsBounds, SlowMotion, WindowSizeDifferentScreens, FullscreenWindowProps
>     - One test is moved from the closed repo(I made a small cleanup of it): ListMultipleSelectTest
> 
> ========================================================
> I have run jck, regression tests in different configurations, when the main screen is on the left, up, down,
> right, and have different DPI such as 100, 125, 150, and 200. No new issues were found so far.
> 
> The mach5 is also green.
> 
> PS: hope I did not forget some important information, will send it later if any.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Update SunGraphicsEnvironment.java
 - Merge branch 'master' into JDK-8211999
 - Update WindowSizeDifferentScreens.java
 - Update ListMultipleSelectTest.java
 - syncBounds code reformat
 - javadoc fix for SunGraphicsEnvironment#toDeviceSpace
 - Merge branch 'master' into JDK-8211999
 - Apply suggestions from code review
   
   Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Merge branch 'master' into JDK-8211999
 - Update FullscreenWindowProps.java
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/a7f46919...fd238ef6

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

Changes: https://git.openjdk.java.net/jdk/pull/375/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=375&range=04
  Stats: 1393 lines in 35 files changed: 962 ins; 276 del; 155 mod
  Patch: https://git.openjdk.java.net/jdk/pull/375.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/375/head:pull/375

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

From serb at openjdk.java.net  Tue Nov 10 20:38:12 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 10 Nov 2020 20:38:12 GMT
Subject: <AWT Dev> RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
In-Reply-To: <qdcQkl1PoiPVHcMc34ZuuhznQKyM3fnoK4bB0lJRwIw=.881b8fe9-7194-4a3c-9bf5-26874954dbec@github.com>
References: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
 <GNK5tQ1JknvAOBjO-IA2tvR-u9hI8s1pjtoTAtWvj0I=.24099e9b-dc10-4fc9-b4d3-9b167f299721@github.com>
 <5LNG6nKhwE5XoKjIS9E8Sr5x0IxcFYUcszeGcEck87s=.5d5bb638-c044-4b75-899d-758ed21b872e@github.com>
 <QgMOABuFZJaZI2cFl_FpaSu26QY_hyWYq8wJQa7Wb1U=.7c630020-ca4f-4a20-8755-3fca5ef042c8@github.com>
 <qdcQkl1PoiPVHcMc34ZuuhznQKyM3fnoK4bB0lJRwIw=.881b8fe9-7194-4a3c-9bf5-26874954dbec@github.com>
Message-ID: <CfCuqLTeuQR_Y9bgRrr5zBGF9uL1KkcKhBdcY4uA3EI=.994881dc-5304-4aec-a68c-29ce7a07447b@github.com>

On Tue, 10 Nov 2020 19:35:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I'll fix it and also merge the master, then update the PR.
>
> In this case, also consider adding a space between the word and the opening parenthesis in these  _coordinates (x, y)_ and _size (w, h)_ and, probably, a space after comma.

Spaces are added.

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

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

From serb at openjdk.java.net  Wed Nov 11 01:34:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 11 Nov 2020 01:34:57 GMT
Subject: <AWT Dev> Integrated: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI)
In-Reply-To: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
References: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
Message-ID: <6xdyT0w04J4Q21Cy5LLc2gRnOjyjCHgvDzV6tn9g1KI=.c549d830-c144-4d8e-b4be-464ff836ced0@github.com>

On Sun, 27 Sep 2020 22:16:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hello.
> Please review the fix for jdk.
> 
> Old review request:
> https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html
> 
> 
> (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it should be fine for
> Windows 7, because it does not support different DPI for different monitors)
> 
> ========================================================
> Short description:
>      In the multi-screen configurations when each screen have different DPI
>      we calculate the bounds of each monitor by these formulas:
> 
>          userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / scaleX, deviceH / scaleY
>          devSpaceBounds  = userX * scaleX, userY * scaleY, userW * scaleX, userH * scaleY
> 
>   This formula makes the next configuration completely broken:
>     - The main screen on the left and 100% DPI
>     - The second screen on the right and 200% DPI
>   When we translate the bounds of the config from the device space to the user's space,
>      the bounds of both screen overlap in the user's space, because we use bounds of
>      the main screen as-is, and the X/Y of the second screen are divided by the scaleX/Y.
> 
>   Since the screens are overlapped we cannot be sure how to translate the user's space
>    coordinates to device space in the overlapped zone.
>   As a result => we use the wrong screen
>                    => got wrong coordinates in the device space
>                      => show top-level windows/popups/tooltips/menus/etc on the wrong screen
> 
>    The proposed solution for this bug is to change the formulas to these:
> 
>          userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / scaleY
>          devSpaceBounds  = userX, userY, userW * scaleX, userH * scaleY
> 
>    In other words, we should not transform the X and Y coordinates of the screen(the top/left corner). This will
>    complicate the way of how we transform coordinates on the screen: user's <--> device spaces:
> 
>    Before the fix:
> 
>          userX = deviceX * scaleX;
>          deviceX = userX / scaleX;
> 
>    After the fix(only the part appeared on this screen should be scaled)
> 
>          userX = screenX + (deviceX - screenX) * scaleX
>          deviceX = screenX + (userX - screenX) / scaleX
> 
>    Note that these new formulas are applicable only for the coordinates on the screen such as X and Y.
>    If we will need to calculate the "size" such as W and H then the old formula should be used.
> 
>    The main changes for the problem above are:
>    - Skip transformation of X and Y of the screen bounds:
>        http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html
>    - A number of utility methods in java and native:
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html
>    
> 
> ========================================================
> Long description:
>      Unfortunately, the changes above are not enough to fix the problem when different monitors
>      have different DPI, even if the bounds are *NOT* overlapped.
> 
>    - Currently, when we try to set the bounds of the window, we manually convert it in "java" to the
>      expected device position based on the current GraphicsConfiguration of the peer, and then
>      additionally, tweak it in native using the device scale stored in native code. Unfortunately
>      this two scale might not be in sync:(after we use the GraphicsConfiguration scale in peer,
>      the config might be changed and the tweak in native will use a different screen).
> 
>      As a fix I have moved all transformation from the peer to the native code, it will be executed
>      on the toolkit thread:
>      See the change in WWindowPeer.setBounds() and awt_Window.cpp AwtWindow::Reshape
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>      I think at some point we should delete all transformation in java, and apply it in the native code only.
>      
> 
>    - We had a special code that tracked the dragging of the window by the user from one screen to another,
>      and change the size of the window only when the user stops the drag operation. I've proposed to use standard Windows
>      machinery for that via WM_DPICHANGED: https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged
>      As a result, Windows will provide the "best" windows bounds on the new screen. Note that the code has a
>      workaround for https://bugs.openjdk.java.net/browse/JDK-8249164
>   
>    - I've also fix a variation of the bug previously fixed on macOS https://hg.openjdk.java.net/jdk/jdk/rev/b5cdba232fca
>      If we try to change the position of the window, and Windows ignores this request then we need to call all "callbacks" manually, otherwise, the shared code will use the bounds ignored by the Windows.
>      See the end of void AwtWindow::Reshape():
>      http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
> 
>   -  Currently the HW componets such as Canvas scales everything based on such code:
> 
>           770 int AwtComponent::ScaleUpX(int x) {
>           4771     int screen = AwtWin32GraphicsDevice::DeviceIndexForWindow(GetHWnd());
>           4772     Devices::InstanceAccess devices;
>           4773     AwtWin32GraphicsDevice* device = devices->GetDevice(screen);
>           4774     return device == NULL ? x : device->ScaleUpX(x);
>           4775 }
> 
>   But it does not work well if the smaller part of the top-level window is located on one screen1(DPI=100) but
>      the biggest part is located on the screen2(DPI=200). If the Canvas is located on the "smaller" part of the
>      window, then the canvas will use DPI=100 for scale, but the whole window will use DPI=200
> 
>    As a fix, all HW components will try to use the scale factor of the top-level window, see AwtComponent::GetScreenImOn:
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp.sdiff.html
> 
>    - Our current implementation does not take care of the case when the HW component bounds are updated when the top-level
>      the window is moved to another screen. For example, if the window does not use LayoutManager and the user sets some specific bounds for the Canvas. It is expected that the size of the Canvas will be updated when the window will be moved to another screen, but only HW top-level window and Swing components will update its size.
> 
>      As a fix I suggest to resync the bounds of the HW components if the GraphicsCOnfiguration is changed, see WComponentPeer.syncBounds():
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java.sdiff.html
> 
>    - Note that the current fix is for Windows only, but the bug exists on Linux as well, so I have to create a kind of "ifdef" in the
>      Robot class, on windows we will use the new logic, on other platforms the old logic will be used.
> 
>    - The win32GraphicsDevice incorrectly sets the size of the full-screen window. It uses the display mode width/height(which are stored in pixels), but the bounds of the graphics config(which are stored in user's space) should be used.
> 
> ========================================================
> Some other bugs which are not fixed.
> 
>     - We have a lot of places where we mix(unintentionally) the coordinate in user's space and device space.
>       For example when we create the component we read x/y/width/height by the JNI(of course in a user's space)
>       but pass this coordinates as-is to the ::CreateWindowEx() which is incorrect. It works currently
>       because later we reshape the component to the correct bounds. Will fix it later.
> 
>     - When the frame is iconized and we try to save a new bounds for the future use, we store the
>       coordinates in the user's space to the field which use device space:
>       https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664
> 
> Probably there are some other bugs and possibility to cleanups, but I would like to do that in separate issues.
>      
> 
> ========================================================
> The tests
>     - I have updated a couple of the tests to check multiple screens if possible, it helps to found some bugs
>       in my initial implementation
>     - Four new tests were added: SetComponentsBounds, SlowMotion, WindowSizeDifferentScreens, FullscreenWindowProps
>     - One test is moved from the closed repo(I made a small cleanup of it): ListMultipleSelectTest
> 
> ========================================================
> I have run jck, regression tests in different configurations, when the main screen is on the left, up, down,
> right, and have different DPI such as 100, 125, 150, and 200. No new issues were found so far.
> 
> The mach5 is also green.
> 
> PS: hope I did not forget some important information, will send it later if any.

This pull request has now been integrated.

Changeset: be635258
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/be635258
Stats:     1393 lines in 35 files changed: 962 ins; 276 del; 155 mod

8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI)

Reviewed-by: kizune, aivanov

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

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

From serb at openjdk.java.net  Thu Nov 12 09:14:02 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 12 Nov 2020 09:14:02 GMT
Subject: <AWT Dev> RFR: 8256201:
 java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java failed
Message-ID: <MXZ8gCr0KTS1zE89fnCwJYyKXUKRuBVX8by29LmWEmU=.2412e42e-7f1f-427e-b7df-e9baf1795488@github.com>

The new test added in JDK-8211999 hits a bug on Linux (in mach5 it is passed on ubuntu 18.04 and failed on 20.04). The problem is that the bounds of the fullscreen frame include insets of the frame additionally to the screen size.

The behavior of the decorated full-screen window is not specified:
https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/GraphicsDevice.html#setFullScreenWindow(java.awt.Window)

But it will be good to have the same cross-platform behavior. So I filed a separate bug to investigate the behavior of decorated frame in the fullscreen mode:
https://bugs.openjdk.java.net/browse/JDK-8256257

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

Commit messages:
 - Update FullscreenWindowProps.java

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

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

From alexsch at openjdk.java.net  Thu Nov 12 10:37:06 2020
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Thu, 12 Nov 2020 10:37:06 GMT
Subject: <AWT Dev> RFR: 8256264: Printed GlyphVector outline with low DPI
 has bad quality on Windows
Message-ID: <iA4R8RQHqStufCJRG2qB5tJODvX-mIlqv392YbdNE84=.5bfe5fa6-6062-45ec-aebd-d193cf8b76c6@github.com>

Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows.
The GDI system used for text printing on Windows accepts only integer path coordinates.
Rounding GlyphVector outline coordinates leads to distorted printed text.

To reproduce the issue run the [PrintGlyphVectorOutlineSample](https://bugs.openjdk.java.net/secure/attachment/91398/PrintGlyphVectorOutlineSample.java)  file on Windows and select a low DPI
printer in the printer dialog. The sample prints two lines, one using Graphics drawString() method and another by
filling GlyphVector outline. Chars on the second line are distorted.

It is also possible to reproduce the issue running the sample and printing the text to PDF: [fill-glyph-vector-outline.png](https://bugs.openjdk.java.net/secure/attachment/91397/fill-glyph-vector-outline.png)

The proposed fix introduce "sun.java2d.print.enablePathPrecisionScale" property which being enabled
scales the GDI WorldTransform down and GlyphVector outline coordinates up.
This allows to keep some digits after a dot from being rounded.
The value for scaling is chosen to be 1000 in the same way how it is used  by `String trunc(float f)` method from PSPrinterJob class on Linux:
https://github.com/openjdk/jdk/blob/ed615e3ca0d681e8e67cdbf1d5d964979ccd7888/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#L1489

See the  [fill-glyph-vector-outline-enable-path-scale-factor.png](https://bugs.openjdk.java.net/secure/attachment/91399/fill-glyph-vector-outline-enable-path-scale-factor.png) screenshot which shows how the GlyphVector outline is filled after the fix with the enabled "sun.java2d.print.enablePathPrecisionScale" option.

[fill-glyph-vector-outline-diff.png](https://bugs.openjdk.java.net/secure/attachment/91400/fill-glyph-vector-outline-diff.png) shows difference of GlyphVector outline printing before and after the fix.

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

Commit messages:
 - 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows

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

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

From jdv at openjdk.java.net  Thu Nov 12 16:56:01 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 12 Nov 2020 16:56:01 GMT
Subject: <AWT Dev> RFR: 8256201:
 java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java failed
In-Reply-To: <MXZ8gCr0KTS1zE89fnCwJYyKXUKRuBVX8by29LmWEmU=.2412e42e-7f1f-427e-b7df-e9baf1795488@github.com>
References: <MXZ8gCr0KTS1zE89fnCwJYyKXUKRuBVX8by29LmWEmU=.2412e42e-7f1f-427e-b7df-e9baf1795488@github.com>
Message-ID: <jljrPwXoX_DQ1upHufgFmveFuiLXSc3F-1hwVJUb9Fo=.624f2a02-e8ce-4bf2-8364-f1d08647dde1@github.com>

On Thu, 12 Nov 2020 08:46:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The new test added in JDK-8211999 hits a bug on Linux (in mach5 it is passed on ubuntu 18.04 and failed on 20.04). The problem is that the bounds of the fullscreen frame include insets of the frame additionally to the screen size.
> 
> The behavior of the decorated full-screen window is not specified:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/GraphicsDevice.html#setFullScreenWindow(java.awt.Window)
> 
> But it will be good to have the same cross-platform behavior. So I filed a separate bug to investigate the behavior of decorated frame in the fullscreen mode:
> https://bugs.openjdk.java.net/browse/JDK-8256257

Marked as reviewed by jdv (Reviewer).

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

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

From serb at openjdk.java.net  Thu Nov 12 17:04:00 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 12 Nov 2020 17:04:00 GMT
Subject: <AWT Dev> Integrated: 8256201:
 java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java failed
In-Reply-To: <MXZ8gCr0KTS1zE89fnCwJYyKXUKRuBVX8by29LmWEmU=.2412e42e-7f1f-427e-b7df-e9baf1795488@github.com>
References: <MXZ8gCr0KTS1zE89fnCwJYyKXUKRuBVX8by29LmWEmU=.2412e42e-7f1f-427e-b7df-e9baf1795488@github.com>
Message-ID: <oMbX9Oxna43Y3qcLpVaHwTfP74CsjCwwka152VYuQJM=.d614ca97-dc8b-4edf-9e07-52c30bbaf874@github.com>

On Thu, 12 Nov 2020 08:46:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The new test added in JDK-8211999 hits a bug on Linux (in mach5 it is passed on ubuntu 18.04 and failed on 20.04). The problem is that the bounds of the fullscreen frame include insets of the frame additionally to the screen size.
> 
> The behavior of the decorated full-screen window is not specified:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/GraphicsDevice.html#setFullScreenWindow(java.awt.Window)
> 
> But it will be good to have the same cross-platform behavior. So I filed a separate bug to investigate the behavior of decorated frame in the fullscreen mode:
> https://bugs.openjdk.java.net/browse/JDK-8256257

This pull request has now been integrated.

Changeset: 1c0b490c
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1c0b490c
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8256201: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java failed

Reviewed-by: jdv

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

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

From herrick at openjdk.java.net  Thu Nov 12 18:32:02 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 12 Nov 2020 18:32:02 GMT
Subject: <AWT Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <j3MK4sBx_azdu0U4AH9Ys6cO9i7225Sku6Qqzy5CiyU=.05465f80-fd5b-46fd-821f-e3d8f07b2527@github.com>

On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8189198: Add "forRemoval = true" to Applet APIs

preliminary changes for JDK-8189198 for evaluation

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

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

From herrick at openjdk.java.net  Thu Nov 12 18:32:02 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 12 Nov 2020 18:32:02 GMT
Subject: <AWT Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs
Message-ID: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>

JDK-8189198: Add "forRemoval = true" to Applet APIs

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

Commit messages:
 - Merge branch 'master' into JDK-8189198
 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - JDK-8189198: Add "forRemoval = true" to Applet APIs

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

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

From kcr at openjdk.java.net  Thu Nov 12 19:22:01 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 12 Nov 2020 19:22:01 GMT
Subject: <AWT Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs
In-Reply-To: <j3MK4sBx_azdu0U4AH9Ys6cO9i7225Sku6Qqzy5CiyU=.05465f80-fd5b-46fd-821f-e3d8f07b2527@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <j3MK4sBx_azdu0U4AH9Ys6cO9i7225Sku6Qqzy5CiyU=.05465f80-fd5b-46fd-821f-e3d8f07b2527@github.com>
Message-ID: <GvP5LlxK0ocbdaxXbPDFAtX1v3sIZav1dHpSi54EEdg=.e2f907f8-d9e5-4910-be6a-6ec83f9d1ef9@github.com>

On Mon, 9 Nov 2020 13:57:32 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> preliminary changes for JDK-8189198 for evaluation

The following field, which is currently deprecated (not for removal) should probably also be marked as deprecated for removal::

javax.naming.Context:
    static final String APPLET

The CSR and JEP should be updated accordingly.

Also, what about the following?

javax.swing.text.html.parser.DTD
    Element applet

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

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

From iris at openjdk.java.net  Thu Nov 12 19:40:54 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 12 Nov 2020 19:40:54 GMT
Subject: <AWT Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <1hu3mjRsBg1gnnWXUNl9TQ8PoPFjmGOaXkr6Vdd4mOo=.7ead6f18-6b34-42e4-adfb-756ada49eb61@github.com>

On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8189198: Add "forRemoval = true" to Applet APIs

Since all APIs in the java.applet package are deprecated "forRemoval = true", consider adding a brief deprecation note to java/applet/package-info.java too.

As an example, when all of the APIs in package java.rmi.activation were similarly deprecated in JDK 15, the following note was added: 

https://docs.oracle.com/en/java/javase/15/docs/api/java.rmi/java/rmi/activation/package-summary.html .

Thanks!
Iris

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

Marked as reviewed by iris (Reviewer).

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

From herrick at openjdk.java.net  Thu Nov 12 20:48:13 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 12 Nov 2020 20:48:13 GMT
Subject: <AWT Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v2]
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>

> JDK-8189198: Add "forRemoval = true" to Applet APIs

Andy Herrick 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 six additional commits since the last revision:

 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - Merge branch 'master' into JDK-8189198
 - Merge branch 'master' into JDK-8189198
 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - JDK-8189198: Add "forRemoval = true" to Applet APIs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1127/files
  - new: https://git.openjdk.java.net/jdk/pull/1127/files/a74deeee..d9850cd8

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

  Stats: 7753 lines in 89 files changed: 4891 ins; 1603 del; 1259 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1127/head:pull/1127

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

From almatvee at openjdk.java.net  Thu Nov 12 23:52:56 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 12 Nov 2020 23:52:56 GMT
Subject: <AWT Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v2]
In-Reply-To: <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
Message-ID: <JVMXf2S7V5H6rariy6z8YkOGlh3YAtu2O6TWup0KeyY=.729335e8-4acc-4146-be1f-f5329cd98caf@github.com>

On Thu, 12 Nov 2020 20:48:13 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> Andy Herrick 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 six additional commits since the last revision:
> 
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - Merge branch 'master' into JDK-8189198
>  - Merge branch 'master' into JDK-8189198
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs

Marked as reviewed by almatvee (Committer).

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

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

From kcr at openjdk.java.net  Fri Nov 13 00:27:58 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 13 Nov 2020 00:27:58 GMT
Subject: <AWT Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <Ycx4b7aaw5u8aiSS2NkJhWpuXdQjIRVbEn4DZautriM=.bbab7054-a46f-49c7-b8b7-ee0174aaa8b8@github.com>

On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8189198: Add "forRemoval = true" to Applet APIs

@andyherrick can you enter the `/csr needed` command? I would, but it needs to be done by either the author of the PR or a Reviewer.

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

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

From alanb at openjdk.java.net  Fri Nov 13 09:35:00 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 13 Nov 2020 09:35:00 GMT
Subject: <AWT Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v2]
In-Reply-To: <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
Message-ID: <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>

On Thu, 12 Nov 2020 20:48:13 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> Andy Herrick 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 six additional commits since the last revision:
> 
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - Merge branch 'master' into JDK-8189198
>  - Merge branch 'master' into JDK-8189198
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs

src/java.naming/share/classes/javax/naming/Context.java line 1087:

> 1085:     @Deprecated(since="16", forRemoval=true)
> 1086:     String APPLET = "java.naming.applet";
> 1087: };

Probably should be since="9" (the deprecation in JDK-8051422 pre-dates the enhanced deprecation work).

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

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

From herrick at openjdk.java.net  Fri Nov 13 15:05:15 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 13 Nov 2020 15:05:15 GMT
Subject: <AWT Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v3]
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>

> JDK-8189198: Add "forRemoval = true" to Applet APIs

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

  JDK-8189198: Add "forRemoval = true" to Applet APIs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1127/files
  - new: https://git.openjdk.java.net/jdk/pull/1127/files/d9850cd8..c6ea7714

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

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

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

From kcr at openjdk.java.net  Fri Nov 13 18:03:59 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 13 Nov 2020 18:03:59 GMT
Subject: <AWT Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v2]
In-Reply-To: <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
 <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>
Message-ID: <mot16WfbcRFgGyIX69OOOuf0ci4YY6zH1DcHnNVwM9g=.39da06f9-1bf8-47cf-9d99-a7b29b999ffa@github.com>

On Fri, 13 Nov 2020 09:31:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andy Herrick 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 six additional commits since the last revision:
>> 
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>>  - Merge branch 'master' into JDK-8189198
>>  - Merge branch 'master' into JDK-8189198
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> src/java.naming/share/classes/javax/naming/Context.java line 1087:
> 
>> 1085:     @Deprecated(since="16", forRemoval=true)
>> 1086:     String APPLET = "java.naming.applet";
>> 1087: };
> 
> Probably should be since="9" (the deprecation in JDK-8051422 pre-dates the enhanced deprecation work).

Good point, since it was in fact deprecated in 9.

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

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

From kcr at openjdk.java.net  Fri Nov 13 18:23:02 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 13 Nov 2020 18:23:02 GMT
Subject: <AWT Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v3]
In-Reply-To: <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>
Message-ID: <2YW5WLSFQN87oSb4c-t2jsiflm8TmSyLH_ByIc9lq2U=.647a0363-4fea-4550-bb90-91603e5b842c@github.com>

On Fri, 13 Nov 2020 15:05:15 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8189198: Add "forRemoval = true" to Applet APIs

src/java.desktop/share/classes/java/applet/package-info.java line 40:

> 38:  * <p>
> 39:  * Deprecated.
> 40:  * This package has been deprecated and may be removed in a future version of the Java Platform.

That should be `@deprecated This package ...`. See [java/rmi/activation/package-info.java#L41](https://github.com/openjdk/jdk/blob/master/src/java.rmi/share/classes/java/rmi/activation/package-info.java#L41).

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

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

From herrick at openjdk.java.net  Fri Nov 13 18:22:59 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 13 Nov 2020 18:22:59 GMT
Subject: <AWT Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v2]
In-Reply-To: <mot16WfbcRFgGyIX69OOOuf0ci4YY6zH1DcHnNVwM9g=.39da06f9-1bf8-47cf-9d99-a7b29b999ffa@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
 <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>
 <mot16WfbcRFgGyIX69OOOuf0ci4YY6zH1DcHnNVwM9g=.39da06f9-1bf8-47cf-9d99-a7b29b999ffa@github.com>
Message-ID: <gYa0bATGPUhfwxiRzpSFAjvkqohOGexGE2wtQOhzU2A=.0686d174-96f9-48c3-8bce-2222bdf38e3b@github.com>

On Fri, 13 Nov 2020 18:01:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> src/java.naming/share/classes/javax/naming/Context.java line 1087:
>> 
>>> 1085:     @Deprecated(since="16", forRemoval=true)
>>> 1086:     String APPLET = "java.naming.applet";
>>> 1087: };
>> 
>> Probably should be since="9" (the deprecation in JDK-8051422 pre-dates the enhanced deprecation work).
>
> Good point, since it was in fact deprecated in 9.

yes - changed to since="9" this morning

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

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

From serb at openjdk.java.net  Fri Nov 13 23:29:59 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 13 Nov 2020 23:29:59 GMT
Subject: <AWT Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v3]
In-Reply-To: <2YW5WLSFQN87oSb4c-t2jsiflm8TmSyLH_ByIc9lq2U=.647a0363-4fea-4550-bb90-91603e5b842c@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>
 <2YW5WLSFQN87oSb4c-t2jsiflm8TmSyLH_ByIc9lq2U=.647a0363-4fea-4550-bb90-91603e5b842c@github.com>
Message-ID: <duVZxCWBKhVJrPXH4TcaSygW8i99rc9pLXcJe1bXC_s=.5bc72434-59bb-44d8-a957-9c391237397e@github.com>

On Fri, 13 Nov 2020 18:20:37 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> src/java.desktop/share/classes/java/applet/package-info.java line 40:
> 
>> 38:  * <p>
>> 39:  * Deprecated.
>> 40:  * This package has been deprecated and may be removed in a future version of the Java Platform.
> 
> That should be `@deprecated This package ...`. See [java/rmi/activation/package-info.java#L41](https://github.com/openjdk/jdk/blob/master/src/java.rmi/share/classes/java/rmi/activation/package-info.java#L41).

The deprecation description should point to the new API which might be used instead of the deprecated ones. So the text "deprecated without replacement" was intentionally added, it will be good to preserve it.

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

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

From serb at openjdk.java.net  Sat Nov 14 00:27:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 14 Nov 2020 00:27:55 GMT
Subject: <AWT Dev> RFR: 8254024: Enhance native libs for AWT and Swing
 to work with GraalVM Native Image
In-Reply-To: <KdtSni2r8p8F3aKOPKeoBxUK6dmLQZ-ZYvlppfZWrN4=.77af7a43-eadf-45ed-bc2b-d0ecf74a8489@github.com>
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>
 <wTu1KYcM4mGcl9vJo1801bSz7TjmPfJe0qcdTGk2VLw=.0f813dd3-1a65-4981-8366-015c53afa6de@github.com>
 <nuRBeOsQfK-e8AlOYqbNCkA5PBvq2fkn3ajD5qO6EEA=.af41b9fe-d3be-4daf-b9be-c995fa6dd655@github.com>
 <ntRWXDeM6dkIdJY35CONCg8CorrhGmOvGpoq4j-OnSg=.69e9f9c2-754f-438b-960f-0a13daca0309@github.com>
 <o5PqI-0JlvEgEy-KXilJvFKyX3vNJnMH9nAgcBoABdg=.80d5f6a9-d68b-4a26-97ac-3b66bfb5d313@github.com>
 <p75sm7bljXhbCvv_co0gnczxO_sAYfDjwmYDBRRZKsg=.f33ca87f-4700-4348-8ffd-137c00b2395b@github.com>
 <v2MRHheWZJuZyYs2e7HHYTWGFd-MQplZco5JPcvPPCs=.02ffe15c-4b94-45ab-96fa-ac8e5de450ef@github.com>
 <QzfezoU2Z6pAhQPucs_Tj7qhCp-pnT1xJNeGaY8ZIIs=.1a8f82c9-2ee5-482b-b2a7-c76e03359a1f@github.com>
 <2hFTjMReXMfiNjTWswTV5EyEA7zFoEIbepsyelAcPeU=.fe56a018-3429-420c-b47f-274a400cc989@github.com>
 <QrK00iKoap7foOlhN2iMP2db0Rzae-oOB0FQBlZpHIk=.c61d95ae-bdae-4f58-a6c1-ee0e610ee442@github.com>
 <uKRfxak1vC1q-Gq_wT-SZewnJECciGLipTz
 Szgsp5_4=.2ee8c653-ab49-4be9-a7e9-5013d35676f3@github.com>
 <eDjJrOr_NkjJe4_vziRSrGby_Y0JZ6WIAioNPfY2pCM=.b67111ed-896f-4096-84c2-53f51290ad94@github.com>
 <MLCPQ7F1i88ra5xzd1BRcBbMTRxArgfxu6tc-s1o4ZM=.294480d9-043e-4e56-bfad-4d06c83c445b@github.com>
 <jbxDix7bNUsNqPh0BQDqNqqSkXXPax4ut8fS5odCrqI=.82c96792-e691-46ab-9756-d444adb6b186@github.com>
 <KdtSni2r8p8F3aKOPKeoBxUK6dmLQZ-ZYvlppfZWrN4=.77af7a43-eadf-45ed-bc2b-d0ecf74a8489@github.com>
Message-ID: <bX2VsAGYYiqMHGhqoNYVZa08lXtv6HWkYc8G9meDLiM=.8524069e-bd6d-44af-9a92-c273774b66a3@github.com>

On Tue, 10 Nov 2020 01:09:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @mrserb With the last dev build of GraalVM based on JDK 11.09, the bug can be reproduced by the approach that I've mentioned above.
>> The general steps: 
>> - download the [last dev build](https://github.com/graalvm/graalvm-ce-dev-builds/releases) of GraalVM + Native image 
>> - build the native image for AWTFixExample class (ziped configs for reflection and JNI is attached): 
>> `$ ~/graalvm-ce-java11-21.0.0-dev/bin/native-image -H:ConfigurationFileDirectories=./configs -Djava.awt.headless=true --native-image-info AWTFixExample`
>> - run built image - it should be executed successfully
>> - clone any version of the OpenJDK (11.09 - 16)
>> - build static libraries by executing `make static-libs-image` target 
>> - replace `libawt.a` in GraalVM on built static library from OpenJDK
>> - try to build example again and run it - it should be failed
>> - clone OpenJDK with the proposed fix
>> - build static libraries
>> - replace `libawt.a` in GraalVM on built static library with the fix
>> - build example and run it - it should be executed successfully
>> 
>> public class AWTFixExample {
>>     public static void main(String[] args) {
>>         float[] data = new float[]{0.0f, 1.1f, 2.2f, 3.3f, 4.4f, 5.5f, 6.6f, 7.7f, 8.8f};
>>         Kernel kernel = new Kernel(3, 3, data);
>>         ConvolveOp op = new ConvolveOp(kernel);
>> 
>>         BufferedImage src = new BufferedImage(10, 10, BufferedImage.TYPE_INT_ARGB);
>>         BufferedImage dest = new BufferedImage(10, 10, BufferedImage.TYPE_INT_ARGB);
>> 
>>         BufferedImage image = op.filter(src, dest);
>>         System.out.println(image);
>>     }
>> }
>> 
>> [configs.zip](https://github.com/openjdk/jdk/files/5490906/configs.zip)
>
> I think part of the changed code is actually dead code and can be removed, I'll take a look.

The changes in awt_LoadLibrary.c and XToolkit.c is mostly noop except excluding dladdr/dlopen. Since XsessionWMcommand/AWTIsHeadless are not used at least in the mainline(jdk16).
The changes in the mlib look fine.

The testing is in progress.

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

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

From serb at openjdk.java.net  Sat Nov 14 00:27:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 14 Nov 2020 00:27:55 GMT
Subject: <AWT Dev> RFR: 8254024: Enhance native libs for AWT and Swing
 to work with GraalVM Native Image
In-Reply-To: <bX2VsAGYYiqMHGhqoNYVZa08lXtv6HWkYc8G9meDLiM=.8524069e-bd6d-44af-9a92-c273774b66a3@github.com>
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>
 <wTu1KYcM4mGcl9vJo1801bSz7TjmPfJe0qcdTGk2VLw=.0f813dd3-1a65-4981-8366-015c53afa6de@github.com>
 <nuRBeOsQfK-e8AlOYqbNCkA5PBvq2fkn3ajD5qO6EEA=.af41b9fe-d3be-4daf-b9be-c995fa6dd655@github.com>
 <ntRWXDeM6dkIdJY35CONCg8CorrhGmOvGpoq4j-OnSg=.69e9f9c2-754f-438b-960f-0a13daca0309@github.com>
 <o5PqI-0JlvEgEy-KXilJvFKyX3vNJnMH9nAgcBoABdg=.80d5f6a9-d68b-4a26-97ac-3b66bfb5d313@github.com>
 <p75sm7bljXhbCvv_co0gnczxO_sAYfDjwmYDBRRZKsg=.f33ca87f-4700-4348-8ffd-137c00b2395b@github.com>
 <v2MRHheWZJuZyYs2e7HHYTWGFd-MQplZco5JPcvPPCs=.02ffe15c-4b94-45ab-96fa-ac8e5de450ef@github.com>
 <QzfezoU2Z6pAhQPucs_Tj7qhCp-pnT1xJNeGaY8ZIIs=.1a8f82c9-2ee5-482b-b2a7-c76e03359a1f@github.com>
 <2hFTjMReXMfiNjTWswTV5EyEA7zFoEIbepsyelAcPeU=.fe56a018-3429-420c-b47f-274a400cc989@github.com>
 <QrK00iKoap7foOlhN2iMP2db0Rzae-oOB0FQBlZpHIk=.c61d95ae-bdae-4f58-a6c1-ee0e610ee442@github.com>
 <uKRfxak1vC1q-Gq_wT-SZewnJECciGLipTz
 Szgsp5_4=.2ee8c653-ab49-4be9-a7e9-5013d35676f3@github.com>
 <eDjJrOr_NkjJe4_vziRSrGby_Y0JZ6WIAioNPfY2pCM=.b67111ed-896f-4096-84c2-53f51290ad94@github.com>
 <MLCPQ7F1i88ra5xzd1BRcBbMTRxArgfxu6tc-s1o4ZM=.294480d9-043e-4e56-bfad-4d06c83c445b@github.com>
 <jbxDix7bNUsNqPh0BQDqNqqSkXXPax4ut8fS5odCrqI=.82c96792-e691-46ab-9756-d444adb6b186@github.com>
 <KdtSni2r8p8F3aKOPKeoBxUK6dmLQZ-ZYvlppfZWrN4=.77af7a43-eadf-45ed-bc2b-d0ecf74a8489@github.com>
 <bX2VsAGYYiqMHGhqoNYVZa08lXtv6HWkYc8G9meDLiM=.8524069e-bd6d-44af-9a92-c273774b66a3@github.com>
Message-ID: <xOo0CtO8uhLGrSiROM30bY_bS1mKl-4vlK68eIOSxkM=.8d83e016-a7b0-4f0e-a2b0-f0221e5fba56@github.com>

On Sat, 14 Nov 2020 00:23:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I think part of the changed code is actually dead code and can be removed, I'll take a look.
>
> The changes in awt_LoadLibrary.c and XToolkit.c is mostly noop except excluding dladdr/dlopen. Since XsessionWMcommand/AWTIsHeadless are not used at least in the mainline(jdk16).
> The changes in the mlib look fine.
> 
> The testing is in progress.

please merge the master to this branch, it is quite outdated, and update the last copyright date to 2020.

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

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

From herrick at openjdk.java.net  Sun Nov 15 19:09:07 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Sun, 15 Nov 2020 19:09:07 GMT
Subject: <AWT Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v4]
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <n07B5X31Of1E-zQbdfwwtShOQ54zESY2s6oQQ8npBNU=.1beb38c9-1241-44cb-bf64-e64e0c9b3ea5@github.com>

> JDK-8189198: Add "forRemoval = true" to Applet APIs

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

  JDK-8189198: Add "forRemoval = true" to Applet APIs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1127/files
  - new: https://git.openjdk.java.net/jdk/pull/1127/files/c6ea7714..bc781bea

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

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

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

From serb at openjdk.java.net  Mon Nov 16 03:43:07 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 16 Nov 2020 03:43:07 GMT
Subject: <AWT Dev> RFR: 8256373: [Windows/HiDPI] The Frame#setBounds does
 not work in a minimized state
Message-ID: <rnMuc8fXGxVXCbogchpWBX_95FZkt1NrSC52QfdfhwU=.4473141b-66d1-4f0a-aa3a-6d4b9e4f575c@github.com>

On HIDPI Windows, the Frame#setBounds does not work in a minimized state. The bug found during the development of JDK-8211999. When the frame is iconized and we try to save new bounds for future use, we store the coordinates in the user's space to the field which use device space:
https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664

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

Commit messages:
 - Initial fix

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

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

From tnakamura at openjdk.java.net  Mon Nov 16 13:15:14 2020
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Mon, 16 Nov 2020 13:15:14 GMT
Subject: <AWT Dev> RFR: 8255387: Japanese characters were printed upside
 down on AIX
Message-ID: <-zl1EqjwYppCrp7Wdifz42Jagial2KqVXkEbAxMciUc=.5b75c16d-f0e8-427f-b3b4-62aca0076732@github.com>

Hi,

Could you review this fix? Under some special conditions, non-English characters were printed upside down.

At printing with raster image, the image was generated from bottom to top. So, each characters should also be drawn as vertical mirrored. However, freetype doesn't support to transform it if the font is using embedded bitmap and non-English. As the result, these Japanese characters were printed as upside down.

In this case, freetype should be prevented to use embedded bitmap.

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

Commit messages:
 - 8255387: Japanese characters were printed upside down on AIX
 - 8255387: Japanese characters were printed upside down on AIX

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

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

From vdyakov at openjdk.java.net  Tue Nov 17 18:22:06 2020
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Tue, 17 Nov 2020 18:22:06 GMT
Subject: <AWT Dev> RFR: 8251854: [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com>
References: <Nf052gV_cPeWE9lYgIOeus5BZZXi_Pc-BFICzqLVO4A=.8fb05764-e448-4c82-91a6-cecbb2ed6b2e@github.com>
 <epFJBT7ojxv5e7lJwX92LkMtHvFnWDTsiXg6SIcxFf8=.0b6d23db-89de-4521-89ef-5c0002968d90@github.com>
 <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com>
Message-ID: <FUrLkNpJsIswb3uqovEbwbThfyeD5L9-CEGNknAUm84=.1bda9a5f-b686-4ed0-accd-843e56815bc9@github.com>

On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Change looks ok from a build point of view, but I can't comment on the validity and implications of using this key.
>
> I ran a 3D lighting test that is designed to be a GPU stress test. It's a worst case, to be sure, but it take 10 times as long to render with the integrated GPU as it does with the discrete GPU:
> 
> **attenuation.LightingSample: 500 large quads**
> discrete GPU: 23.5 fps
> integrated GPU: 2.34 fps
> 
> In a more realistic example of drawing a large number of 2D vectors, it runs 35% slower with the integrated GPU:
> 
> **Vector charting test, oval clip**
> discrete GPU: 41.1 fps
> integrated GPU: 26.6 fps
> 
> I see similar results in the performance numbers you listed above.
> 
> An application developer who packages up their JDK, for example, using jpackage, can make the decision for themselves. Application developers who rely on the JDK as delivered will get whatever we choose as the default. So we need to be sure that the benefit of doing this justifies the performance hit.

@kevinrushforth  @prrace could you please review?

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

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

From prr at openjdk.java.net  Tue Nov 17 18:44:08 2020
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 17 Nov 2020 18:44:08 GMT
Subject: <AWT Dev> RFR: 8251854: [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com>
References: <Nf052gV_cPeWE9lYgIOeus5BZZXi_Pc-BFICzqLVO4A=.8fb05764-e448-4c82-91a6-cecbb2ed6b2e@github.com>
 <epFJBT7ojxv5e7lJwX92LkMtHvFnWDTsiXg6SIcxFf8=.0b6d23db-89de-4521-89ef-5c0002968d90@github.com>
 <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com>
Message-ID: <dubtBvgqgRYk_S_K_gdYWcNB_FYwGluxnzL_NSc9YWE=.c2fd6415-5620-4610-8ef1-828ab5de07f5@github.com>

On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Change looks ok from a build point of view, but I can't comment on the validity and implications of using this key.
>
> I ran a 3D lighting test that is designed to be a GPU stress test. It's a worst case, to be sure, but it take 10 times as long to render with the integrated GPU as it does with the discrete GPU:
> 
> **attenuation.LightingSample: 500 large quads**
> discrete GPU: 23.5 fps
> integrated GPU: 2.34 fps
> 
> In a more realistic example of drawing a large number of 2D vectors, it runs 35% slower with the integrated GPU:
> 
> **Vector charting test, oval clip**
> discrete GPU: 41.1 fps
> integrated GPU: 26.6 fps
> 
> I see similar results in the performance numbers you listed above.
> 
> An application developer who packages up their JDK, for example, using jpackage, can make the decision for themselves. Application developers who rely on the JDK as delivered will get whatever we choose as the default. So we need to be sure that the benefit of doing this justifies the performance hit.

> @kevinrushforth @prrace could you please review?

As we discussed yesterday, it is reviewed but not ready to be approved.
We are waiting for a reply from Apple.

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

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

From serb at openjdk.java.net  Tue Nov 17 18:59:04 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 17 Nov 2020 18:59:04 GMT
Subject: <AWT Dev> RFR: 8251854: [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com>
References: <Nf052gV_cPeWE9lYgIOeus5BZZXi_Pc-BFICzqLVO4A=.8fb05764-e448-4c82-91a6-cecbb2ed6b2e@github.com>
 <epFJBT7ojxv5e7lJwX92LkMtHvFnWDTsiXg6SIcxFf8=.0b6d23db-89de-4521-89ef-5c0002968d90@github.com>
 <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com>
Message-ID: <YhYXy8tdT7E_dCSss6az0WIpnfL1dxw2eVsCTWUwDJI=.33246b1e-7e53-455f-87ea-cf94081759e2@github.com>

On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Change looks ok from a build point of view, but I can't comment on the validity and implications of using this key.
>
> I ran a 3D lighting test that is designed to be a GPU stress test. It's a worst case, to be sure, but it take 10 times as long to render with the integrated GPU as it does with the discrete GPU:
> 
> **attenuation.LightingSample: 500 large quads**
> discrete GPU: 23.5 fps
> integrated GPU: 2.34 fps
> 
> In a more realistic example of drawing a large number of 2D vectors, it runs 35% slower with the integrated GPU:
> 
> **Vector charting test, oval clip**
> discrete GPU: 41.1 fps
> integrated GPU: 26.6 fps
> 
> I see similar results in the performance numbers you listed above.
> 
> An application developer who packages up their JDK, for example, using jpackage, can make the decision for themselves. Application developers who rely on the JDK as delivered will get whatever we choose as the default. So we need to be sure that the benefit of doing this justifies the performance hit.

> > @kevinrushforth @prrace could you please review?
> 
> As we discussed yesterday, it is reviewed but not ready to be approved.
> We are waiting for a reply from Apple.

@prrace 
We are waiting for it for three months already. If it is possible then not sure why other applications did not found any possible ways to force one specific GPU. What we are wating for?

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

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

From kizune at openjdk.java.net  Wed Nov 18 13:32:09 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 18 Nov 2020 13:32:09 GMT
Subject: <AWT Dev> RFR: 8256108: Create implementation for
 NSAccessibilityElement protocol peer
Message-ID: <_9UfIb_lzveonWoV4ivf_a-484IgJDs5KzYaAYNWbi4=.b8d285a1-5d94-4732-a80f-73655cc78a50@github.com>

8256108: Create implementation for NSAccessibilityElement protocol peer

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

Commit messages:
 - 8256108: Create implementation for NSAccessibilityElement protocol peer
 - Merge pull request #3 from openjdk/master
 - Merge pull request #2 from openjdk/master
 - Merge pull request #1 from openjdk/master

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

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

From kizune at openjdk.java.net  Wed Nov 18 18:00:08 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 18 Nov 2020 18:00:08 GMT
Subject: <AWT Dev> RFR: 8256373: [Windows/HiDPI] The Frame#setBounds
 does not work in a minimized state
In-Reply-To: <rnMuc8fXGxVXCbogchpWBX_95FZkt1NrSC52QfdfhwU=.4473141b-66d1-4f0a-aa3a-6d4b9e4f575c@github.com>
References: <rnMuc8fXGxVXCbogchpWBX_95FZkt1NrSC52QfdfhwU=.4473141b-66d1-4f0a-aa3a-6d4b9e4f575c@github.com>
Message-ID: <HhvXU9p6AI9S3wfbMqG1TnpLsGtzPSWXvqgkUs5EwlY=.3b733147-1a61-40d1-a215-1ccda77bc48f@github.com>

On Mon, 16 Nov 2020 03:02:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> On HIDPI Windows, the Frame#setBounds does not work in a minimized state. The bug found during the development of JDK-8211999. When the frame is iconized and we try to save new bounds for future use, we store the coordinates in the user's space to the field which use device space:
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664

Quick question: is there any way to manually reproduce this problem or it is only possible programmatically? How can you move iconified window to another display without de-iconifying it?

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

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

From serb at openjdk.java.net  Wed Nov 18 18:16:04 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 18 Nov 2020 18:16:04 GMT
Subject: <AWT Dev> RFR: 8256373: [Windows/HiDPI] The Frame#setBounds
 does not work in a minimized state
In-Reply-To: <HhvXU9p6AI9S3wfbMqG1TnpLsGtzPSWXvqgkUs5EwlY=.3b733147-1a61-40d1-a215-1ccda77bc48f@github.com>
References: <rnMuc8fXGxVXCbogchpWBX_95FZkt1NrSC52QfdfhwU=.4473141b-66d1-4f0a-aa3a-6d4b9e4f575c@github.com>
 <HhvXU9p6AI9S3wfbMqG1TnpLsGtzPSWXvqgkUs5EwlY=.3b733147-1a61-40d1-a215-1ccda77bc48f@github.com>
Message-ID: <j-UBUx8hbgmB7nLdvluh2lOCM9nyhpx6HFnUXBlSX_w=.aae27117-68e8-4eae-b607-39bf188606c0@github.com>

On Wed, 18 Nov 2020 17:57:18 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Quick question: is there any way to manually reproduce this problem or it is only possible programmatically? How can you move iconified window to another display without de-iconifying it?

To reproduce the bug it is necessary to call setBounds method while the window is iconified - actually replacing its normal state bounds. So when the frame will de-iconifying(become normal) it appeared on the new bounds.

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

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

From kizune at openjdk.java.net  Wed Nov 18 19:03:17 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 18 Nov 2020 19:03:17 GMT
Subject: <AWT Dev> RFR: 8256108: Create implementation for
 NSAccessibilityElement protocol peer [v2]
In-Reply-To: <_9UfIb_lzveonWoV4ivf_a-484IgJDs5KzYaAYNWbi4=.b8d285a1-5d94-4732-a80f-73655cc78a50@github.com>
References: <_9UfIb_lzveonWoV4ivf_a-484IgJDs5KzYaAYNWbi4=.b8d285a1-5d94-4732-a80f-73655cc78a50@github.com>
Message-ID: <KCEuRFFZuyWEs0Sw4fHiABWkAXCDR8UQNd5AwESlaZU=.4aaf3401-e280-4dce-9a40-a1cd22b709a6@github.com>

> 8256108: Create implementation for NSAccessibilityElement protocol peer

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

  Fixed the year in file header.
  
  Added comments on a reason for the common component layer existance.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1290/files
  - new: https://git.openjdk.java.net/jdk/pull/1290/files/f3ff43fa..cbdc9081

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

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

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

From philip.race at oracle.com  Thu Nov 19 00:00:11 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 18 Nov 2020 16:00:11 -0800
Subject: <AWT Dev> EA7 build of Project Lanai (Java 2D Metal rendering
 pipeline for macOS) is now posted
Message-ID: <5FB5B58B.4060000@oracle.com>

The EA 7 build of Project Lanai [1] was posted today at 
https://jdk.java.net/lanai/


    EA 7 Build 16-lanai+3-278 (2020/11/17)

Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues.

EA 7 contains the following new bug fixes relative to EA 6

# 8256331: Lanai: DrawImage/IncorrectAlphaSurface2SW fails 
<https://bugs.openjdk.java.net/browse/JDK-8256331>
# 8252954: Lanai : 
java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java fails 
<https://bugs.openjdk.java.net/browse/JDK-8252954>
# 8252951: Lanai : java/awt/Robot/NonEmptyErrorStream.java fails 
<https://bugs.openjdk.java.net/browse/JDK-8252951>
# 8251033: Background texture is not visible when Alpha Composite is 
enabled <https://bugs.openjdk.java.net/browse/JDK-8251033>
# 8238533: [Lanai] Support texture paint where source is transparent 
<https://bugs.openjdk.java.net/browse/JDK-8238533>
# 8248129: Swingmark numbers are not good for Nimbus LAF 
<https://bugs.openjdk.java.net/browse/JDK-8248129>
# 8255212: J2DDemo : Rectangle in Texture paint disappears if we enable AA 
<https://bugs.openjdk.java.net/browse/JDK-8255212>
# 8255149: Lanai: DrawImage/IncorrectAlphaConversionBicubic.java failure 
<https://bugs.openjdk.java.net/browse/JDK-8255149>
# 8244718: J2DDemo - AlphaComposite tab - output colors are different with 
AA & non-AA <https://bugs.openjdk.java.net/browse/JDK-8244718>
# 8254881: Commit commandbuffer after draw happens through JNI 
<https://bugs.openjdk.java.net/browse/JDK-8254881>
# 8254879: Implement JNI path for Draw Poly 
<https://bugs.openjdk.java.net/browse/JDK-8254879>
# 8254869: Refactor check_previous_op usage in Mask Fill 
<https://bugs.openjdk.java.net/browse/JDK-8254869>
# 8244845: Lanai : J2DDemo - Clipping - Two parallel lines do not appear 
with AA Rendering <https://bugs.openjdk.java.net/browse/JDK-8244845>
# 8242924: Selection is not correct in Paint.TextureAnim 
<https://bugs.openjdk.java.net/browse/JDK-8242924>
# 8253994: J2DDemo: Buttcap, SquareCap color is different in 
AlphaComposite mode <https://bugs.openjdk.java.net/browse/JDK-8253994>
# 8252726: Lanai: IDEA Editor Rendering OGL vs Metal 1:2 
<https://bugs.openjdk.java.net/browse/JDK-8252726>
# 8254176: Lanai: MTLTexturePool optimize lookup of expired textures 
<https://bugs.openjdk.java.net/browse/JDK-8254176>

-phil.

[1] https://wiki.openjdk.java.net/display/lanai/Main
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20201118/11de1f55/attachment-0001.htm>

From serb at openjdk.java.net  Thu Nov 19 00:26:09 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 19 Nov 2020 00:26:09 GMT
Subject: <AWT Dev> RFR: 8256108: Create implementation for
 NSAccessibilityElement protocol peer [v2]
In-Reply-To: <KCEuRFFZuyWEs0Sw4fHiABWkAXCDR8UQNd5AwESlaZU=.4aaf3401-e280-4dce-9a40-a1cd22b709a6@github.com>
References: <_9UfIb_lzveonWoV4ivf_a-484IgJDs5KzYaAYNWbi4=.b8d285a1-5d94-4732-a80f-73655cc78a50@github.com>
 <KCEuRFFZuyWEs0Sw4fHiABWkAXCDR8UQNd5AwESlaZU=.4aaf3401-e280-4dce-9a40-a1cd22b709a6@github.com>
Message-ID: <y3pmVOF3UytI6IVhnb-A8c4mFQFiKL1T6QuFhEI6GDA=.aff2506e-3168-4fac-afc5-4c48997c9ae3@github.com>

On Wed, 18 Nov 2020 19:03:17 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8256108: Create implementation for NSAccessibilityElement protocol peer
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the year in file header.
>   
>   Added comments on a reason for the common component layer existance.

src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m line 140:

> 138: // Please see https://developer.apple.com/documentation/appkit/nsaccessibilityprotocol
> 139: // for more details.
> 140: @interface CommonComponentAccessibility : JavaComponentAccessibility <NSAccessibilityElement> {

I remember we had a plan to implement this step by step, replacing the parts of the old API with some new parts.

If the plan still in place then why we do not implement `NSAccessibilityElement` in the `JavaComponentAccessibility ` class, so the usage of current (old) methods like `accessibilityPositionAttribute/accessibilitySizeAttribute/accessibilityFocusedAttribute` could be replaced by the new methods from the NSAccessibilityElement protocol like accessibilityParent/accessibilityFrame/isAccessibilityFocused.

If we plan to implement it from scratch then why the CommonComponentAccessibility extends JavaComponentAccessibility?

It is not obvious from the change since the `accessibilityFrame()` is implemented from scratch mostly duplicate `accessibilityPositionAttribute+accessibilitySizeAttribute`, but the `accessibilityParent()` uses the code from the `JavaComponentAccessibility `

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

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

From kizune at openjdk.java.net  Thu Nov 19 04:24:03 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 19 Nov 2020 04:24:03 GMT
Subject: <AWT Dev> RFR: 8256108: Create implementation for
 NSAccessibilityElement protocol peer [v2]
In-Reply-To: <y3pmVOF3UytI6IVhnb-A8c4mFQFiKL1T6QuFhEI6GDA=.aff2506e-3168-4fac-afc5-4c48997c9ae3@github.com>
References: <_9UfIb_lzveonWoV4ivf_a-484IgJDs5KzYaAYNWbi4=.b8d285a1-5d94-4732-a80f-73655cc78a50@github.com>
 <KCEuRFFZuyWEs0Sw4fHiABWkAXCDR8UQNd5AwESlaZU=.4aaf3401-e280-4dce-9a40-a1cd22b709a6@github.com>
 <y3pmVOF3UytI6IVhnb-A8c4mFQFiKL1T6QuFhEI6GDA=.aff2506e-3168-4fac-afc5-4c48997c9ae3@github.com>
Message-ID: <RCl97D3M6zz6BPRK6mek_snoGGL63T2ojZZHZnOY7Sg=.a117c734-647f-465c-8158-7a6e0a1a1156@github.com>

On Thu, 19 Nov 2020 00:23:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed the year in file header.
>>   
>>   Added comments on a reason for the common component layer existance.
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m line 140:
> 
>> 138: // Please see https://developer.apple.com/documentation/appkit/nsaccessibilityprotocol
>> 139: // for more details.
>> 140: @interface CommonComponentAccessibility : JavaComponentAccessibility <NSAccessibilityElement> {
> 
> I remember we had a plan to implement this step by step, replacing the parts of the old API with some new parts.
> 
> If the plan still in place then why we do not implement `NSAccessibilityElement` in the `JavaComponentAccessibility ` class, so the usage of current (old) methods like `accessibilityPositionAttribute/accessibilitySizeAttribute/accessibilityFocusedAttribute` could be replaced by the new methods from the NSAccessibilityElement protocol like accessibilityParent/accessibilityFrame/isAccessibilityFocused.
> 
> If we plan to implement it from scratch then why the CommonComponentAccessibility extends JavaComponentAccessibility?
> 
> It is not obvious from the change since the `accessibilityFrame()` is implemented from scratch mostly duplicate `accessibilityPositionAttribute+accessibilitySizeAttribute`, but the `accessibilityParent()` uses the code from the `JavaComponentAccessibility `

Implementing it step by step is exactly why i did it - if i make JavaComponentAccessibility implementing the NSAccessibilityElement it triggers mac os to stop using the old property based API on all of it and we are not ready for that. I'm planning to keep CommonComponentAccessibility implementation minimal so once all of our bases are covered we can just swap JavaComponentAccessibility to implementing NSAccessibilityElement and switching all the subcomponent's peers to extend it and then we will be able to drop CommonComponentAccessibility altogether (or just leave it so we can swap to older API easier for comparison testing).

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

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

From serb at openjdk.java.net  Thu Nov 19 05:57:04 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 19 Nov 2020 05:57:04 GMT
Subject: <AWT Dev> RFR: 8256108: Create implementation for
 NSAccessibilityElement protocol peer [v2]
In-Reply-To: <RCl97D3M6zz6BPRK6mek_snoGGL63T2ojZZHZnOY7Sg=.a117c734-647f-465c-8158-7a6e0a1a1156@github.com>
References: <_9UfIb_lzveonWoV4ivf_a-484IgJDs5KzYaAYNWbi4=.b8d285a1-5d94-4732-a80f-73655cc78a50@github.com>
 <KCEuRFFZuyWEs0Sw4fHiABWkAXCDR8UQNd5AwESlaZU=.4aaf3401-e280-4dce-9a40-a1cd22b709a6@github.com>
 <y3pmVOF3UytI6IVhnb-A8c4mFQFiKL1T6QuFhEI6GDA=.aff2506e-3168-4fac-afc5-4c48997c9ae3@github.com>
 <RCl97D3M6zz6BPRK6mek_snoGGL63T2ojZZHZnOY7Sg=.a117c734-647f-465c-8158-7a6e0a1a1156@github.com>
Message-ID: <CDT306Vtbm134QEwUFYynjDDOesTdPFPt-dHgG4GGo4=.e94caa85-8232-4243-8f1e-8c586135c7ba@github.com>

On Thu, 19 Nov 2020 04:20:58 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m line 140:
>> 
>>> 138: // Please see https://developer.apple.com/documentation/appkit/nsaccessibilityprotocol
>>> 139: // for more details.
>>> 140: @interface CommonComponentAccessibility : JavaComponentAccessibility <NSAccessibilityElement> {
>> 
>> I remember we had a plan to implement this step by step, replacing the parts of the old API with some new parts.
>> 
>> If the plan still in place then why we do not implement `NSAccessibilityElement` in the `JavaComponentAccessibility ` class, so the usage of current (old) methods like `accessibilityPositionAttribute/accessibilitySizeAttribute/accessibilityFocusedAttribute` could be replaced by the new methods from the NSAccessibilityElement protocol like accessibilityParent/accessibilityFrame/isAccessibilityFocused.
>> 
>> If we plan to implement it from scratch then why the CommonComponentAccessibility extends JavaComponentAccessibility?
>> 
>> It is not obvious from the change since the `accessibilityFrame()` is implemented from scratch mostly duplicate `accessibilityPositionAttribute+accessibilitySizeAttribute`, but the `accessibilityParent()` uses the code from the `JavaComponentAccessibility `
>
> Implementing it step by step is exactly why i did it - if i make JavaComponentAccessibility implementing the NSAccessibilityElement it triggers mac os to stop using the old property based API on all of it and we are not ready for that. I'm planning to keep CommonComponentAccessibility implementation minimal so once all of our bases are covered we can just swap JavaComponentAccessibility to implementing NSAccessibilityElement and switching all the subcomponent's peers to extend it and then we will be able to drop CommonComponentAccessibility altogether (or just leave it so we can swap to older API easier for comparison testing).

Then it does not look like as step by step implementation, it just adding the code which does not necessarily work properly. Are you sure that the implementation of NSAccessibilityElement will block the old for all roles not only for the elemental role? It will be useful if we start to use the new accessibilityFrame/etc API instead of accessibilityPositionAttribute/etc attributes, but still, use the old attributes for other roles.

If the plan is to make the CommonComponentAccessibility as small as possible then the CommonComponentAccessibility.accessibilityFrame could be implemented on top of accessibilityPositionAttribute+accessibilitySizeAttribute or another way around, similar to accessibilityParent which is implemented via accessibilityParentAttribute. But in this case, the whole class will have 5 rows which are never executed? Probably it is possible to mix old/new?

> 
Note

> The new, method-based accessibility API is backward compatible with the previous, key-based API. This means, if you have controls that are already accessible, you can continue to use them. You can even convert a control to the method-based API in stages, implementing the new method-based API for some features, leaving others in the key-based API.

> If there?s a conflict between the method- and key-based APIs, the method-based API takes precedence. This is particularly important for frameworks that provides accessible controls. If you convert those controls to the method-based API, the system ignores any legacy code that modifies their attributes. For this reason, if you create third-party libraries, you may want to wait to upgrade your library until you?re sure that all your clients have updated their apps.
https://developer.apple.com/library/archive/documentation/Accessibility/Conceptual/AccessibilityMacOSX/

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

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

From kizune at openjdk.java.net  Thu Nov 19 07:12:00 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 19 Nov 2020 07:12:00 GMT
Subject: <AWT Dev> RFR: 8256108: Create implementation for
 NSAccessibilityElement protocol peer [v2]
In-Reply-To: <CDT306Vtbm134QEwUFYynjDDOesTdPFPt-dHgG4GGo4=.e94caa85-8232-4243-8f1e-8c586135c7ba@github.com>
References: <_9UfIb_lzveonWoV4ivf_a-484IgJDs5KzYaAYNWbi4=.b8d285a1-5d94-4732-a80f-73655cc78a50@github.com>
 <KCEuRFFZuyWEs0Sw4fHiABWkAXCDR8UQNd5AwESlaZU=.4aaf3401-e280-4dce-9a40-a1cd22b709a6@github.com>
 <y3pmVOF3UytI6IVhnb-A8c4mFQFiKL1T6QuFhEI6GDA=.aff2506e-3168-4fac-afc5-4c48997c9ae3@github.com>
 <RCl97D3M6zz6BPRK6mek_snoGGL63T2ojZZHZnOY7Sg=.a117c734-647f-465c-8158-7a6e0a1a1156@github.com>
 <CDT306Vtbm134QEwUFYynjDDOesTdPFPt-dHgG4GGo4=.e94caa85-8232-4243-8f1e-8c586135c7ba@github.com>
Message-ID: <ujbImqGbdixeLLhPI9aG5aRW9ruThEPgPIlQyUiFZc4=.8d9f01f5-0e4c-4a3b-850c-4c4af61b734d@github.com>

On Thu, 19 Nov 2020 05:54:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Implementing it step by step is exactly why i did it - if i make JavaComponentAccessibility implementing the NSAccessibilityElement it triggers mac os to stop using the old property based API on all of it and we are not ready for that. I'm planning to keep CommonComponentAccessibility implementation minimal so once all of our bases are covered we can just swap JavaComponentAccessibility to implementing NSAccessibilityElement and switching all the subcomponent's peers to extend it and then we will be able to drop CommonComponentAccessibility altogether (or just leave it so we can swap to older API easier for comparison testing).
>
> Then it does not look like as step by step implementation, it just adding the code which does not necessarily work properly. Are you sure that the implementation of NSAccessibilityElement will block the old for all roles not only for the elemental role? It will be useful if we start to use the new accessibilityFrame/etc API instead of accessibilityPositionAttribute/etc attributes, but still, use the old attributes for other roles.
> 
> If the plan is to make the CommonComponentAccessibility as small as possible then the CommonComponentAccessibility.accessibilityFrame could be implemented on top of accessibilityPositionAttribute+accessibilitySizeAttribute or another way around, similar to accessibilityParent which is implemented via accessibilityParentAttribute. But in this case, the whole class will have 5 rows which are never executed? Probably it is possible to mix old/new?
> 
>> 
> Note
> 
>> The new, method-based accessibility API is backward compatible with the previous, key-based API. This means, if you have controls that are already accessible, you can continue to use them. You can even convert a control to the method-based API in stages, implementing the new method-based API for some features, leaving others in the key-based API.
> 
>> If there?s a conflict between the method- and key-based APIs, the method-based API takes precedence. This is particularly important for frameworks that provides accessible controls. If you convert those controls to the method-based API, the system ignores any legacy code that modifies their attributes. For this reason, if you create third-party libraries, you may want to wait to upgrade your library until you?re sure that all your clients have updated their apps.
> https://developer.apple.com/library/archive/documentation/Accessibility/Conceptual/AccessibilityMacOSX/

It is step by step implementation since the component peers will inherit these functions and they will be called once we initialize these peers. It will be clear once you see simple peer like pushbutton peer implementation. And yes - i tested - once system detects that peer implement new protocol it stops calling the property retrieving methods giving out "unrecognized selector sent to instance" errors for not implemented functions.

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

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

From serb at openjdk.java.net  Thu Nov 19 09:13:05 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 19 Nov 2020 09:13:05 GMT
Subject: <AWT Dev> RFR: 8256108: Create implementation for
 NSAccessibilityElement protocol peer [v2]
In-Reply-To: <ujbImqGbdixeLLhPI9aG5aRW9ruThEPgPIlQyUiFZc4=.8d9f01f5-0e4c-4a3b-850c-4c4af61b734d@github.com>
References: <_9UfIb_lzveonWoV4ivf_a-484IgJDs5KzYaAYNWbi4=.b8d285a1-5d94-4732-a80f-73655cc78a50@github.com>
 <KCEuRFFZuyWEs0Sw4fHiABWkAXCDR8UQNd5AwESlaZU=.4aaf3401-e280-4dce-9a40-a1cd22b709a6@github.com>
 <y3pmVOF3UytI6IVhnb-A8c4mFQFiKL1T6QuFhEI6GDA=.aff2506e-3168-4fac-afc5-4c48997c9ae3@github.com>
 <RCl97D3M6zz6BPRK6mek_snoGGL63T2ojZZHZnOY7Sg=.a117c734-647f-465c-8158-7a6e0a1a1156@github.com>
 <CDT306Vtbm134QEwUFYynjDDOesTdPFPt-dHgG4GGo4=.e94caa85-8232-4243-8f1e-8c586135c7ba@github.com>
 <ujbImqGbdixeLLhPI9aG5aRW9ruThEPgPIlQyUiFZc4=.8d9f01f5-0e4c-4a3b-850c-4c4af61b734d@github.com>
Message-ID: <pD05Dk2AxHa3uXFopvNszrzNkZ1axNLz8aGinI0ljE0=.121704d3-6d06-4918-88df-f0ac1e929628@github.com>

On Thu, 19 Nov 2020 07:09:33 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Then it does not look like as step by step implementation, it just adding the code which does not necessarily work properly. Are you sure that the implementation of NSAccessibilityElement will block the old for all roles not only for the elemental role? It will be useful if we start to use the new accessibilityFrame/etc API instead of accessibilityPositionAttribute/etc attributes, but still, use the old attributes for other roles.
>> 
>> If the plan is to make the CommonComponentAccessibility as small as possible then the CommonComponentAccessibility.accessibilityFrame could be implemented on top of accessibilityPositionAttribute+accessibilitySizeAttribute or another way around, similar to accessibilityParent which is implemented via accessibilityParentAttribute. But in this case, the whole class will have 5 rows which are never executed? Probably it is possible to mix old/new?
>> 
>>> 
>> Note
>> 
>>> The new, method-based accessibility API is backward compatible with the previous, key-based API. This means, if you have controls that are already accessible, you can continue to use them. You can even convert a control to the method-based API in stages, implementing the new method-based API for some features, leaving others in the key-based API.
>> 
>>> If there?s a conflict between the method- and key-based APIs, the method-based API takes precedence. This is particularly important for frameworks that provides accessible controls. If you convert those controls to the method-based API, the system ignores any legacy code that modifies their attributes. For this reason, if you create third-party libraries, you may want to wait to upgrade your library until you?re sure that all your clients have updated their apps.
>> https://developer.apple.com/library/archive/documentation/Accessibility/Conceptual/AccessibilityMacOSX/
>
> It is step by step implementation since the component peers will inherit these functions and they will be called once we initialize these peers. It will be clear once you see simple peer like pushbutton peer implementation. And yes - i tested - once system detects that peer implement new protocol it stops calling the property retrieving methods giving out "unrecognized selector sent to instance" errors for not implemented functions.

So do you plan to return different a11y components depends on the type of the role? So for the old API, you will return JavaComponentAccessibility and for the new, you will return ButtonAccessibility which will extend CommonComponentAccessibility and implement NSAccessibilityButton, etc? WIll it work?

BTW don't you need to implement isAccessibilityFocused to cover old accessibilityFocusedAttribute?

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

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

From kizune at openjdk.java.net  Thu Nov 19 09:24:07 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 19 Nov 2020 09:24:07 GMT
Subject: <AWT Dev> RFR: 8256108: Create implementation for
 NSAccessibilityElement protocol peer [v2]
In-Reply-To: <pD05Dk2AxHa3uXFopvNszrzNkZ1axNLz8aGinI0ljE0=.121704d3-6d06-4918-88df-f0ac1e929628@github.com>
References: <_9UfIb_lzveonWoV4ivf_a-484IgJDs5KzYaAYNWbi4=.b8d285a1-5d94-4732-a80f-73655cc78a50@github.com>
 <KCEuRFFZuyWEs0Sw4fHiABWkAXCDR8UQNd5AwESlaZU=.4aaf3401-e280-4dce-9a40-a1cd22b709a6@github.com>
 <y3pmVOF3UytI6IVhnb-A8c4mFQFiKL1T6QuFhEI6GDA=.aff2506e-3168-4fac-afc5-4c48997c9ae3@github.com>
 <RCl97D3M6zz6BPRK6mek_snoGGL63T2ojZZHZnOY7Sg=.a117c734-647f-465c-8158-7a6e0a1a1156@github.com>
 <CDT306Vtbm134QEwUFYynjDDOesTdPFPt-dHgG4GGo4=.e94caa85-8232-4243-8f1e-8c586135c7ba@github.com>
 <ujbImqGbdixeLLhPI9aG5aRW9ruThEPgPIlQyUiFZc4=.8d9f01f5-0e4c-4a3b-850c-4c4af61b734d@github.com>
 <pD05Dk2AxHa3uXFopvNszrzNkZ1axNLz8aGinI0ljE0=.121704d3-6d06-4918-88df-f0ac1e929628@github.com>
Message-ID: <MDBoOLpPO_X9zIeTuWYGt2fp35qft2mYPuWRbtZaHHE=.a04efe1c-e22e-4158-bfbe-655464aff9a1@github.com>

On Thu, 19 Nov 2020 09:10:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> So do you plan to return different a11y components depends on the type of the role? So for the old API, you will return JavaComponentAccessibility and for the new, you will return ButtonAccessibility which will extend CommonComponentAccessibility and implement NSAccessibilityButton, etc? WIll it work?

Yes. That's the way. I mean - that's the plan. I already tested it on couple of components and it works just fine.

> BTW don't you need to implement isAccessibilityFocused to cover old accessibilityFocusedAttribute?

Not right now. I'm trying to do the minimal implementation and so far in my testing i haven't found that anyone calls that selector under any circumstances. OTOH the current implementation is in no way a complete one and selectors will be added during the component peers implementation phase. I'm trying to reuse as much code from the original class as possible but for streamlining purposes if there's no corresponding function i can use i am writing this function as a new one, because i do not want to modify the behavior of the existing functions. This should streamline the last merge in this feature which should be a general cleanup of the existing code and removal of unused functions and refactoring of the used ones to the new API.

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

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

From serb at openjdk.java.net  Thu Nov 19 18:46:06 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 19 Nov 2020 18:46:06 GMT
Subject: <AWT Dev> RFR: 8256108: Create implementation for
 NSAccessibilityElement protocol peer [v2]
In-Reply-To: <KCEuRFFZuyWEs0Sw4fHiABWkAXCDR8UQNd5AwESlaZU=.4aaf3401-e280-4dce-9a40-a1cd22b709a6@github.com>
References: <_9UfIb_lzveonWoV4ivf_a-484IgJDs5KzYaAYNWbi4=.b8d285a1-5d94-4732-a80f-73655cc78a50@github.com>
 <KCEuRFFZuyWEs0Sw4fHiABWkAXCDR8UQNd5AwESlaZU=.4aaf3401-e280-4dce-9a40-a1cd22b709a6@github.com>
Message-ID: <ZLRbLAYlhbkdcyJ3fc-eYWn7VRrJDs9tcyJ-BJ7YXB8=.6aa43d41-eaee-4bc4-aeb6-46b430d259d1@github.com>

On Wed, 18 Nov 2020 19:03:17 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8256108: Create implementation for NSAccessibilityElement protocol peer
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the year in file header.
>   
>   Added comments on a reason for the common component layer existance.

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Thu Nov 19 18:46:07 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 19 Nov 2020 18:46:07 GMT
Subject: <AWT Dev> RFR: 8256108: Create implementation for
 NSAccessibilityElement protocol peer [v2]
In-Reply-To: <MDBoOLpPO_X9zIeTuWYGt2fp35qft2mYPuWRbtZaHHE=.a04efe1c-e22e-4158-bfbe-655464aff9a1@github.com>
References: <_9UfIb_lzveonWoV4ivf_a-484IgJDs5KzYaAYNWbi4=.b8d285a1-5d94-4732-a80f-73655cc78a50@github.com>
 <KCEuRFFZuyWEs0Sw4fHiABWkAXCDR8UQNd5AwESlaZU=.4aaf3401-e280-4dce-9a40-a1cd22b709a6@github.com>
 <y3pmVOF3UytI6IVhnb-A8c4mFQFiKL1T6QuFhEI6GDA=.aff2506e-3168-4fac-afc5-4c48997c9ae3@github.com>
 <RCl97D3M6zz6BPRK6mek_snoGGL63T2ojZZHZnOY7Sg=.a117c734-647f-465c-8158-7a6e0a1a1156@github.com>
 <CDT306Vtbm134QEwUFYynjDDOesTdPFPt-dHgG4GGo4=.e94caa85-8232-4243-8f1e-8c586135c7ba@github.com>
 <ujbImqGbdixeLLhPI9aG5aRW9ruThEPgPIlQyUiFZc4=.8d9f01f5-0e4c-4a3b-850c-4c4af61b734d@github.com>
 <pD05Dk2AxHa3uXFopvNszrzNkZ1axNLz8aGinI0ljE0=.121704d3-6d06-4918-88df-f0ac1e929628@github.com>
 <MDBoOLpPO_X9zIeTuWYGt2fp35qft2mYPuWRbtZaHHE=.a04efe1c-e22e-4158-bfbe-655464aff9a1@github.com>
Message-ID: <pzEYSI7ZHkMTUz_hwZ371gewtxJAvyJ5HoTnBc3TbKI=.f1865b49-0578-452b-ad71-e9adc4a2a4c2@github.com>

On Thu, 19 Nov 2020 09:20:51 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> So do you plan to return different a11y components depends on the type of the role? So for the old API, you will return JavaComponentAccessibility and for the new, you will return ButtonAccessibility which will extend CommonComponentAccessibility and implement NSAccessibilityButton, etc? WIll it work?
>> 
>> BTW don't you need to implement isAccessibilityFocused to cover old accessibilityFocusedAttribute?
>
>> So do you plan to return different a11y components depends on the type of the role? So for the old API, you will return JavaComponentAccessibility and for the new, you will return ButtonAccessibility which will extend CommonComponentAccessibility and implement NSAccessibilityButton, etc? WIll it work?
> 
> Yes. That's the way. I mean - that's the plan. I already tested it on couple of components and it works just fine.
> 
>> BTW don't you need to implement isAccessibilityFocused to cover old accessibilityFocusedAttribute?
> 
> Not right now. I'm trying to do the minimal implementation and so far in my testing i haven't found that anyone calls that selector under any circumstances. OTOH the current implementation is in no way a complete one and selectors will be added during the component peers implementation phase. I'm trying to reuse as much code from the original class as possible but for streamlining purposes if there's no corresponding function i can use i am writing this function as a new one, because i do not want to modify the behavior of the existing functions. This should streamline the last merge in this feature which should be a general cleanup of the existing code and removal of unused functions and refactoring of the used ones to the new API.

Ok, let's see how it will work.

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

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

From serb at openjdk.java.net  Fri Nov 20 00:47:03 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 20 Nov 2020 00:47:03 GMT
Subject: <AWT Dev> RFR: 8255387: Japanese characters were printed upside
 down on AIX
In-Reply-To: <-zl1EqjwYppCrp7Wdifz42Jagial2KqVXkEbAxMciUc=.5b75c16d-f0e8-427f-b3b4-62aca0076732@github.com>
References: <-zl1EqjwYppCrp7Wdifz42Jagial2KqVXkEbAxMciUc=.5b75c16d-f0e8-427f-b3b4-62aca0076732@github.com>
Message-ID: <SwyyrlhQNWjnwp-PRlHkw1A9eC5y5bUVpeZ7hZszS4w=.71590b93-6a9a-4a1c-bf61-82550e30d8c2@github.com>

On Mon, 16 Nov 2020 09:09:50 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> Hi,
> 
> Could you review this fix? Under some special conditions, non-English characters were printed upside down.
> 
> At printing with raster image, the image was generated from bottom to top. So, each characters should also be drawn as vertical mirrored. However, freetype doesn't support to transform it if the font is using embedded bitmap and non-English. As the result, these Japanese characters were printed as upside down.
> 
> In this case, freetype should be prevented to use embedded bitmap.

test/jdk/java/awt/print/PrinterJob/PrintTranslateTest.java line 40:

> 38: import java.awt.image.BufferedImage;
> 39: 
> 40: public class PrintTranslateTest{

Does it really bind to the printing/"print/PrinterJob", look like the bug is reproduced in the common rendering as well?

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

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

From kizune at openjdk.java.net  Fri Nov 20 04:13:03 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 20 Nov 2020 04:13:03 GMT
Subject: <AWT Dev> Integrated: 8256108: Create implementation for
 NSAccessibilityElement protocol peer
In-Reply-To: <_9UfIb_lzveonWoV4ivf_a-484IgJDs5KzYaAYNWbi4=.b8d285a1-5d94-4732-a80f-73655cc78a50@github.com>
References: <_9UfIb_lzveonWoV4ivf_a-484IgJDs5KzYaAYNWbi4=.b8d285a1-5d94-4732-a80f-73655cc78a50@github.com>
Message-ID: <HEeDFDs1dWmAA0cPITiRZvVnTST7fbsSQwWUXFfJfu4=.650120a6-f2f3-450c-9997-16fbee0e4a72@github.com>

On Wed, 18 Nov 2020 13:27:00 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8256108: Create implementation for NSAccessibilityElement protocol peer

This pull request has now been integrated.

Changeset: 4c095252
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4c095252
Stats:     44 lines in 1 file changed: 43 ins; 0 del; 1 mod

8256108: Create implementation for NSAccessibilityElement protocol peer

Reviewed-by: serb

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

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

From serb at openjdk.java.net  Fri Nov 20 06:34:03 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 20 Nov 2020 06:34:03 GMT
Subject: <AWT Dev> RFR: 8256264: Printed GlyphVector outline with low
 DPI has bad quality on Windows
In-Reply-To: <iA4R8RQHqStufCJRG2qB5tJODvX-mIlqv392YbdNE84=.5bfe5fa6-6062-45ec-aebd-d193cf8b76c6@github.com>
References: <iA4R8RQHqStufCJRG2qB5tJODvX-mIlqv392YbdNE84=.5bfe5fa6-6062-45ec-aebd-d193cf8b76c6@github.com>
Message-ID: <a4IkTW6qwFnlbnrq-SMzkaDuAOLCrescYF4ts0mV9-Q=.fd7c6323-6561-4897-932d-4d8e6392ff8e@github.com>

On Thu, 12 Nov 2020 10:32:16 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows.
> The GDI system used for text printing on Windows accepts only integer path coordinates.
> Rounding GlyphVector outline coordinates leads to distorted printed text.
> 
> To reproduce the issue run the [PrintGlyphVectorOutlineSample](https://bugs.openjdk.java.net/secure/attachment/91398/PrintGlyphVectorOutlineSample.java)  file on Windows and select a low DPI
> printer in the printer dialog. The sample prints two lines, one using Graphics drawString() method and another by
> filling GlyphVector outline. Chars on the second line are distorted.
> 
> It is also possible to reproduce the issue running the sample and printing the text to PDF: [fill-glyph-vector-outline.png](https://bugs.openjdk.java.net/secure/attachment/91397/fill-glyph-vector-outline.png)
> 
> The proposed fix introduce "sun.java2d.print.enablePathPrecisionScale" property which being enabled
> scales the GDI WorldTransform down and GlyphVector outline coordinates up.
> This allows to keep some digits after a dot from being rounded.
> The value for scaling is chosen to be 1000 in the same way how it is used  by `String trunc(float f)` method from PSPrinterJob class on Linux:
> https://github.com/openjdk/jdk/blob/ed615e3ca0d681e8e67cdbf1d5d964979ccd7888/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#L1489
> 
> See the  [fill-glyph-vector-outline-enable-path-scale-factor.png](https://bugs.openjdk.java.net/secure/attachment/91399/fill-glyph-vector-outline-enable-path-scale-factor.png) screenshot which shows how the GlyphVector outline is filled after the fix with the enabled "sun.java2d.print.enablePathPrecisionScale" option.
> 
> [fill-glyph-vector-outline-diff.png](https://bugs.openjdk.java.net/secure/attachment/91400/fill-glyph-vector-outline-diff.png) shows difference of GlyphVector outline printing before and after the fix.

I am not sure that we need the additional property for things other than possibly to workaround some possible bugs. I am fine if we will use the scaled version all the time, does it have any drawbacks?

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

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

From alanb at openjdk.java.net  Fri Nov 20 07:46:15 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 07:46:15 GMT
Subject: <AWT Dev> =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?q?dGroup_stop=2C_destroy=2C_isDestroyed=2C=E2=80=A6?=
Message-ID: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>

This change terminally deprecates the following methods defined by java.lang.ThreadGroup 

- stop 
- destroy 
- isDestroyed 
- setDaemon 
- isDaemon 

The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 

The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.

CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

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

Commit messages:
 - Update jshell class
 - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

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

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

From serb at openjdk.java.net  Fri Nov 20 07:46:15 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 20 Nov 2020 07:46:15 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?q?dGroup_stop=2C_destroy=2C_isDestroyed=2C=E2=80=A6?=
In-Reply-To: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
Message-ID: <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>

On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
> 
> - stop 
> - destroy 
> - isDestroyed 
> - setDaemon 
> - isDaemon 
> 
> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
> 
> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
> 
> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Fri Nov 20 07:46:15 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 20 Nov 2020 07:46:15 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?q?dGroup_stop=2C_destroy=2C_isDestroyed=2C=E2=80=A6?=
In-Reply-To: <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>
Message-ID: <_RP0iviwL3M-gRNDjdm_5I97T3V0SH1bMdrq4in4l6M=.ee1ab82e-9e1c-4d27-94c6-7c17eccbd51c@github.com>

On Thu, 19 Nov 2020 18:51:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Marked as reviewed by serb (Reviewer).

The changes in the awt are trivial and look fine.

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

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

From mullan at openjdk.java.net  Fri Nov 20 14:10:01 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 20 Nov 2020 14:10:01 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?q?dGroup_stop=2C_destroy=2C_isDestroyed=2C=E2=80=A6?=
In-Reply-To: <_RP0iviwL3M-gRNDjdm_5I97T3V0SH1bMdrq4in4l6M=.ee1ab82e-9e1c-4d27-94c6-7c17eccbd51c@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>
 <_RP0iviwL3M-gRNDjdm_5I97T3V0SH1bMdrq4in4l6M=.ee1ab82e-9e1c-4d27-94c6-7c17eccbd51c@github.com>
Message-ID: <S51-ecuyQ54MBq01TepG1IMNwWcSMWC9uiT_f4ZQESU=.bf2f83e8-5db9-4873-9882-c97b7a244946@github.com>

On Thu, 19 Nov 2020 18:53:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Marked as reviewed by serb (Reviewer).
>
> The changes in the awt are trivial and look fine.

I think it would be useful in the javadoc of the RuntimePermission targets (stopThread, etc) to add a note/link that the corresponding method that the permission applies to is terminally deprecated. Something as simple as "Note that the Thread.stop() method is terminally deprecated and will be deprecated in a future release."

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

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

From mullan at openjdk.java.net  Fri Nov 20 14:10:05 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 20 Nov 2020 14:10:05 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?q?dGroup_stop=2C_destroy=2C_isDestroyed=2C=E2=80=A6?=
In-Reply-To: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
Message-ID: <knW1V0OnHSYpmU66-hNTgSAr0HMTg1QaDF5fwV9A9sQ=.97d035ce-42a3-4103-ab8f-35c200b4ac48@github.com>

On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
> 
> - stop 
> - destroy 
> - isDestroyed 
> - setDaemon 
> - isDaemon 
> 
> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
> 
> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
> 
> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

src/java.base/share/classes/java/lang/ThreadGroup.java line 191:

> 189:      * @deprecated Destroying a thread group and its subgroups is not an atomic
> 190:      *             operation and is inherently racy with respect to threads that
> 191:      *             have been created but not have started. The concept of daemon

"a daemon group" sounds better to me.

src/java.base/share/classes/java/lang/ThreadGroup.java line 208:

> 206:      * @deprecated Destroying a thread group and its subgroups is not an atomic
> 207:      *             operation and is inherently racy with respect to threads that
> 208:      *             have been created but not have started. The ability to explicitly

"have not started"

src/java.base/share/classes/java/lang/ThreadGroup.java line 237:

> 235:      * @deprecated Destroying a thread group and its subgroups is not an atomic
> 236:      *             operation and is inherently racy with respect to threads that
> 237:      *             have been created but not have started. The concept of daemon

same comment as above - "a daemon group"

src/java.base/share/classes/java/lang/ThreadGroup.java line 790:

> 788:      * @deprecated Destroying a thread group and its subgroups is not an atomic
> 789:      *             operation and is inherently racy with respect to threads that
> 790:      *             have been created but not have started. The ability to explicitly

"have not started"

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

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

From alanb at openjdk.java.net  Fri Nov 20 14:45:07 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 14:45:07 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?q?dGroup_stop=2C_destroy=2C_isDestroyed=2C=E2=80=A6?=
In-Reply-To: <knW1V0OnHSYpmU66-hNTgSAr0HMTg1QaDF5fwV9A9sQ=.97d035ce-42a3-4103-ab8f-35c200b4ac48@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <knW1V0OnHSYpmU66-hNTgSAr0HMTg1QaDF5fwV9A9sQ=.97d035ce-42a3-4103-ab8f-35c200b4ac48@github.com>
Message-ID: <KAvIXZnGXNYBRq6b5pHas8eRZVibi1SqrFFI-sLBJVE=.ae7983a5-9847-4674-9c3b-6799995f510f@github.com>

On Fri, 20 Nov 2020 14:05:09 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> src/java.base/share/classes/java/lang/ThreadGroup.java line 191:
> 
>> 189:      * @deprecated Destroying a thread group and its subgroups is not an atomic
>> 190:      *             operation and is inherently racy with respect to threads that
>> 191:      *             have been created but not have started. The concept of daemon
> 
> "a daemon group" sounds better to me.

The existing spec uses "daemon thread group" so I'd prefer to stick with that.

> src/java.base/share/classes/java/lang/ThreadGroup.java line 208:
> 
>> 206:      * @deprecated Destroying a thread group and its subgroups is not an atomic
>> 207:      *             operation and is inherently racy with respect to threads that
>> 208:      *             have been created but not have started. The ability to explicitly
> 
> "have not started"

Thanks, there's a typo there.

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

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

From alanb at openjdk.java.net  Fri Nov 20 14:52:07 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 14:52:07 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?q?dGroup_stop=2C_destroy=2C_isDestroyed=2C=E2=80=A6?=
In-Reply-To: <S51-ecuyQ54MBq01TepG1IMNwWcSMWC9uiT_f4ZQESU=.bf2f83e8-5db9-4873-9882-c97b7a244946@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>
 <_RP0iviwL3M-gRNDjdm_5I97T3V0SH1bMdrq4in4l6M=.ee1ab82e-9e1c-4d27-94c6-7c17eccbd51c@github.com>
 <S51-ecuyQ54MBq01TepG1IMNwWcSMWC9uiT_f4ZQESU=.bf2f83e8-5db9-4873-9882-c97b7a244946@github.com>
Message-ID: <RmLft_qv51ThYdWa5EleLBhHRK4i_DnhzLMsZX9jS48=.bca371ab-52bc-473b-9fbf-b8add5895e24@github.com>

On Fri, 20 Nov 2020 14:03:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> I think it would be useful in the javadoc of the RuntimePermission targets (stopThread, etc) to add a note/link that the corresponding method that the permission applies to is terminally deprecated. Something as simple as "Note that the Thread.stop() method is terminally deprecated and will be removed in a future release."

We haven't changed Thread.stop here, I would like to get that done too but as separate issue because it will require wider discussion. The main thing for now is the prep work before proposing to shove ThreadGroup to the side.

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

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

From alanb at openjdk.java.net  Fri Nov 20 15:08:27 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 15:08:27 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?b?ZEdyb3VwIHN0b3AsIGRlc3Ryb3ksIGlzRGVzdHJveWVkLOKApiBbdjJd?=
In-Reply-To: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
Message-ID: <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>

> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
> 
> - stop 
> - destroy 
> - isDestroyed 
> - setDaemon 
> - isDaemon 
> 
> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
> 
> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
> 
> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

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

 - Fixed typo in @deprecated text
 - Merge
 - Update jshell class
 - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1318/files
  - new: https://git.openjdk.java.net/jdk/pull/1318/files/c661861a..ca656ba1

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

  Stats: 99634 lines in 382 files changed: 45266 ins; 43186 del; 11182 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1318.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1318/head:pull/1318

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

From mullan at openjdk.java.net  Fri Nov 20 15:23:06 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 20 Nov 2020 15:23:06 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?b?ZEdyb3VwIHN0b3AsIGRlc3Ryb3ksIGlzRGVzdHJveWVkLOKApiBbdjJd?=
In-Reply-To: <RmLft_qv51ThYdWa5EleLBhHRK4i_DnhzLMsZX9jS48=.bca371ab-52bc-473b-9fbf-b8add5895e24@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>
 <_RP0iviwL3M-gRNDjdm_5I97T3V0SH1bMdrq4in4l6M=.ee1ab82e-9e1c-4d27-94c6-7c17eccbd51c@github.com>
 <S51-ecuyQ54MBq01TepG1IMNwWcSMWC9uiT_f4ZQESU=.bf2f83e8-5db9-4873-9882-c97b7a244946@github.com>
 <RmLft_qv51ThYdWa5EleLBhHRK4i_DnhzLMsZX9jS48=.bca371ab-52bc-473b-9fbf-b8add5895e24@github.com>
Message-ID: <6PdDak1NVV78CaUuKR8Xl6wVwSvVcCZyPHYcE8LytmY=.3831f142-9fc4-44bf-b0c1-ac45d20b7716@github.com>

On Fri, 20 Nov 2020 14:49:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I think it would be useful in the javadoc of the RuntimePermission targets (stopThread, etc) to add a note/link that the corresponding method that the permission applies to is terminally deprecated. Something as simple as "Note that the Thread.stop() method is terminally deprecated and will be removed in a future release."
> 
> We haven't changed Thread.stop here, I would like to get that done too but as separate issue because it will require wider discussion. The main thing for now is the prep work before proposing to shove ThreadGroup to the side.

Ok, but then how about putting a similar note in the javadoc for the RuntimePermission "modifyThreadGroup" target?

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

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

From rriggs at openjdk.java.net  Fri Nov 20 15:30:06 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 20 Nov 2020 15:30:06 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?b?ZEdyb3VwIHN0b3AsIGRlc3Ryb3ksIGlzRGVzdHJveWVkLOKApiBbdjJd?=
In-Reply-To: <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
Message-ID: <F34EKW5I8GbRhzXZi719lQ8HKQ1Zw-pztK8xnqq_1Wo=.4925ab34-f769-47fc-9373-a9a9144a6a66@github.com>

On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fixed typo in @deprecated text
>  - Merge
>  - Update jshell class
>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/java/lang/ThreadGroup.java line 194:

> 192:      *             thread group that is automatically destroyed will be removed
> 193:      *             in a future release.
> 194:      */

I would switch the order of the sentences.  Put the action first and the rationale second. $.02
(in all the @ deprecated javadoc).

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

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

From alanb at openjdk.java.net  Fri Nov 20 15:53:10 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 15:53:10 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?b?ZEdyb3VwIHN0b3AsIGRlc3Ryb3ksIGlzRGVzdHJveWVkLOKApiBbdjJd?=
In-Reply-To: <F34EKW5I8GbRhzXZi719lQ8HKQ1Zw-pztK8xnqq_1Wo=.4925ab34-f769-47fc-9373-a9a9144a6a66@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
 <F34EKW5I8GbRhzXZi719lQ8HKQ1Zw-pztK8xnqq_1Wo=.4925ab34-f769-47fc-9373-a9a9144a6a66@github.com>
Message-ID: <f4NAmy4mSHMpUvmLiLgYu0fyPKdOhfs7JTVwearn3n4=.7358afe5-60ce-44b2-b78a-fa32d879f2b8@github.com>

On Fri, 20 Nov 2020 15:27:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Fixed typo in @deprecated text
>>  - Merge
>>  - Update jshell class
>>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon
>
> Marked as reviewed by rriggs (Reviewer).

> Ok, but then how about putting a similar note in the javadoc for the RuntimePermission "modifyThreadGroup" target?

The "modifyThread" and "modifyThreadGroup" permission targets list methods that have been terminally deprecated for some time, are you looking for both permission targets to be updated? I could imagine doing an overall here, also re-visiting SecurityManager checkAccess(ThreadGroup) but it feels like it's beyond the scope of the deprecation proposed here and would be better off being left to when we eventually degrade and/or remove these methods.

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

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

From mullan at openjdk.java.net  Fri Nov 20 16:08:03 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 20 Nov 2020 16:08:03 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?b?ZEdyb3VwIHN0b3AsIGRlc3Ryb3ksIGlzRGVzdHJveWVkLOKApiBbdjJd?=
In-Reply-To: <f4NAmy4mSHMpUvmLiLgYu0fyPKdOhfs7JTVwearn3n4=.7358afe5-60ce-44b2-b78a-fa32d879f2b8@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
 <F34EKW5I8GbRhzXZi719lQ8HKQ1Zw-pztK8xnqq_1Wo=.4925ab34-f769-47fc-9373-a9a9144a6a66@github.com>
 <f4NAmy4mSHMpUvmLiLgYu0fyPKdOhfs7JTVwearn3n4=.7358afe5-60ce-44b2-b78a-fa32d879f2b8@github.com>
Message-ID: <zNb8XgYqE_s32lKNQORnUGoh6nKBHaHLMq96y7WFBH4=.8398dd8d-2783-4c18-ae69-e4f90eed3171@github.com>

On Fri, 20 Nov 2020 15:50:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Ok, but then how about putting a similar note in the javadoc for the RuntimePermission "modifyThreadGroup" target?
> 
> The "modifyThread" and "modifyThreadGroup" permission targets list methods that have been terminally deprecated for some time, are you looking for both permission targets to be updated? I could imagine doing an overall here, also re-visiting SecurityManager checkAccess(ThreadGroup) but it feels like it's beyond the scope of the deprecation proposed here and would be better off being left to when we eventually degrade and/or remove these methods.

Ok, I see there is a broader context for my comment. I think then it makes sense to open a separate issue to specify these various RuntimePermission targets that are associated with deprecated APIs. In my mind, these permission targets are standard targets and should also be "deprecated" even if there is no annotation that can formally indicate that. For comparison, SecurityPermission puts these in a separate table in the class summary: https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/security/SecurityPermission.html
If you agree, I can file an issue.

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

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

From alanb at openjdk.java.net  Fri Nov 20 17:03:04 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 17:03:04 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?b?ZEdyb3VwIHN0b3AsIGRlc3Ryb3ksIGlzRGVzdHJveWVkLOKApiBbdjJd?=
In-Reply-To: <zNb8XgYqE_s32lKNQORnUGoh6nKBHaHLMq96y7WFBH4=.8398dd8d-2783-4c18-ae69-e4f90eed3171@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
 <F34EKW5I8GbRhzXZi719lQ8HKQ1Zw-pztK8xnqq_1Wo=.4925ab34-f769-47fc-9373-a9a9144a6a66@github.com>
 <f4NAmy4mSHMpUvmLiLgYu0fyPKdOhfs7JTVwearn3n4=.7358afe5-60ce-44b2-b78a-fa32d879f2b8@github.com>
 <zNb8XgYqE_s32lKNQORnUGoh6nKBHaHLMq96y7WFBH4=.8398dd8d-2783-4c18-ae69-e4f90eed3171@github.com>
Message-ID: <CIzjSKmsDowUN8Fug1JXYQX-8jjtG-Tq_3rgkoth4gg=.7ef98fa1-64a9-4757-b2dd-ecfab998da1c@github.com>

On Fri, 20 Nov 2020 16:05:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> If you agree, I can file an issue.

Yes, make sense to separate this out, esp. permission targets such as "stopThread" where all usages are in deprecated methods. However, I don't expect "modifyThreadGroup" would be deprecated, at least not yet, because there are usages in several methods that are not deprecated.

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

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

From serb at openjdk.java.net  Fri Nov 20 17:58:10 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 20 Nov 2020 17:58:10 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?b?ZEdyb3VwIHN0b3AsIGRlc3Ryb3ksIGlzRGVzdHJveWVkLOKApiBbdjJd?=
In-Reply-To: <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
Message-ID: <sV1eWm3ZqFAQ0yM8ZplcYHqeMx_OK67VcDDVP4Y7rjg=.1124de6a-5992-4937-a849-06d4a3ea8e3b@github.com>

On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fixed typo in @deprecated text
>  - Merge
>  - Update jshell class
>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Marked as reviewed by serb (Reviewer).

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

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

From iris at openjdk.java.net  Fri Nov 20 19:28:10 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 20 Nov 2020 19:28:10 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?b?ZEdyb3VwIHN0b3AsIGRlc3Ryb3ksIGlzRGVzdHJveWVkLOKApiBbdjJd?=
In-Reply-To: <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
Message-ID: <eWF-EAOrTnAd5-66ObnEMDFMfWb5IEETjlTPHmQqFSE=.eaf8ffbd-c78b-432d-b75d-48cbf9fc0d27@github.com>

On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fixed typo in @deprecated text
>  - Merge
>  - Update jshell class
>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Marked as reviewed by iris (Reviewer).

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

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

From mchung at openjdk.java.net  Fri Nov 20 20:03:07 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 20 Nov 2020 20:03:07 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?b?ZEdyb3VwIHN0b3AsIGRlc3Ryb3ksIGlzRGVzdHJveWVkLOKApiBbdjJd?=
In-Reply-To: <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
Message-ID: <KNTRfhuv-SQDYNpXgSzY4X2w3M06la8mU-4nAvHDQfo=.e36dd3eb-2df4-4529-afb6-7094fdb2ee6b@github.com>

On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fixed typo in @deprecated text
>  - Merge
>  - Update jshell class
>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Marked as reviewed by mchung (Reviewer).

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

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

From alexsch at openjdk.java.net  Fri Nov 20 20:05:21 2020
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Fri, 20 Nov 2020 20:05:21 GMT
Subject: <AWT Dev> RFR: 8256264: Printed GlyphVector outline with low
 DPI has bad quality on Windows [v2]
In-Reply-To: <iA4R8RQHqStufCJRG2qB5tJODvX-mIlqv392YbdNE84=.5bfe5fa6-6062-45ec-aebd-d193cf8b76c6@github.com>
References: <iA4R8RQHqStufCJRG2qB5tJODvX-mIlqv392YbdNE84=.5bfe5fa6-6062-45ec-aebd-d193cf8b76c6@github.com>
Message-ID: <RfOptqTyvLPRrQSe0BGMcpeI1tTexNPfJBXXJJlTjNg=.92ca6311-1b1a-43cc-b035-2f294cd0e899@github.com>

> Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows.
> The GDI system used for text printing on Windows accepts only integer path coordinates.
> Rounding GlyphVector outline coordinates leads to distorted printed text.
> 
> To reproduce the issue run the [PrintGlyphVectorOutlineSample](https://bugs.openjdk.java.net/secure/attachment/91398/PrintGlyphVectorOutlineSample.java)  file on Windows and select a low DPI
> printer in the printer dialog. The sample prints two lines, one using Graphics drawString() method and another by
> filling GlyphVector outline. Chars on the second line are distorted.
> 
> It is also possible to reproduce the issue running the sample and printing the text to PDF: [fill-glyph-vector-outline.png](https://bugs.openjdk.java.net/secure/attachment/91397/fill-glyph-vector-outline.png)
> 
> The proposed fix introduce "sun.java2d.print.enablePathPrecisionScale" property which being enabled
> scales the GDI WorldTransform down and GlyphVector outline coordinates up.
> This allows to keep some digits after a dot from being rounded.
> The value for scaling is chosen to be 1000 in the same way how it is used  by `String trunc(float f)` method from PSPrinterJob class on Linux:
> https://github.com/openjdk/jdk/blob/ed615e3ca0d681e8e67cdbf1d5d964979ccd7888/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#L1489
> 
> See the  [fill-glyph-vector-outline-enable-path-scale-factor.png](https://bugs.openjdk.java.net/secure/attachment/91399/fill-glyph-vector-outline-enable-path-scale-factor.png) screenshot which shows how the GlyphVector outline is filled after the fix with the enabled "sun.java2d.print.enablePathPrecisionScale" option.
> 
> [fill-glyph-vector-outline-diff.png](https://bugs.openjdk.java.net/secure/attachment/91400/fill-glyph-vector-outline-diff.png) shows difference of GlyphVector outline printing before and after the fix.

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

  Remove sun.java2d.print.enablePathPrecisionScale property from JDK-8256264 fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1183/files
  - new: https://git.openjdk.java.net/jdk/pull/1183/files/120ae32b..f79b8014

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

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

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

From smarks at openjdk.java.net  Fri Nov 20 20:15:08 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 20 Nov 2020 20:15:08 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?b?ZEdyb3VwIHN0b3AsIGRlc3Ryb3ksIGlzRGVzdHJveWVkLOKApiBbdjJd?=
In-Reply-To: <KNTRfhuv-SQDYNpXgSzY4X2w3M06la8mU-4nAvHDQfo=.e36dd3eb-2df4-4529-afb6-7094fdb2ee6b@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
 <KNTRfhuv-SQDYNpXgSzY4X2w3M06la8mU-4nAvHDQfo=.e36dd3eb-2df4-4529-afb6-7094fdb2ee6b@github.com>
Message-ID: <C5wgUmALPM359dZJVMr_pvM2Ij1mVORRJti2Oby28qg=.bce3ef94-229d-4e4d-9bde-5f2276c83732@github.com>

On Fri, 20 Nov 2020 19:59:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Fixed typo in @deprecated text
>>  - Merge
>>  - Update jshell class
>>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon
>
> Marked as reviewed by mchung (Reviewer).

I think the current deprecation wording is actually too specific regarding the raciness between TG destruction and created-but-not-started threads. That's just one of the flaws of thread groups. In fact, I think there are enough weirdnesses and race conditions around all destruction-related operations of thread groups that the whole concept is fundamentally flawed. We should just say that. How about this:

> ThreadGroup's destruction mechanisms are fundamentally flawed. Therefore, the ThreadGroup methods destroy(), isDestroyed(), setDaemon(), and isDaemon(), which relate to ThreadGroup destruction, have been deprecated and may be removed from a future version of the system.

I think there are too many subtle details to include a justification here about why TG destruction is fundamentally flawed, so we just have to assert that. Unfortunately the writeups in the JEP and CSR are in draft state so we can't link to them. Maybe when the JEP is published we can add a link to it from here later.

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

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

From alexsch at openjdk.java.net  Fri Nov 20 20:26:10 2020
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Fri, 20 Nov 2020 20:26:10 GMT
Subject: <AWT Dev> RFR: 8256264: Printed GlyphVector outline with low
 DPI has bad quality on Windows
In-Reply-To: <a4IkTW6qwFnlbnrq-SMzkaDuAOLCrescYF4ts0mV9-Q=.fd7c6323-6561-4897-932d-4d8e6392ff8e@github.com>
References: <iA4R8RQHqStufCJRG2qB5tJODvX-mIlqv392YbdNE84=.5bfe5fa6-6062-45ec-aebd-d193cf8b76c6@github.com>
 <a4IkTW6qwFnlbnrq-SMzkaDuAOLCrescYF4ts0mV9-Q=.fd7c6323-6561-4897-932d-4d8e6392ff8e@github.com>
Message-ID: <OQb2sicw9j00AWw_SD-MHP_0MRS97F08M3Rep1xCHrg=.e4e598ca-0354-4b36-b954-75aed241ad08@github.com>

On Fri, 20 Nov 2020 06:31:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows.
>> The GDI system used for text printing on Windows accepts only integer path coordinates.
>> Rounding GlyphVector outline coordinates leads to distorted printed text.
>> 
>> To reproduce the issue run the [PrintGlyphVectorOutlineSample](https://bugs.openjdk.java.net/secure/attachment/91398/PrintGlyphVectorOutlineSample.java)  file on Windows and select a low DPI
>> printer in the printer dialog. The sample prints two lines, one using Graphics drawString() method and another by
>> filling GlyphVector outline. Chars on the second line are distorted.
>> 
>> It is also possible to reproduce the issue running the sample and printing the text to PDF: [fill-glyph-vector-outline.png](https://bugs.openjdk.java.net/secure/attachment/91397/fill-glyph-vector-outline.png)
>> 
>> The proposed fix introduce "sun.java2d.print.enablePathPrecisionScale" property which being enabled
>> scales the GDI WorldTransform down and GlyphVector outline coordinates up.
>> This allows to keep some digits after a dot from being rounded.
>> The value for scaling is chosen to be 1000 in the same way how it is used  by `String trunc(float f)` method from PSPrinterJob class on Linux:
>> https://github.com/openjdk/jdk/blob/ed615e3ca0d681e8e67cdbf1d5d964979ccd7888/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#L1489
>> 
>> See the  [fill-glyph-vector-outline-enable-path-scale-factor.png](https://bugs.openjdk.java.net/secure/attachment/91399/fill-glyph-vector-outline-enable-path-scale-factor.png) screenshot which shows how the GlyphVector outline is filled after the fix with the enabled "sun.java2d.print.enablePathPrecisionScale" option.
>> 
>> [fill-glyph-vector-outline-diff.png](https://bugs.openjdk.java.net/secure/attachment/91400/fill-glyph-vector-outline-diff.png) shows difference of GlyphVector outline printing before and after the fix.
>
> I am not sure that we need the additional property for things other than possibly to workaround some possible bugs. I am fine if we will use the scaled version all the time, does it have any drawbacks?

I prepared a simple [print test](http://cr.openjdk.java.net/~alexsch/8256264/performance/PrintTextPerformanceTest.java) sample which uses 4 different fonts (plain and bold) with different sizes and prints 640 lines on 10 pages.

I run the sample with and without the fix to PDF and measured the time which is used by the  deviceFill() method (it both converts the shape to path and fills it):
https://github.com/openjdk/jdk/blob/b21b96df2162c72098afcdfd2cf243a55a0f17e1/src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java#L1489

The average time without the fix: 2.77s (min 2.74s, max 2,78)
The average time with the fix: 2.76s (min 2.74s, max 2.77)

I removed the `sun.java2d.print.enablePathPrecisionScale` property from the fix.

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

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

From serb at openjdk.java.net  Sat Nov 21 22:23:15 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 21 Nov 2020 22:23:15 GMT
Subject: <AWT Dev> RFR: 6508941: java.awt.Desktop.open causes VM to crash
 with video files sporadically
Message-ID: <UdGqCPJqVEPnkbOF2jmoK4v27Wx2yLrcd0GN3P85U_4=.4fcf2a24-6014-4591-9e11-f1552b2324a5@github.com>

The report of this bug quite outdated so can be closed but I found that in the documentation:
https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutea

> Because ShellExecute can delegate execution to Shell extensions (data sources, context menu handlers, verb implementations) that are activated using Component Object Model (COM), COM should be initialized before ShellExecute is called. Some Shell extensions require the COM single-threaded apartment (STA) type. In that case, COM should be initialized as shown here: CoInitializeEx(NULL, COINIT_APARTMENTTHREADED | COINIT_DISABLE_OLE1DDE)

But this CoInitializeEx is missed in the Desktop class. Absent of this initialization caused some other crashes in past, see JDK-6950553 for example:
https://bugs.openjdk.java.net/browse/JDK-6950553

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

Commit messages:
 - Initial fix

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

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

From alanb at openjdk.java.net  Sun Nov 22 16:00:45 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 22 Nov 2020 16:00:45 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?b?ZEdyb3VwIHN0b3AsIGRlc3Ryb3ksIGlzRGVzdHJveWVkLOKApiBbdjNd?=
In-Reply-To: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
Message-ID: <vDmkugOG_EATqtXaLA73yTD04IAtIVOT92_cixJfTqM=.d2f05630-f0ea-4f5a-be38-5742dd4aea00@github.com>

> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
> 
> - stop 
> - destroy 
> - isDestroyed 
> - setDaemon 
> - isDaemon 
> 
> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
> 
> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
> 
> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

Alan Bateman 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 six additional commits since the last revision:

 - Tweak wording of @deprecated message to make it more general
 - Merge
 - Fixed typo in @deprecated text
 - Merge
 - Update jshell class
 - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1318/files
  - new: https://git.openjdk.java.net/jdk/pull/1318/files/ca656ba1..38d951b9

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

  Stats: 1688 lines in 57 files changed: 885 ins; 381 del; 422 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1318.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1318/head:pull/1318

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

From alanb at openjdk.java.net  Sun Nov 22 16:05:24 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 22 Nov 2020 16:05:24 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?b?ZEdyb3VwIHN0b3AsIGRlc3Ryb3ksIGlzRGVzdHJveWVkLOKApiBbdjJd?=
In-Reply-To: <C5wgUmALPM359dZJVMr_pvM2Ij1mVORRJti2Oby28qg=.bce3ef94-229d-4e4d-9bde-5f2276c83732@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
 <KNTRfhuv-SQDYNpXgSzY4X2w3M06la8mU-4nAvHDQfo=.e36dd3eb-2df4-4529-afb6-7094fdb2ee6b@github.com>
 <C5wgUmALPM359dZJVMr_pvM2Ij1mVORRJti2Oby28qg=.bce3ef94-229d-4e4d-9bde-5f2276c83732@github.com>
Message-ID: <jTvzKn7GriuFfNKgxLnz0bSa-AWRI0tmIIuPz3l692E=.057ca93b-33fc-42ad-8ede-3103d2a716f1@github.com>

On Fri, 20 Nov 2020 20:12:31 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Marked as reviewed by mchung (Reviewer).
>
> I think the current deprecation wording is actually too specific regarding the raciness between TG destruction and created-but-not-started threads. That's just one of the flaws of thread groups. In fact, I think there are enough weirdnesses and race conditions around all destruction-related operations of thread groups that the whole concept is fundamentally flawed. We should just say that. How about this:
> 
>> ThreadGroup's destruction mechanisms are fundamentally flawed. Therefore, the ThreadGroup methods destroy(), isDestroyed(), setDaemon(), and isDaemon(), which relate to ThreadGroup destruction, have been deprecated and may be removed from a future version of the system.
> 
> I think there are too many subtle details to include a justification here about why TG destruction is fundamentally flawed, so we just have to assert that. Unfortunately the writeups in the JEP and CSR are in draft state so we can't link to them. Maybe when the JEP is published we can add a link to it from here later.

Okay, I think I agree that the first sentence needs to be a bit more general so I've re-worded it. I used "inherently" rather than "fundamentally" to be consistent with the other deprecation text in Thread/ThreadGroup. If you are okay with the updated text then I'll transfer it to the CSR.

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

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

From smarks at openjdk.java.net  Tue Nov 24 20:03:03 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 24 Nov 2020 20:03:03 GMT
Subject: <AWT Dev> 
 =?utf-8?q?RFR=3A_8256643=3A_Terminally_deprecate_Threa?=
 =?utf-8?b?ZEdyb3VwIHN0b3AsIGRlc3Ryb3ksIGlzRGVzdHJveWVkLOKApiBbdjNd?=
In-Reply-To: <vDmkugOG_EATqtXaLA73yTD04IAtIVOT92_cixJfTqM=.d2f05630-f0ea-4f5a-be38-5742dd4aea00@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <vDmkugOG_EATqtXaLA73yTD04IAtIVOT92_cixJfTqM=.d2f05630-f0ea-4f5a-be38-5742dd4aea00@github.com>
Message-ID: <fv7k_Hj3Wkkx0xIayMan4G8DTJNXfVa_rFipU6jVydo=.1a82f547-ea9c-4a88-a97b-77e2f81f01da@github.com>

On Sun, 22 Nov 2020 16:00:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Alan Bateman 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 six additional commits since the last revision:
> 
>  - Tweak wording of @deprecated message to make it more general
>  - Merge
>  - Fixed typo in @deprecated text
>  - Merge
>  - Update jshell class
>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

I'm ok with the wording "inherently flawed."

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

Marked as reviewed by smarks (Reviewer).

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

From serb at openjdk.java.net  Wed Nov 25 00:52:09 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 25 Nov 2020 00:52:09 GMT
Subject: <AWT Dev> RFR: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails
Message-ID: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>

Here is a fix for one of the annoying bug, which causes random test failures in the CI.

We have a method Robot.waitForIdle(), which supposed to wait until the java and the native queue stabilized. The common use case is to click on the button or show the window, and call waitForIdle() which will wait until the native event will be dispatched by the X11/Windows/macOS as well as followed Java event(paint/focus/etc event) will be dispatched to the EDT.

Currently, it is implemented in this way:
  1. Flush the EventQueue, so all old events will be posted to EDT.
  2. Flush the native event queue, by posting the native event.
  3. Flush the EDT, by posting a java event.
  4. If some events(unrelated to waitForIdle machinery) were dispatched on steps 2. or 3. then repeat since step 1.

It is implemented that they because the native events caused by the OS usually generate the java events, and the java events may generate native events. So we have to wait for both queues (java/native).

But it has the next disadvantages:
 - It is implemented as a busy loop, which does not give a chance for the application to proceed further since it blocks 3 threads EDT/native toolkit thread like appkit/main thread.
- It throws the InfiniteLoop exception if the number of attempts is bigger than 20. And this limitation is too small because some tests generate much more events during startup.
 - Note that the timeout value for the realSync method is 10 seconds, and it was assumed that this method will not be executed longer, but it uses this timeout for all events flushing which can lead up to 600 seconds (20 iters * 3  calls * 10 seconds).


The fix:
 - Add a small delay to the method, so the app can do something useful when waitForIdle() is called
 - The timeout=10 second is taken care of, we calculate the "end" time and exits if it is exceeded
 - The maximum number of attempts is increased to 100 and InfiniteLoop is removed.

Note that I have made one additional change to the new realSync implementation. At the beginning of the method I call:
 EventQueue.invokeAndWait(() -> {/*dummy implementation*/});
It is needed to be sure that we flush the first event on EDT even if we spend more time than 10 seconds.

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

Commit messages:
 - Update SunToolkit.java
 - The new tests
 - Do not use shared state
 - Update SunToolkit.java
 - realSync too slow
 - Update bug5074573.java
 - Test update
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/1424/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1424&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8196100
  Stats: 242 lines in 9 files changed: 192 ins; 20 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1424.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1424/head:pull/1424

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

From alanb at openjdk.java.net  Wed Nov 25 08:28:59 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 25 Nov 2020 08:28:59 GMT
Subject: <AWT Dev> Integrated: 8256643: Terminally deprecate ThreadGroup
 stop, destroy, isDestroyed, setDaemon and isDaemon
In-Reply-To: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
Message-ID: <eZag_nwpvxIv6r1yW69IhT8Vrqu9WkUqEe4ArPvy8OE=.4d84b65f-ca2c-4f6c-af3d-93623fb41b06@github.com>

On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
> 
> - stop 
> - destroy 
> - isDestroyed 
> - setDaemon 
> - isDaemon 
> 
> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
> 
> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
> 
> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

This pull request has now been integrated.

Changeset: 79e57ace
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/79e57ace
Stats:     26 lines in 4 files changed: 23 ins; 0 del; 3 mod

8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Reviewed-by: serb, rriggs, iris, mchung, smarks

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

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

From kizune at openjdk.java.net  Wed Nov 25 17:52:03 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 25 Nov 2020 17:52:03 GMT
Subject: <AWT Dev> RFR: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails
In-Reply-To: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
References: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
Message-ID: <-3MWzl2XJ7KjbSdtS3LZpz4mqE2hG4MLa5iL8XnDQLE=.1951234f-6a8c-4414-849b-c0f53ac52c16@github.com>

On Wed, 25 Nov 2020 00:15:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Here is a fix for one of the annoying bug, which causes random test failures in the CI.
> 
> We have a method Robot.waitForIdle(), which supposed to wait until the java and the native queue stabilized. The common use case is to click on the button or show the window, and call waitForIdle() which will wait until the native event will be dispatched by the X11/Windows/macOS as well as followed Java event(paint/focus/etc event) will be dispatched to the EDT.
> 
> Currently, it is implemented in this way:
>   1. Flush the EventQueue, so all old events will be posted to EDT.
>   2. Flush the native event queue, by posting the native event.
>   3. Flush the EDT, by posting a java event.
>   4. If some events(unrelated to waitForIdle machinery) were dispatched on steps 2. or 3. then repeat since step 1.
> 
> It is implemented that they because the native events caused by the OS usually generate the java events, and the java events may generate native events. So we have to wait for both queues (java/native).
> 
> But it has the next disadvantages:
>  - It is implemented as a busy loop, which does not give a chance for the application to proceed further since it blocks 3 threads EDT/native toolkit thread like appkit/main thread.
> - It throws the InfiniteLoop exception if the number of attempts is bigger than 20. And this limitation is too small because some tests generate much more events during startup.
>  - Note that the timeout value for the realSync method is 10 seconds, and it was assumed that this method will not be executed longer, but it uses this timeout for all events flushing which can lead up to 600 seconds (20 iters * 3  calls * 10 seconds).
> 
> 
> The fix:
>  - Add a small delay to the method, so the app can do something useful when waitForIdle() is called
>  - The timeout=10 second is taken care of, we calculate the "end" time and exits if it is exceeded
>  - The maximum number of attempts is increased to 100 and InfiniteLoop is removed.
> 
> Note that I have made one additional change to the new realSync implementation. At the beginning of the method I call:
>  EventQueue.invokeAndWait(() -> {/*dummy implementation*/});
> It is needed to be sure that we flush the first event on EDT even if we spend more time than 10 seconds.

src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1383:

> 1381:                 it.next().modalityPopped(ev);
> 1382:             }
> 1383:         }

I think that the rationale behind this exception as that in case of really stuck loop we could identify it. Why are we throwing it away? Now when we exceed the maximum allowed number of iterations we are assuming that the native event queue synchronization happened while it might not be the case.

test/jdk/java/awt/Robot/InfiniteLoopException.java line 63:

> 61:         long time = TimeUnit.NANOSECONDS.toSeconds(System.nanoTime() - start);
> 62:         if (time > 20) {
> 63:             throw new RuntimeException("To slow:" + time);

Typo? Shouldn't it be "Too slow"?

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

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

From serb at openjdk.java.net  Thu Nov 26 04:45:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Nov 2020 04:45:58 GMT
Subject: <AWT Dev> RFR: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails
In-Reply-To: <-3MWzl2XJ7KjbSdtS3LZpz4mqE2hG4MLa5iL8XnDQLE=.1951234f-6a8c-4414-849b-c0f53ac52c16@github.com>
References: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
 <-3MWzl2XJ7KjbSdtS3LZpz4mqE2hG4MLa5iL8XnDQLE=.1951234f-6a8c-4414-849b-c0f53ac52c16@github.com>
Message-ID: <I3bK-oKlSeKQIVrEfJ5uW6lq5QVjmz5KiOzIwrFyHD8=.4f3b4b6b-6cee-4081-9d6b-240ffccf8e17@github.com>

On Wed, 25 Nov 2020 17:48:06 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Here is a fix for one of the annoying bug, which causes random test failures in the CI.
>> 
>> We have a method Robot.waitForIdle(), which supposed to wait until the java and the native queue stabilized. The common use case is to click on the button or show the window, and call waitForIdle() which will wait until the native event will be dispatched by the X11/Windows/macOS as well as followed Java event(paint/focus/etc event) will be dispatched to the EDT.
>> 
>> Currently, it is implemented in this way:
>>   1. Flush the EventQueue, so all old events will be posted to EDT.
>>   2. Flush the native event queue, by posting the native event.
>>   3. Flush the EDT, by posting a java event.
>>   4. If some events(unrelated to waitForIdle machinery) were dispatched on steps 2. or 3. then repeat since step 1.
>> 
>> It is implemented that they because the native events caused by the OS usually generate the java events, and the java events may generate native events. So we have to wait for both queues (java/native).
>> 
>> But it has the next disadvantages:
>>  - It is implemented as a busy loop, which does not give a chance for the application to proceed further since it blocks 3 threads EDT/native toolkit thread like appkit/main thread.
>> - It throws the InfiniteLoop exception if the number of attempts is bigger than 20. And this limitation is too small because some tests generate much more events during startup.
>>  - Note that the timeout value for the realSync method is 10 seconds, and it was assumed that this method will not be executed longer, but it uses this timeout for all events flushing which can lead up to 600 seconds (20 iters * 3  calls * 10 seconds).
>> 
>> 
>> The fix:
>>  - Add a small delay to the method, so the app can do something useful when waitForIdle() is called
>>  - The timeout=10 second is taken care of, we calculate the "end" time and exits if it is exceeded
>>  - The maximum number of attempts is increased to 100 and InfiniteLoop is removed.
>> 
>> Note that I have made one additional change to the new realSync implementation. At the beginning of the method I call:
>>  EventQueue.invokeAndWait(() -> {/*dummy implementation*/});
>> It is needed to be sure that we flush the first event on EDT even if we spend more time than 10 seconds.
>
> src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1383:
> 
>> 1381:                 it.next().modalityPopped(ev);
>> 1382:             }
>> 1383:         }
> 
> I think that the rationale behind this exception as that in case of really stuck loop we could identify it. Why are we throwing it away? Now when we exceed the maximum allowed number of iterations we are assuming that the native event queue synchronization happened while it might not be the case.

Yes, that was the initial goal, but currently, it does not work well if some of the components use animation and periodically repainted we hit this exception.

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

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

From serb at openjdk.java.net  Thu Nov 26 04:52:17 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Nov 2020 04:52:17 GMT
Subject: <AWT Dev> RFR: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails [v2]
In-Reply-To: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
References: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
Message-ID: <ZLl36uuUpcZmP2V6pLn_krKMVxLzl-tiBQkPrPuzVV8=.a9773fe5-c856-4390-a075-5e01184c095b@github.com>

> Here is a fix for one of the annoying bug, which causes random test failures in the CI.
> 
> We have a method Robot.waitForIdle(), which supposed to wait until the java and the native queue stabilized. The common use case is to click on the button or show the window, and call waitForIdle() which will wait until the native event will be dispatched by the X11/Windows/macOS as well as followed Java event(paint/focus/etc event) will be dispatched to the EDT.
> 
> Currently, it is implemented in this way:
>   1. Flush the EventQueue, so all old events will be posted to EDT.
>   2. Flush the native event queue, by posting the native event.
>   3. Flush the EDT, by posting a java event.
>   4. If some events(unrelated to waitForIdle machinery) were dispatched on steps 2. or 3. then repeat since step 1.
> 
> It is implemented that they because the native events caused by the OS usually generate the java events, and the java events may generate native events. So we have to wait for both queues (java/native).
> 
> But it has the next disadvantages:
>  - It is implemented as a busy loop, which does not give a chance for the application to proceed further since it blocks 3 threads EDT/native toolkit thread like appkit/main thread.
> - It throws the InfiniteLoop exception if the number of attempts is bigger than 20. And this limitation is too small because some tests generate much more events during startup.
>  - Note that the timeout value for the realSync method is 10 seconds, and it was assumed that this method will not be executed longer, but it uses this timeout for all events flushing which can lead up to 600 seconds (20 iters * 3  calls * 10 seconds).
> 
> 
> The fix:
>  - Add a small delay to the method, so the app can do something useful when waitForIdle() is called
>  - The timeout=10 second is taken care of, we calculate the "end" time and exits if it is exceeded
>  - The maximum number of attempts is increased to 100 and InfiniteLoop is removed.
> 
> Note that I have made one additional change to the new realSync implementation. At the beginning of the method I call:
>  EventQueue.invokeAndWait(() -> {/*dummy implementation*/});
> It is needed to be sure that we flush the first event on EDT even if we spend more time than 10 seconds.

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

  Update test/jdk/java/awt/Robot/InfiniteLoopException.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1424/files
  - new: https://git.openjdk.java.net/jdk/pull/1424/files/1bbd7ba1..1229546b

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

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

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

From serb at openjdk.java.net  Thu Nov 26 04:52:18 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Nov 2020 04:52:18 GMT
Subject: <AWT Dev> RFR: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails [v2]
In-Reply-To: <ZLl36uuUpcZmP2V6pLn_krKMVxLzl-tiBQkPrPuzVV8=.a9773fe5-c856-4390-a075-5e01184c095b@github.com>
References: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
 <ZLl36uuUpcZmP2V6pLn_krKMVxLzl-tiBQkPrPuzVV8=.a9773fe5-c856-4390-a075-5e01184c095b@github.com>
Message-ID: <JAW7wzcLAxHk_wFW9KnVaCU0Oq5hKKNBAYPHETaZJCc=.1aaac54d-f748-42bf-bfb6-40fc0c9eaf23@github.com>

On Thu, 26 Nov 2020 04:49:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Here is a fix for one of the annoying bug, which causes random test failures in the CI.
>> 
>> We have a method Robot.waitForIdle(), which supposed to wait until the java and the native queue stabilized. The common use case is to click on the button or show the window, and call waitForIdle() which will wait until the native event will be dispatched by the X11/Windows/macOS as well as followed Java event(paint/focus/etc event) will be dispatched to the EDT.
>> 
>> Currently, it is implemented in this way:
>>   1. Flush the EventQueue, so all old events will be posted to EDT.
>>   2. Flush the native event queue, by posting the native event.
>>   3. Flush the EDT, by posting a java event.
>>   4. If some events(unrelated to waitForIdle machinery) were dispatched on steps 2. or 3. then repeat since step 1.
>> 
>> It is implemented that they because the native events caused by the OS usually generate the java events, and the java events may generate native events. So we have to wait for both queues (java/native).
>> 
>> But it has the next disadvantages:
>>  - It is implemented as a busy loop, which does not give a chance for the application to proceed further since it blocks 3 threads EDT/native toolkit thread like appkit/main thread.
>> - It throws the InfiniteLoop exception if the number of attempts is bigger than 20. And this limitation is too small because some tests generate much more events during startup.
>>  - Note that the timeout value for the realSync method is 10 seconds, and it was assumed that this method will not be executed longer, but it uses this timeout for all events flushing which can lead up to 600 seconds (20 iters * 3  calls * 10 seconds).
>> 
>> 
>> The fix:
>>  - Add a small delay to the method, so the app can do something useful when waitForIdle() is called
>>  - The timeout=10 second is taken care of, we calculate the "end" time and exits if it is exceeded
>>  - The maximum number of attempts is increased to 100 and InfiniteLoop is removed.
>> 
>> Note that I have made one additional change to the new realSync implementation. At the beginning of the method I call:
>>  EventQueue.invokeAndWait(() -> {/*dummy implementation*/});
>> It is needed to be sure that we flush the first event on EDT even if we spend more time than 10 seconds.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/awt/Robot/InfiniteLoopException.java

test/jdk/java/awt/Robot/InfiniteLoopException.java line 63:

> 61:         long time = TimeUnit.NANOSECONDS.toSeconds(System.nanoTime() - start);
> 62:         if (time > 20) {
> 63:             throw new RuntimeException("To slow:" + time);

Suggestion:

            throw new RuntimeException("Too slow:" + time);

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

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

From serb at openjdk.java.net  Thu Nov 26 04:52:19 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Nov 2020 04:52:19 GMT
Subject: <AWT Dev> RFR: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails [v2]
In-Reply-To: <-3MWzl2XJ7KjbSdtS3LZpz4mqE2hG4MLa5iL8XnDQLE=.1951234f-6a8c-4414-849b-c0f53ac52c16@github.com>
References: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
 <-3MWzl2XJ7KjbSdtS3LZpz4mqE2hG4MLa5iL8XnDQLE=.1951234f-6a8c-4414-849b-c0f53ac52c16@github.com>
Message-ID: <531EebiGo8bJfvHe3ZrVadlO_nmVpLLi-f_j4y7FOL4=.6cc2a9be-02cd-44ad-956e-cae80209031e@github.com>

On Wed, 25 Nov 2020 17:49:22 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/java/awt/Robot/InfiniteLoopException.java
>
> test/jdk/java/awt/Robot/InfiniteLoopException.java line 63:
> 
>> 61:         long time = TimeUnit.NANOSECONDS.toSeconds(System.nanoTime() - start);
>> 62:         if (time > 20) {
>> 63:             throw new RuntimeException("To slow:" + time);
> 
> Typo? Shouldn't it be "Too slow"?

yes, fixed.

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

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

From kizune at openjdk.java.net  Thu Nov 26 05:35:01 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 26 Nov 2020 05:35:01 GMT
Subject: <AWT Dev> RFR: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails [v2]
In-Reply-To: <ZLl36uuUpcZmP2V6pLn_krKMVxLzl-tiBQkPrPuzVV8=.a9773fe5-c856-4390-a075-5e01184c095b@github.com>
References: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
 <ZLl36uuUpcZmP2V6pLn_krKMVxLzl-tiBQkPrPuzVV8=.a9773fe5-c856-4390-a075-5e01184c095b@github.com>
Message-ID: <H_2K68r66MokY4SuMyZJ5xirmBS6wx4Cvsw2jIgWCZA=.da1f32fd-0f6f-4e07-af92-896848dd7d61@github.com>

On Thu, 26 Nov 2020 04:52:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Here is a fix for one of the annoying bug, which causes random test failures in the CI.
>> 
>> We have a method Robot.waitForIdle(), which supposed to wait until the java and the native queue stabilized. The common use case is to click on the button or show the window, and call waitForIdle() which will wait until the native event will be dispatched by the X11/Windows/macOS as well as followed Java event(paint/focus/etc event) will be dispatched to the EDT.
>> 
>> Currently, it is implemented in this way:
>>   1. Flush the EventQueue, so all old events will be posted to EDT.
>>   2. Flush the native event queue, by posting the native event.
>>   3. Flush the EDT, by posting a java event.
>>   4. If some events(unrelated to waitForIdle machinery) were dispatched on steps 2. or 3. then repeat since step 1.
>> 
>> It is implemented that they because the native events caused by the OS usually generate the java events, and the java events may generate native events. So we have to wait for both queues (java/native).
>> 
>> But it has the next disadvantages:
>>  - It is implemented as a busy loop, which does not give a chance for the application to proceed further since it blocks 3 threads EDT/native toolkit thread like appkit/main thread.
>> - It throws the InfiniteLoop exception if the number of attempts is bigger than 20. And this limitation is too small because some tests generate much more events during startup.
>>  - Note that the timeout value for the realSync method is 10 seconds, and it was assumed that this method will not be executed longer, but it uses this timeout for all events flushing which can lead up to 600 seconds (20 iters * 3  calls * 10 seconds).
>> 
>> 
>> The fix:
>>  - Add a small delay to the method, so the app can do something useful when waitForIdle() is called
>>  - The timeout=10 second is taken care of, we calculate the "end" time and exits if it is exceeded
>>  - The maximum number of attempts is increased to 100 and InfiniteLoop is removed.
>> 
>> Note that I have made one additional change to the new realSync implementation. At the beginning of the method I call:
>>  EventQueue.invokeAndWait(() -> {/*dummy implementation*/});
>> It is needed to be sure that we flush the first event on EDT even if we spend more time than 10 seconds.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/awt/Robot/InfiniteLoopException.java

Marked as reviewed by kizune (Reviewer).

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

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

From peterz at openjdk.java.net  Thu Nov 26 08:01:55 2020
From: peterz at openjdk.java.net (Peter Zhelezniakov)
Date: Thu, 26 Nov 2020 08:01:55 GMT
Subject: <AWT Dev> RFR: 8252015: [macos11] java.awt.TrayIcon requires
 updates for template images
In-Reply-To: <PiEff3tWAloIkoWxqYyI4tLfDfB8nVRbRsuJbdCZiD4=.f5ad2da7-8cbe-4898-a474-99eb47676983@github.com>
References: <CXsVH80C0Bo7annVHdBWxfL5oSBWXyXVslcJ8VrZKzQ=.2e2b46af-0cc2-4767-865c-853e82f38a60@github.com>
 <PgvPQpyrGLGQ7qKVO8nCMOrU-uV7hlQBtTQ-GQZcY64=.b35979d4-1ffd-4099-a232-ee1327919409@github.com>
 <PiEff3tWAloIkoWxqYyI4tLfDfB8nVRbRsuJbdCZiD4=.f5ad2da7-8cbe-4898-a474-99eb47676983@github.com>
Message-ID: <fqWa_fkpHDNEsScZdLHgJvTWraytgbMJbV87sHFsevk=.cc7e11e8-4126-47f2-a270-ad86c808ffe3@github.com>

On Tue, 6 Oct 2020 08:19:25 GMT, Peter Zhelezniakov <peterz at openjdk.org> wrote:

>> Hi, Peter. You are welcome!
>> Just an initial question about the template images, can you please provide some steps to reproduce this bug and so it will be possible to check that the fix solves it.
>
> Hi Sergey, and thanks for looking into this!
> 
> Try the attached jar, it's a modified version of TrayIconDemo using a template icon taken from Wikimedia Commons. Without the fix, or without `-Dsun.awt.enableTemplateImages`, the icon disappears if you switch to Dark theme. With the fix and the property set, the system repaints it in white.
> 
> [TrayIconDemo.jar.zip](https://github.com/openjdk/jdk/files/5332241/TrayIconDemo.jar.zip)

Filed [CSR request](https://bugs.openjdk.java.net/browse/JDK-8255597)

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

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

From serb at openjdk.java.net  Thu Nov 26 08:48:02 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Nov 2020 08:48:02 GMT
Subject: <AWT Dev> Integrated: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails
In-Reply-To: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
References: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
Message-ID: <MNkg0tKd0qpLOVlqJ-Y2z4YQl5xAlMrmmQbOSGMe0Qg=.4ba7702d-f94d-45b3-b0ec-74490395bb2c@github.com>

On Wed, 25 Nov 2020 00:15:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Here is a fix for one of the annoying bug, which causes random test failures in the CI.
> 
> We have a method Robot.waitForIdle(), which supposed to wait until the java and the native queue stabilized. The common use case is to click on the button or show the window, and call waitForIdle() which will wait until the native event will be dispatched by the X11/Windows/macOS as well as followed Java event(paint/focus/etc event) will be dispatched to the EDT.
> 
> Currently, it is implemented in this way:
>   1. Flush the EventQueue, so all old events will be posted to EDT.
>   2. Flush the native event queue, by posting the native event.
>   3. Flush the EDT, by posting a java event.
>   4. If some events(unrelated to waitForIdle machinery) were dispatched on steps 2. or 3. then repeat since step 1.
> 
> It is implemented that they because the native events caused by the OS usually generate the java events, and the java events may generate native events. So we have to wait for both queues (java/native).
> 
> But it has the next disadvantages:
>  - It is implemented as a busy loop, which does not give a chance for the application to proceed further since it blocks 3 threads EDT/native toolkit thread like appkit/main thread.
> - It throws the InfiniteLoop exception if the number of attempts is bigger than 20. And this limitation is too small because some tests generate much more events during startup.
>  - Note that the timeout value for the realSync method is 10 seconds, and it was assumed that this method will not be executed longer, but it uses this timeout for all events flushing which can lead up to 600 seconds (20 iters * 3  calls * 10 seconds).
> 
> 
> The fix:
>  - Add a small delay to the method, so the app can do something useful when waitForIdle() is called
>  - The timeout=10 second is taken care of, we calculate the "end" time and exits if it is exceeded
>  - The maximum number of attempts is increased to 100 and InfiniteLoop is removed.
> 
> Note that I have made one additional change to the new realSync implementation. At the beginning of the method I call:
>  EventQueue.invokeAndWait(() -> {/*dummy implementation*/});
> It is needed to be sure that we flush the first event on EDT even if we spend more time than 10 seconds.

This pull request has now been integrated.

Changeset: 973255c4
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/973255c4
Stats:     242 lines in 9 files changed: 192 ins; 20 del; 30 mod

8196100: javax/swing/text/JTextComponent/5074573/bug5074573.java fails

Reviewed-by: kizune

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

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

From vkempik at openjdk.java.net  Thu Nov 26 09:33:03 2020
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Thu, 26 Nov 2020 09:33:03 GMT
Subject: <AWT Dev> RFR: 8257148: Remove obsolete code in AWTView.m
Message-ID: <1KFUgoKLT2YMc-3sii-UJn2Bbq8MBh19ziGk58IHF5Q=.03bb8897-e928-4c65-b2d9-e4ec0a23b0c3@github.com>

8257148: Remove obsolete code in AWTView.m

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

Commit messages:
 - 8257148: Remove obsolete code in AWTView.m

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

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

From vkempik at openjdk.java.net  Thu Nov 26 09:33:03 2020
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Thu, 26 Nov 2020 09:33:03 GMT
Subject: <AWT Dev> RFR: 8257148: Remove obsolete code in AWTView.m
In-Reply-To: <1KFUgoKLT2YMc-3sii-UJn2Bbq8MBh19ziGk58IHF5Q=.03bb8897-e928-4c65-b2d9-e4ec0a23b0c3@github.com>
References: <1KFUgoKLT2YMc-3sii-UJn2Bbq8MBh19ziGk58IHF5Q=.03bb8897-e928-4c65-b2d9-e4ec0a23b0c3@github.com>
Message-ID: <Yjv-qT6H9j6uDaNTB3brczF5SdeykyLXX3xcBJbBqgc=.14d7c968-d992-44c9-a097-00cc1d07243b@github.com>

On Thu, 26 Nov 2020 09:27:58 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> 8257148: Remove obsolete code in AWTView.m

Hello
Please review this fix for jdk-8257148
The AWTView.m has some checks for very old version of macos unsupported by openjdk.

also the code in OSVersion.m uses system's API which are intel-only in macos big sur.

Removing this cleans up JDK.

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

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

From serb at openjdk.java.net  Sat Nov 28 20:09:54 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 28 Nov 2020 20:09:54 GMT
Subject: <AWT Dev> RFR: 8256264: Printed GlyphVector outline with low
 DPI has bad quality on Windows
In-Reply-To: <OQb2sicw9j00AWw_SD-MHP_0MRS97F08M3Rep1xCHrg=.e4e598ca-0354-4b36-b954-75aed241ad08@github.com>
References: <iA4R8RQHqStufCJRG2qB5tJODvX-mIlqv392YbdNE84=.5bfe5fa6-6062-45ec-aebd-d193cf8b76c6@github.com>
 <a4IkTW6qwFnlbnrq-SMzkaDuAOLCrescYF4ts0mV9-Q=.fd7c6323-6561-4897-932d-4d8e6392ff8e@github.com>
 <OQb2sicw9j00AWw_SD-MHP_0MRS97F08M3Rep1xCHrg=.e4e598ca-0354-4b36-b954-75aed241ad08@github.com>
Message-ID: <EPXV17v8uTi9KWKeX4Qx8LEsXIaaMDmsa0ZfFWhbjto=.9aa89f09-a903-4dc6-9efe-0d2cfcebb210@github.com>

On Fri, 20 Nov 2020 20:23:23 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> I removed the `sun.java2d.print.enablePathPrecisionScale` property from the fix.

You forgot to delete it from the test.

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

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

From serb at openjdk.java.net  Sun Nov 29 08:18:03 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 29 Nov 2020 08:18:03 GMT
Subject: <AWT Dev> RFR: 8257148: Remove obsolete code in AWTView.m
In-Reply-To: <1KFUgoKLT2YMc-3sii-UJn2Bbq8MBh19ziGk58IHF5Q=.03bb8897-e928-4c65-b2d9-e4ec0a23b0c3@github.com>
References: <1KFUgoKLT2YMc-3sii-UJn2Bbq8MBh19ziGk58IHF5Q=.03bb8897-e928-4c65-b2d9-e4ec0a23b0c3@github.com>
Message-ID: <nQqkbN9OBTu9XkIKfeeBMVeie_WBo_sGzZea3Wc7Jw0=.11908acd-7e49-48bb-8d38-31a9f6ec4d30@github.com>

On Thu, 26 Nov 2020 09:27:58 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> 8257148: Remove obsolete code in AWTView.m

Marked as reviewed by serb (Reviewer).

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

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

From vkempik at openjdk.java.net  Sun Nov 29 08:20:56 2020
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Sun, 29 Nov 2020 08:20:56 GMT
Subject: <AWT Dev> Integrated: 8257148: Remove obsolete code in AWTView.m
In-Reply-To: <1KFUgoKLT2YMc-3sii-UJn2Bbq8MBh19ziGk58IHF5Q=.03bb8897-e928-4c65-b2d9-e4ec0a23b0c3@github.com>
References: <1KFUgoKLT2YMc-3sii-UJn2Bbq8MBh19ziGk58IHF5Q=.03bb8897-e928-4c65-b2d9-e4ec0a23b0c3@github.com>
Message-ID: <RIMqgaOZLSm7e2pgSpwxnUeia51gOBcAjLFcILhQz9o=.6bbc989e-2c8f-4bff-9e48-ff4ee5b7e9f9@github.com>

On Thu, 26 Nov 2020 09:27:58 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> 8257148: Remove obsolete code in AWTView.m

This pull request has now been integrated.

Changeset: c2af27be
Author:    Vladimir Kempik <vkempik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c2af27be
Stats:     95 lines in 3 files changed: 0 ins; 94 del; 1 mod

8257148: Remove obsolete code in AWTView.m

Reviewed-by: serb

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

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

From serb at openjdk.java.net  Mon Nov 30 01:25:59 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Nov 2020 01:25:59 GMT
Subject: <AWT Dev> RFR: 8252015: [macos11] java.awt.TrayIcon requires
 updates for template images
In-Reply-To: <CXsVH80C0Bo7annVHdBWxfL5oSBWXyXVslcJ8VrZKzQ=.2e2b46af-0cc2-4767-865c-853e82f38a60@github.com>
References: <CXsVH80C0Bo7annVHdBWxfL5oSBWXyXVslcJ8VrZKzQ=.2e2b46af-0cc2-4767-865c-853e82f38a60@github.com>
Message-ID: <TDEdju2RtchZPX0RwrnCZVs9wU6TxsrhU7aMkosCjMc=.fc532691-f95f-4717-b66d-b57926da014e@github.com>

On Fri, 2 Oct 2020 11:08:23 GMT, Peter Zhelezniakov <peterz at openjdk.org> wrote:

> [JDK-8252015: [macos11] java.awt.TrayIcon requires updates for template images](https://bugs.openjdk.java.net/browse/JDK-8252015)
> 
> ### Problem
> According to Apple's human interface guidelines, developers should use template images for tray icons. This way icons look good when desktop theme or wallpaper change. On the API level, this means setting the `NSImage::isTemplate` flag. Currently there's no way in Java to set this flag. Even if one uses a template (black and transparent pixels only) image, MacOS will treat it as regular image. As a result, the image will not be visible when using dark theme.
> 
> ### Solution:
> * Add a new system property, `java.awt.enableTemplateImages`, to indicate that template images are being used by tray icons.When this property is set, all tray icon images are treated as templates. It's the developers' responsibility to ensure their images are indeed templates. This property allows us to avoid new API and accidental behavior changes
> * Value of this property is passed from Java into `NSImage::setTemplate`
> * We need the tray icon image rendered by MacOS, so we use a button (rather than a view) to host the image
> 
> To do after CSR approval:
> - [ ] Rename property `java.awt.`
> - [ ] Add `TrayIcon` javadoc, use `@systemProperty` tag there

src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.m line 99:

> 97: 
> 98:     // Its a bad idea to force the item to release our view by setting
> 99:     // the item's view to nil: it can lead to a crash in some scenarios.

This comment seems outdated, we either need to nullify the menu delegate or follow the old approach and update the comment on why the menuDelegate is not set to nil.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CTrayIcon.java line 197:

> 195: 
> 196:     void updateNativeImage(Image image) {
> 197:         boolean imageTemplate = Boolean.parseBoolean(System.getProperty("sun.awt.enableTemplateImages", "false"));

"sun.awt.enableTemplateImages" -> "apple.awt.enableTemplateImages"

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

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

From serb at openjdk.java.net  Mon Nov 30 01:26:01 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Nov 2020 01:26:01 GMT
Subject: <AWT Dev> RFR: 8252015: [macos11] java.awt.TrayIcon requires
 updates for template images
In-Reply-To: <TDEdju2RtchZPX0RwrnCZVs9wU6TxsrhU7aMkosCjMc=.fc532691-f95f-4717-b66d-b57926da014e@github.com>
References: <CXsVH80C0Bo7annVHdBWxfL5oSBWXyXVslcJ8VrZKzQ=.2e2b46af-0cc2-4767-865c-853e82f38a60@github.com>
 <TDEdju2RtchZPX0RwrnCZVs9wU6TxsrhU7aMkosCjMc=.fc532691-f95f-4717-b66d-b57926da014e@github.com>
Message-ID: <RW2_Qs0bGlCf9BDeHrZdITRQx0IsUbEVQBqaG3NgFPo=.f31f32f0-92ea-491d-8adb-20a7835e649e@github.com>

On Mon, 30 Nov 2020 01:16:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> [JDK-8252015: [macos11] java.awt.TrayIcon requires updates for template images](https://bugs.openjdk.java.net/browse/JDK-8252015)
>> 
>> ### Problem
>> According to Apple's human interface guidelines, developers should use template images for tray icons. This way icons look good when desktop theme or wallpaper change. On the API level, this means setting the `NSImage::isTemplate` flag. Currently there's no way in Java to set this flag. Even if one uses a template (black and transparent pixels only) image, MacOS will treat it as regular image. As a result, the image will not be visible when using dark theme.
>> 
>> ### Solution:
>> * Add a new system property, `java.awt.enableTemplateImages`, to indicate that template images are being used by tray icons.When this property is set, all tray icon images are treated as templates. It's the developers' responsibility to ensure their images are indeed templates. This property allows us to avoid new API and accidental behavior changes
>> * Value of this property is passed from Java into `NSImage::setTemplate`
>> * We need the tray icon image rendered by MacOS, so we use a button (rather than a view) to host the image
>> 
>> To do after CSR approval:
>> - [ ] Rename property `java.awt.`
>> - [ ] Add `TrayIcon` javadoc, use `@systemProperty` tag there
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CTrayIcon.java line 197:
> 
>> 195: 
>> 196:     void updateNativeImage(Image image) {
>> 197:         boolean imageTemplate = Boolean.parseBoolean(System.getProperty("sun.awt.enableTemplateImages", "false"));
> 
> "sun.awt.enableTemplateImages" -> "apple.awt.enableTemplateImages"

The impl block in the java.awt.TrayIcon class?

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

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

From serb at openjdk.java.net  Mon Nov 30 03:43:54 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Nov 2020 03:43:54 GMT
Subject: <AWT Dev> RFR: 8005970: Mouse cursor is default cursor over
 TextArea's scrollbar
In-Reply-To: <cpDDsxj4qZrErgEhiwmYsuAhK68LYDp_Jqe7D2nwVs4=.db196b42-3cc3-485a-973d-2748021e7134@github.com>
References: <cpDDsxj4qZrErgEhiwmYsuAhK68LYDp_Jqe7D2nwVs4=.db196b42-3cc3-485a-973d-2748021e7134@github.com>
Message-ID: <12Of1mcu63kgOwAHEcEPIR-jr541qwriG13GNJxFmKc=.0c8e7a82-c8fb-4c07-864c-378286a2f424@github.com>

On Tue, 27 Oct 2020 21:58:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In jdk7 the next bug was fixed: https://bugs.openjdk.java.net/browse/JDK-6431076
> That bug was about text cursor over the scroll bar in XAWT, and it was fixed by using default(arrow cursor) over scrollbar.
> 
> For that bug two tests were created:
>  1. The test which verified that default cursor is used over scrollbar in the TextArea
>  2. The test which verified that non-default cursor is used over scrollbar in the TextArea if the non-default cursor is set for the parent frame.
> 
> Note that the first test verified the actual bug, but the second test check some implementations detail of XAWT.
> The second test never passed on Windows, and on macOS.
> 
> I propose to delete the second test, as it does not test something specific, but check some xawt quirk. The first test is enough.

Any volunteers for a review?

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

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

From serb at openjdk.java.net  Mon Nov 30 03:43:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Nov 2020 03:43:57 GMT
Subject: <AWT Dev> RFR: 8213126:
 java/awt/Window/MainKeyWindow/TestMainKeyWindow.java time-out on mac10.13
In-Reply-To: <TyRZM4jQYhhJU17YaHiHv-S2l4EN0owHtDFi7thG47M=.891b686e-13c2-451c-8d7e-a9b3ba5268c3@github.com>
References: <TyRZM4jQYhhJU17YaHiHv-S2l4EN0owHtDFi7thG47M=.891b686e-13c2-451c-8d7e-a9b3ba5268c3@github.com>
Message-ID: <1335Y6yHsHBIlSaWVa5GwTyuW8Pd-sN8LBrsrPWUs_w=.32417db9-e024-49a5-af38-11e0868e0a06@github.com>

On Thu, 29 Oct 2020 18:42:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Initially, this bug was filed because the test was run via jtreg without passing '-nativepath' option(the make file pass this option automatically). So we could just de-problem list the test, but on the macOS Catalina the "System Preferences.app" was moved so the test cannot run it. As a fix, I suggest running the java app via a separate process instead of "System Preferences.app".
> 
> The test still fails before JDK-8194327, and passed after.

Any volunteers for a review?

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

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

From serb at openjdk.java.net  Mon Nov 30 03:43:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Nov 2020 03:43:57 GMT
Subject: <AWT Dev> RFR: 7194219:
 java/awt/Component/UpdatingBootTime/UpdatingBootTime.html fails on Linux
In-Reply-To: <1puLRaS3bbjpiliy6h0OD3EDboP3pkFlfMUj7wrXfjw=.77372c28-e6a0-49a5-bfe3-863858f47392@github.com>
References: <1puLRaS3bbjpiliy6h0OD3EDboP3pkFlfMUj7wrXfjw=.77372c28-e6a0-49a5-bfe3-863858f47392@github.com>
Message-ID: <DQgX1_2eUtNOCamUvhHKcC0gHnNC1G-JAmU_Lme-vww=.b3375672-ea89-4dca-8294-a22985b2e1f0@github.com>

On Thu, 29 Oct 2020 08:41:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The test checks that the timestamp of the mouse event accurately represents the current time of the system, even if the time of the system is jumped to the past/future.
> 
> On Unix in xawt we calculate the timstamp using this method:
> reset_time_utc = System.currentTimeMillis() - getCurrentServerTime();
> timstamp = reset_time_utc + server_offset;
> 
> (1.) Note that the "server_offset" - timstamp when the native event was generated, and we try to convert it to the UTC timestamp. Unfortunatly we callculate the "reset_time_utc" only once at the start of the application and then rarely update it. So if the time in the system is changed we still use the old one.
> 
> The exactly the same bug described at (1.) was fixed on windows by the https://bugs.openjdk.java.net/browse/JDK-6461933 and for that bug the test in question was created. That bug was fixed by the "recalculation" system time more often. But it does not solve the general time issue and the code was reworked again by the https://bugs.openjdk.java.net/browse/JDK-8046495
> 
> I would like to fix the current bug in the same was as on windows, see link below:
> https://bugs.openjdk.java.net/browse/JDK-8046495?focusedCommentId=13517205&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13517205
> 
> After the fix we will use the same System.currentTimeMillis()/JVM_CurrentTimeMillis on all platforms.

Any volunteers for a review?

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

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

From serb at openjdk.java.net  Mon Nov 30 03:44:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Nov 2020 03:44:57 GMT
Subject: <AWT Dev> RFR: 8225116: Test OwnedWindowsLeak.java
 intermittently fails
In-Reply-To: <qPlC_DmjwuVspEaqf4DZPkmB_3Tb6sRoZ53I_V6CcXU=.0dcc1c31-22cb-4f72-8686-42886fb4d733@github.com>
References: <qPlC_DmjwuVspEaqf4DZPkmB_3Tb6sRoZ53I_V6CcXU=.0dcc1c31-22cb-4f72-8686-42886fb4d733@github.com>
Message-ID: <SK_6NWMUfoogF4m_gU51z1tElMW4U6FNNrpDS2F97AY=.aff75964-6c70-4644-8910-e44eacea6347@github.com>

On Sat, 7 Nov 2020 06:55:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This test rarely fails in the past on some configurations but was never a problem listed, and according to the history of CI, it fails 2 times on its own this year.
> 
> There are two possible reasons for the failure:
> 1. At that time we had a memory leak, which was fixed.
> 2. The test works too fast and it was not enough time for GC to eliminate 1000 windows.
> 
> To make the future evaluation simpler I enhanced the test and make it stricter, see some comments inline.

Any volunteers for a review?

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

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

From serb at openjdk.java.net  Mon Nov 30 03:44:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Nov 2020 03:44:57 GMT
Subject: <AWT Dev> RFR: 6278172: TextComponent.getSelectedText() throws
 StringIndexOutOfBoundsException
In-Reply-To: <5vcukZV00bZ1bAzji0LuUn5sTYIEVCyz3OzEOLeOMpM=.000ffc24-3aa7-481c-b7c8-3105867474e3@github.com>
References: <5vcukZV00bZ1bAzji0LuUn5sTYIEVCyz3OzEOLeOMpM=.000ffc24-3aa7-481c-b7c8-3105867474e3@github.com>
Message-ID: <ZDl-qlKa_bxOcsG49vN2I7KZJsA43aPGW9XXwIkRjec=.6ee78831-ec6e-4e91-8528-eb692ba78f5c@github.com>

On Sat, 7 Nov 2020 00:14:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The text components are implements as wrappers over the "native" peers. Most of the functionality is provided by the peers not wrappers like TextArea/TextField. The current bug occurs in the TextArea/TextField when the native peer was created yet.
> 
> The steps to reproduce:
>  1. Sets the long text to the component
>  2. Select all text in the component
>  3. Sets the short text to the component
>  4. Request the selected text -> BOOM
> 
> The bug on step 4 occurred because we request a long substring of the short text. To eliminate an exception we have two choices:
>  1. Preserve the selection in the setText(), but limit it by the length of the current text.
>  2. Resets the selection.
> 
> I tried both solutions, the second caused some TCK tests to fail, so I selected the first one.

Any volunteers for a review?

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

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

From serb at openjdk.java.net  Mon Nov 30 03:45:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Nov 2020 03:45:55 GMT
Subject: <AWT Dev> RFR: 8256373: [Windows/HiDPI] The Frame#setBounds
 does not work in a minimized state
In-Reply-To: <j-UBUx8hbgmB7nLdvluh2lOCM9nyhpx6HFnUXBlSX_w=.aae27117-68e8-4eae-b607-39bf188606c0@github.com>
References: <rnMuc8fXGxVXCbogchpWBX_95FZkt1NrSC52QfdfhwU=.4473141b-66d1-4f0a-aa3a-6d4b9e4f575c@github.com>
 <HhvXU9p6AI9S3wfbMqG1TnpLsGtzPSWXvqgkUs5EwlY=.3b733147-1a61-40d1-a215-1ccda77bc48f@github.com>
 <j-UBUx8hbgmB7nLdvluh2lOCM9nyhpx6HFnUXBlSX_w=.aae27117-68e8-4eae-b607-39bf188606c0@github.com>
Message-ID: <qRMQc46SJ_HjhmaiT3ADr2uKKeJSEfb0p1mOO-Q8W2A=.12b29792-ced9-4983-a3b0-28e59acd3dd0@github.com>

On Wed, 18 Nov 2020 18:13:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Quick question: is there any way to manually reproduce this problem or it is only possible programmatically? How can you move iconified window to another display without de-iconifying it?
>
>> Quick question: is there any way to manually reproduce this problem or it is only possible programmatically? How can you move iconified window to another display without de-iconifying it?
> 
> To reproduce the bug it is necessary to call setBounds method while the window is iconified - actually replacing its normal state bounds. So when the frame will de-iconifying(become normal) it appeared on the new bounds.

Any volunteers for a review?

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

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

From serb at openjdk.java.net  Mon Nov 30 04:55:00 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Nov 2020 04:55:00 GMT
Subject: <AWT Dev> RFR: 8252015: [macos11] java.awt.TrayIcon requires
 updates for template images
In-Reply-To: <fqWa_fkpHDNEsScZdLHgJvTWraytgbMJbV87sHFsevk=.cc7e11e8-4126-47f2-a270-ad86c808ffe3@github.com>
References: <CXsVH80C0Bo7annVHdBWxfL5oSBWXyXVslcJ8VrZKzQ=.2e2b46af-0cc2-4767-865c-853e82f38a60@github.com>
 <PgvPQpyrGLGQ7qKVO8nCMOrU-uV7hlQBtTQ-GQZcY64=.b35979d4-1ffd-4099-a232-ee1327919409@github.com>
 <PiEff3tWAloIkoWxqYyI4tLfDfB8nVRbRsuJbdCZiD4=.f5ad2da7-8cbe-4898-a474-99eb47676983@github.com>
 <fqWa_fkpHDNEsScZdLHgJvTWraytgbMJbV87sHFsevk=.cc7e11e8-4126-47f2-a270-ad86c808ffe3@github.com>
Message-ID: <wSKwhr5RSPY3gO-fp37T0i14Ye9UJmNlfjRNRMUztUs=.efc05cd4-e430-43e5-8d99-e81aa1654313@github.com>

On Thu, 26 Nov 2020 07:58:59 GMT, Peter Zhelezniakov <peterz at openjdk.org> wrote:

>> Hi Sergey, and thanks for looking into this!
>> 
>> Try the attached jar, it's a modified version of TrayIconDemo using a template icon taken from Wikimedia Commons. Without the fix, or without `-Dsun.awt.enableTemplateImages`, the icon disappears if you switch to Dark theme. With the fix and the property set, the system repaints it in white.
>> 
>> [TrayIconDemo.jar.zip](https://github.com/openjdk/jdk/files/5332241/TrayIconDemo.jar.zip)
>
> Filed [CSR request](https://bugs.openjdk.java.net/browse/JDK-8255597)

Please check the tests in the .../test/jdk/java/awt/TrayIcon/ folder it looks like some of them fail after the fix:
java/awt/TrayIcon/ActionCommand/ActionCommand.java 
java/awt/TrayIcon/ActionEventMask/ActionEventMask.java 
java/awt/TrayIcon/MouseEventMask/MouseEventMaskTest.java 
java/awt/TrayIcon/SecurityCheck/FunctionalityCheck/FunctionalityCheck.java 
java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java 
java/awt/TrayIcon/TrayIconEvents/TrayIconEventsTest.java 
java/awt/TrayIcon/TrayIconMouseTest/TrayIconMouseTest.java 
java/awt/TrayIcon/TrayIconPopup/TrayIconPopupTest.java

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

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

From alexsch at openjdk.java.net  Mon Nov 30 10:00:17 2020
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Mon, 30 Nov 2020 10:00:17 GMT
Subject: <AWT Dev> RFR: 8256264: Printed GlyphVector outline with low
 DPI has bad quality on Windows [v3]
In-Reply-To: <iA4R8RQHqStufCJRG2qB5tJODvX-mIlqv392YbdNE84=.5bfe5fa6-6062-45ec-aebd-d193cf8b76c6@github.com>
References: <iA4R8RQHqStufCJRG2qB5tJODvX-mIlqv392YbdNE84=.5bfe5fa6-6062-45ec-aebd-d193cf8b76c6@github.com>
Message-ID: <RuypdUxdhpGKNpSzorEcpPjRWwL6mzp2k5QA-0sEa2I=.3641d376-4342-4b39-8423-cedf4b7d330e@github.com>

> Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows.
> The GDI system used for text printing on Windows accepts only integer path coordinates.
> Rounding GlyphVector outline coordinates leads to distorted printed text.
> 
> To reproduce the issue run the [PrintGlyphVectorOutlineSample](https://bugs.openjdk.java.net/secure/attachment/91398/PrintGlyphVectorOutlineSample.java)  file on Windows and select a low DPI
> printer in the printer dialog. The sample prints two lines, one using Graphics drawString() method and another by
> filling GlyphVector outline. Chars on the second line are distorted.
> 
> It is also possible to reproduce the issue running the sample and printing the text to PDF: [fill-glyph-vector-outline.png](https://bugs.openjdk.java.net/secure/attachment/91397/fill-glyph-vector-outline.png)
> 
> The proposed fix introduce "sun.java2d.print.enablePathPrecisionScale" property which being enabled
> scales the GDI WorldTransform down and GlyphVector outline coordinates up.
> This allows to keep some digits after a dot from being rounded.
> The value for scaling is chosen to be 1000 in the same way how it is used  by `String trunc(float f)` method from PSPrinterJob class on Linux:
> https://github.com/openjdk/jdk/blob/ed615e3ca0d681e8e67cdbf1d5d964979ccd7888/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#L1489
> 
> See the  [fill-glyph-vector-outline-enable-path-scale-factor.png](https://bugs.openjdk.java.net/secure/attachment/91399/fill-glyph-vector-outline-enable-path-scale-factor.png) screenshot which shows how the GlyphVector outline is filled after the fix with the enabled "sun.java2d.print.enablePathPrecisionScale" option.
> 
> [fill-glyph-vector-outline-diff.png](https://bugs.openjdk.java.net/secure/attachment/91400/fill-glyph-vector-outline-diff.png) shows difference of GlyphVector outline printing before and after the fix.

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

  Remove Dsun.java2d.print.enablePathPrecisionScale property from the PathPrecisionScaleFactorTest

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1183/files
  - new: https://git.openjdk.java.net/jdk/pull/1183/files/f79b8014..b6885e5f

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

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

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

From alexsch at openjdk.java.net  Mon Nov 30 10:00:18 2020
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Mon, 30 Nov 2020 10:00:18 GMT
Subject: <AWT Dev> RFR: 8256264: Printed GlyphVector outline with low
 DPI has bad quality on Windows
In-Reply-To: <EPXV17v8uTi9KWKeX4Qx8LEsXIaaMDmsa0ZfFWhbjto=.9aa89f09-a903-4dc6-9efe-0d2cfcebb210@github.com>
References: <iA4R8RQHqStufCJRG2qB5tJODvX-mIlqv392YbdNE84=.5bfe5fa6-6062-45ec-aebd-d193cf8b76c6@github.com>
 <a4IkTW6qwFnlbnrq-SMzkaDuAOLCrescYF4ts0mV9-Q=.fd7c6323-6561-4897-932d-4d8e6392ff8e@github.com>
 <OQb2sicw9j00AWw_SD-MHP_0MRS97F08M3Rep1xCHrg=.e4e598ca-0354-4b36-b954-75aed241ad08@github.com>
 <EPXV17v8uTi9KWKeX4Qx8LEsXIaaMDmsa0ZfFWhbjto=.9aa89f09-a903-4dc6-9efe-0d2cfcebb210@github.com>
Message-ID: <bGlVe-iXoQvXyOQNmc-Rcob1azFgKFoF1cEUC_RwT7U=.909007dc-faa2-4c8d-8110-06a3c564685c@github.com>

On Sat, 28 Nov 2020 20:07:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I prepared a simple [print test](http://cr.openjdk.java.net/~alexsch/8256264/performance/PrintTextPerformanceTest.java) sample which uses 4 different fonts (plain and bold) with different sizes and prints 640 lines on 10 pages.
>> 
>> I run the sample with and without the fix to PDF and measured the time which is used by the  deviceFill() method (it both converts the shape to path and fills it):
>> https://github.com/openjdk/jdk/blob/b21b96df2162c72098afcdfd2cf243a55a0f17e1/src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java#L1489
>> 
>> The average time without the fix: 2.77s (min 2.74s, max 2,78)
>> The average time with the fix: 2.76s (min 2.74s, max 2.77)
>> 
>> I removed the `sun.java2d.print.enablePathPrecisionScale` property from the fix.
>
>> I removed the `sun.java2d.print.enablePathPrecisionScale` property from the fix.
> 
> You forgot to delete it from the test.

The `sun.java2d.print.enablePathPrecisionScale` property is removed from the PathPrecisionScaleFactorTest test.

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

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

From psadhukhan at openjdk.java.net  Mon Nov 30 13:30:05 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 30 Nov 2020 13:30:05 GMT
Subject: <AWT Dev> RFR: 8257242: [macOS] Java app crashes while switching
 input methods
Message-ID: <LtXiaRnj1po5iIODHDGZYhz4z_gzxZ2APpIXKc-jRoI=.c7594b49-7e7f-4632-b865-3dc845e43379@github.com>

It seems the patch for https://bugs.openjdk.java.net/browse/JDK-8248532 causes a crash, as it attempts to call a method selector on a class for an instance method (- keyboardInputSourceChanged). It was not observed in 10.14 but seen in 10.15 or later.
It resulted in crash as we are passing [AWTView class] as an instance to the notification observer but notification function keyboardInputSourceChanged is not a member function.
Modified the code to make that function a class-level function so that it does not crash.
mucommander.app, JDK-8214578 testcase worked with this change.

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

Commit messages:
 - 8257242: [macOS] Java app crashes while switching input methods

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

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

From serb at openjdk.java.net  Mon Nov 30 17:07:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Nov 2020 17:07:57 GMT
Subject: <AWT Dev> RFR: 8257242: [macOS] Java app crashes while
 switching input methods
In-Reply-To: <LtXiaRnj1po5iIODHDGZYhz4z_gzxZ2APpIXKc-jRoI=.c7594b49-7e7f-4632-b865-3dc845e43379@github.com>
References: <LtXiaRnj1po5iIODHDGZYhz4z_gzxZ2APpIXKc-jRoI=.c7594b49-7e7f-4632-b865-3dc845e43379@github.com>
Message-ID: <Kox_8OyhA3qZMfYg87_dy-PPNxVjlll1xJN-IM3X56I=.56f8266b-25f9-46ee-8a6b-151d31ecb3fe@github.com>

On Mon, 30 Nov 2020 13:23:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems the patch for https://bugs.openjdk.java.net/browse/JDK-8248532 causes a crash, as it attempts to call a method selector on a class for an instance method (- keyboardInputSourceChanged). It was not observed in 10.14 but seen in 10.15 or later.
> It resulted in crash as we are passing [AWTView class] as an instance to the notification observer but notification function keyboardInputSourceChanged is not a member function.
> Modified the code to make that function a class-level function so that it does not crash.
> mucommander.app, JDK-8214578 testcase worked with this change.

Do you have a chance to reproduce this crash?

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

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

From psadhukhan at openjdk.java.net  Mon Nov 30 17:12:57 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 30 Nov 2020 17:12:57 GMT
Subject: <AWT Dev> RFR: 8257242: [macOS] Java app crashes while
 switching input methods
In-Reply-To: <Kox_8OyhA3qZMfYg87_dy-PPNxVjlll1xJN-IM3X56I=.56f8266b-25f9-46ee-8a6b-151d31ecb3fe@github.com>
References: <LtXiaRnj1po5iIODHDGZYhz4z_gzxZ2APpIXKc-jRoI=.c7594b49-7e7f-4632-b865-3dc845e43379@github.com>
 <Kox_8OyhA3qZMfYg87_dy-PPNxVjlll1xJN-IM3X56I=.56f8266b-25f9-46ee-8a6b-151d31ecb3fe@github.com>
Message-ID: <ab9u9QS9nkZR5ayqSPTLyyGsZgax8hBn67UZe69GqIY=.28582751-2958-4429-b9b1-d796ecf42168@github.com>

On Mon, 30 Nov 2020 17:04:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> It seems the patch for https://bugs.openjdk.java.net/browse/JDK-8248532 causes a crash, as it attempts to call a method selector on a class for an instance method (- keyboardInputSourceChanged). It was not observed in 10.14 but seen in 10.15 or later.
>> It resulted in crash as we are passing [AWTView class] as an instance to the notification observer but notification function keyboardInputSourceChanged is not a member function.
>> Modified the code to make that function a class-level function so that it does not crash.
>> mucommander.app, JDK-8214578 testcase worked with this change.
>
> Do you have a chance to reproduce this crash?

No, but Alex did as he has Catalina and my patch solved his crash.

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

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

From serb at openjdk.java.net  Mon Nov 30 17:16:54 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Nov 2020 17:16:54 GMT
Subject: <AWT Dev> RFR: 8257242: [macOS] Java app crashes while
 switching input methods
In-Reply-To: <LtXiaRnj1po5iIODHDGZYhz4z_gzxZ2APpIXKc-jRoI=.c7594b49-7e7f-4632-b865-3dc845e43379@github.com>
References: <LtXiaRnj1po5iIODHDGZYhz4z_gzxZ2APpIXKc-jRoI=.c7594b49-7e7f-4632-b865-3dc845e43379@github.com>
Message-ID: <1H3hI3MbCqPyfB2-bYIqlcGR1tPaGsH6RCu3i5YHV7I=.d388c779-d877-4b53-99dd-bcfa94d66601@github.com>

On Mon, 30 Nov 2020 13:23:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems the patch for https://bugs.openjdk.java.net/browse/JDK-8248532 causes a crash, as it attempts to call a method selector on a class for an instance method (- keyboardInputSourceChanged). It was not observed in 10.14 but seen in 10.15 or later.
> It resulted in crash as we are passing [AWTView class] as an instance to the notification observer but notification function keyboardInputSourceChanged is not a member function.
> Modified the code to make that function a class-level function so that it does not crash.
> mucommander.app, JDK-8214578 testcase worked with this change.

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Mon Nov 30 17:21:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Nov 2020 17:21:58 GMT
Subject: <AWT Dev> RFR: 8256264: Printed GlyphVector outline with low
 DPI has bad quality on Windows [v3]
In-Reply-To: <RuypdUxdhpGKNpSzorEcpPjRWwL6mzp2k5QA-0sEa2I=.3641d376-4342-4b39-8423-cedf4b7d330e@github.com>
References: <iA4R8RQHqStufCJRG2qB5tJODvX-mIlqv392YbdNE84=.5bfe5fa6-6062-45ec-aebd-d193cf8b76c6@github.com>
 <RuypdUxdhpGKNpSzorEcpPjRWwL6mzp2k5QA-0sEa2I=.3641d376-4342-4b39-8423-cedf4b7d330e@github.com>
Message-ID: <GgwM84CPvOXx718puVzNV3okg_xcKqDk3lDY6gnOJDU=.3ad0d7ff-063c-4885-8311-62306aa6477d@github.com>

On Mon, 30 Nov 2020 10:00:17 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows.
>> The GDI system used for text printing on Windows accepts only integer path coordinates.
>> Rounding GlyphVector outline coordinates leads to distorted printed text.
>> 
>> To reproduce the issue run the [PrintGlyphVectorOutlineSample](https://bugs.openjdk.java.net/secure/attachment/91398/PrintGlyphVectorOutlineSample.java)  file on Windows and select a low DPI
>> printer in the printer dialog. The sample prints two lines, one using Graphics drawString() method and another by
>> filling GlyphVector outline. Chars on the second line are distorted.
>> 
>> It is also possible to reproduce the issue running the sample and printing the text to PDF: [fill-glyph-vector-outline.png](https://bugs.openjdk.java.net/secure/attachment/91397/fill-glyph-vector-outline.png)
>> 
>> The proposed fix introduce "sun.java2d.print.enablePathPrecisionScale" property which being enabled
>> scales the GDI WorldTransform down and GlyphVector outline coordinates up.
>> This allows to keep some digits after a dot from being rounded.
>> The value for scaling is chosen to be 1000 in the same way how it is used  by `String trunc(float f)` method from PSPrinterJob class on Linux:
>> https://github.com/openjdk/jdk/blob/ed615e3ca0d681e8e67cdbf1d5d964979ccd7888/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#L1489
>> 
>> See the  [fill-glyph-vector-outline-enable-path-scale-factor.png](https://bugs.openjdk.java.net/secure/attachment/91399/fill-glyph-vector-outline-enable-path-scale-factor.png) screenshot which shows how the GlyphVector outline is filled after the fix with the enabled "sun.java2d.print.enablePathPrecisionScale" option.
>> 
>> [fill-glyph-vector-outline-diff.png](https://bugs.openjdk.java.net/secure/attachment/91400/fill-glyph-vector-outline-diff.png) shows difference of GlyphVector outline printing before and after the fix.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove Dsun.java2d.print.enablePathPrecisionScale property from the PathPrecisionScaleFactorTest

Marked as reviewed by serb (Reviewer).

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Nov 30 17:45:04 2020
From: github.com+741251+turbanoff at openjdk.java.net (Turbanov Andrey)
Date: Mon, 30 Nov 2020 17:45:04 GMT
Subject: <AWT Dev> RFR: 8257438: Avoid adding duplicate values into
 extendedKeyCodesSet
Message-ID: <FwUF270K3RfAXCEf_QIgDkCkDvs8-VgtBIAnqpGLVM0=.825bd05d-5a66-4aef-8652-0f7d2993ee7d@github.com>

Looks like extended key codes set was filled with _synonyms_
https://wiki.linuxquestions.org/wiki/List_of_Keysyms_Recognised_by_Xmodmap
`0x10006cc` is a _Farsi_yeh_ and also deprecated synonym _Arabic_farsi_yeh_
`0x1000589` is an _Armenian_full_stop_ and also deprecated synonym _Armenian_verjaket_
`0x100055d` is an _Armenian_separation_mark_ and also deprecated synonym _Armenian_but_
`0x100055b` is an _Armenian_accent_ and also deprecated synonym _Armenian_shesht_
`0x100055e` is an _Armenian_question_ and also deprecated synonym _Armenian_paruyk_

Found by IntelliJ IDEA inspection `Java | Probable bugs | Overwritten Map key or Set element`

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

Commit messages:
 - [PATCH] Avoid adding duplicate values into extendedKeyCodesSet

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

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

From serb at openjdk.java.net  Mon Nov 30 17:45:05 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Nov 2020 17:45:05 GMT
Subject: <AWT Dev> RFR: 8257438: Avoid adding duplicate values into
 extendedKeyCodesSet
In-Reply-To: <FwUF270K3RfAXCEf_QIgDkCkDvs8-VgtBIAnqpGLVM0=.825bd05d-5a66-4aef-8652-0f7d2993ee7d@github.com>
References: <FwUF270K3RfAXCEf_QIgDkCkDvs8-VgtBIAnqpGLVM0=.825bd05d-5a66-4aef-8652-0f7d2993ee7d@github.com>
Message-ID: <V1lO7Y9OvOsI_YJC8zRQvgHFZWkNnUCPfaG6a3HUgLo=.e4e7f0c3-730c-4a2a-af2b-844a9a82f79e@github.com>

On Sat, 28 Nov 2020 20:12:57 GMT, Turbanov Andrey <github.com+741251+turbanoff at openjdk.org> wrote:

> Looks like extended key codes set was filled with _synonyms_
> https://wiki.linuxquestions.org/wiki/List_of_Keysyms_Recognised_by_Xmodmap
> `0x10006cc` is a _Farsi_yeh_ and also deprecated synonym _Arabic_farsi_yeh_
> `0x1000589` is an _Armenian_full_stop_ and also deprecated synonym _Armenian_verjaket_
> `0x100055d` is an _Armenian_separation_mark_ and also deprecated synonym _Armenian_but_
> `0x100055b` is an _Armenian_accent_ and also deprecated synonym _Armenian_shesht_
> `0x100055e` is an _Armenian_question_ and also deprecated synonym _Armenian_paruyk_
> 
> Found by IntelliJ IDEA inspection `Java | Probable bugs | Overwritten Map key or Set element`

The bug was filed for this PR, please type the command above to refer to that bug.

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

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

From github.com+1538227+arodionov at openjdk.java.net  Mon Nov 30 17:53:26 2020
From: github.com+1538227+arodionov at openjdk.java.net (Andrii Rodionov)
Date: Mon, 30 Nov 2020 17:53:26 GMT
Subject: <AWT Dev> RFR: 8254024: Enhance native libs for AWT and Swing
 to work with GraalVM Native Image [v3]
In-Reply-To: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>
Message-ID: <jIIDeQeTWq5Rt5kBh4_H3TS8zsGXagsEvyo9XVmzlNw=.195765dc-1d2d-4cc4-98ce-e7923b15c570@github.com>

> The following PR fixes https://bugs.openjdk.java.net/browse/JDK-8254024

Andrii Rodionov 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:

  8254024: Enhance native libs for AWT and Swing to work with GraalVM Native Image

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/562/files
  - new: https://git.openjdk.java.net/jdk/pull/562/files/65d3e835..47252ec8

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

  Stats: 644800 lines in 4146 files changed: 524091 ins; 79120 del; 41589 mod
  Patch: https://git.openjdk.java.net/jdk/pull/562.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/562/head:pull/562

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

From kizune at openjdk.java.net  Mon Nov 30 19:59:55 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 30 Nov 2020 19:59:55 GMT
Subject: <AWT Dev> RFR: 8256373: [Windows/HiDPI] The Frame#setBounds
 does not work in a minimized state
In-Reply-To: <rnMuc8fXGxVXCbogchpWBX_95FZkt1NrSC52QfdfhwU=.4473141b-66d1-4f0a-aa3a-6d4b9e4f575c@github.com>
References: <rnMuc8fXGxVXCbogchpWBX_95FZkt1NrSC52QfdfhwU=.4473141b-66d1-4f0a-aa3a-6d4b9e4f575c@github.com>
Message-ID: <CnIvkCurCHeD_8PzKC05bUwyX_4AfgHxx5bRCIxyQrw=.ca499ada-5604-4d34-8cc0-fd7f4b21ef8a@github.com>

On Mon, 16 Nov 2020 03:02:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> On HIDPI Windows, the Frame#setBounds does not work in a minimized state. The bug found during the development of JDK-8211999. When the frame is iconized and we try to save new bounds for future use, we store the coordinates in the user's space to the field which use device space:
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664

Marked as reviewed by kizune (Reviewer).

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

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

From kizune at openjdk.java.net  Mon Nov 30 19:59:57 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 30 Nov 2020 19:59:57 GMT
Subject: <AWT Dev> RFR: 8256373: [Windows/HiDPI] The Frame#setBounds
 does not work in a minimized state
In-Reply-To: <qRMQc46SJ_HjhmaiT3ADr2uKKeJSEfb0p1mOO-Q8W2A=.12b29792-ced9-4983-a3b0-28e59acd3dd0@github.com>
References: <rnMuc8fXGxVXCbogchpWBX_95FZkt1NrSC52QfdfhwU=.4473141b-66d1-4f0a-aa3a-6d4b9e4f575c@github.com>
 <HhvXU9p6AI9S3wfbMqG1TnpLsGtzPSWXvqgkUs5EwlY=.3b733147-1a61-40d1-a215-1ccda77bc48f@github.com>
 <j-UBUx8hbgmB7nLdvluh2lOCM9nyhpx6HFnUXBlSX_w=.aae27117-68e8-4eae-b607-39bf188606c0@github.com>
 <qRMQc46SJ_HjhmaiT3ADr2uKKeJSEfb0p1mOO-Q8W2A=.12b29792-ced9-4983-a3b0-28e59acd3dd0@github.com>
Message-ID: <Lew6Wof8XEP6RkdLnvY2NrPr4JkA0RgS4mSV9utOwtY=.6330dea5-f468-47b8-a582-243ee604762b@github.com>

On Mon, 30 Nov 2020 03:42:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Quick question: is there any way to manually reproduce this problem or it is only possible programmatically? How can you move iconified window to another display without de-iconifying it?
>> 
>> To reproduce the bug it is necessary to call setBounds method while the window is iconified - actually replacing its normal state bounds. So when the frame will de-iconifying(become normal) it appeared on the new bounds.
>
> Any volunteers for a review?

Ok, i played around with the fix, seems to be working fine.

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

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

From github.com+1538227+arodionov at openjdk.java.net  Mon Nov 30 22:32:00 2020
From: github.com+1538227+arodionov at openjdk.java.net (Andrii Rodionov)
Date: Mon, 30 Nov 2020 22:32:00 GMT
Subject: <AWT Dev> RFR: 8254024: Enhance native libs for AWT and Swing
 to work with GraalVM Native Image
In-Reply-To: <xOo0CtO8uhLGrSiROM30bY_bS1mKl-4vlK68eIOSxkM=.8d83e016-a7b0-4f0e-a2b0-f0221e5fba56@github.com>
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>
 <wTu1KYcM4mGcl9vJo1801bSz7TjmPfJe0qcdTGk2VLw=.0f813dd3-1a65-4981-8366-015c53afa6de@github.com>
 <nuRBeOsQfK-e8AlOYqbNCkA5PBvq2fkn3ajD5qO6EEA=.af41b9fe-d3be-4daf-b9be-c995fa6dd655@github.com>
 <ntRWXDeM6dkIdJY35CONCg8CorrhGmOvGpoq4j-OnSg=.69e9f9c2-754f-438b-960f-0a13daca0309@github.com>
 <o5PqI-0JlvEgEy-KXilJvFKyX3vNJnMH9nAgcBoABdg=.80d5f6a9-d68b-4a26-97ac-3b66bfb5d313@github.com>
 <p75sm7bljXhbCvv_co0gnczxO_sAYfDjwmYDBRRZKsg=.f33ca87f-4700-4348-8ffd-137c00b2395b@github.com>
 <v2MRHheWZJuZyYs2e7HHYTWGFd-MQplZco5JPcvPPCs=.02ffe15c-4b94-45ab-96fa-ac8e5de450ef@github.com>
 <QzfezoU2Z6pAhQPucs_Tj7qhCp-pnT1xJNeGaY8ZIIs=.1a8f82c9-2ee5-482b-b2a7-c76e03359a1f@github.com>
 <2hFTjMReXMfiNjTWswTV5EyEA7zFoEIbepsyelAcPeU=.fe56a018-3429-420c-b47f-274a400cc989@github.com>
 <QrK00iKoap7foOlhN2iMP2db0Rzae-oOB0FQBlZpHIk=.c61d95ae-bdae-4f58-a6c1-ee0e610ee442@github.com>
 <uKRfxak1vC1q-Gq_wT-SZewnJECciGLipTz
 Szgsp5_4=.2ee8c653-ab49-4be9-a7e9-5013d35676f3@github.com>
 <eDjJrOr_NkjJe4_vziRSrGby_Y0JZ6WIAioNPfY2pCM=.b67111ed-896f-4096-84c2-53f51290ad94@github.com>
 <MLCPQ7F1i88ra5xzd1BRcBbMTRxArgfxu6tc-s1o4ZM=.294480d9-043e-4e56-bfad-4d06c83c445b@github.com>
 <jbxDix7bNUsNqPh0BQDqNqqSkXXPax4ut8fS5odCrqI=.82c96792-e691-46ab-9756-d444adb6b186@github.com>
 <KdtSni2r8p8F3aKOPKeoBxUK6dmLQZ-ZYvlppfZWrN4=.77af7a43-eadf-45ed-bc2b-d0ecf74a8489@github.com>
 <bX2VsAGYYiqMHGhqoNYVZa08lXtv6HWkYc8G9meDLiM=.8524069e-bd6d-44af-9a92-c273774b66a3@github.com>
 <xOo0CtO8uhLGrSiROM30bY_bS1mKl-4vlK68eIOSxkM=.8d83e016-a7b0-4f0e-a2b0-f0221e5fba56@github.com>
Message-ID: <IAA5IYjPbGdoC3oxPd14tqe4RyGPyhL4I2fXZ_kgHs4=.b46f4f6e-e619-4aea-9512-60525cf62109@github.com>

On Sat, 14 Nov 2020 00:25:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The changes in awt_LoadLibrary.c and XToolkit.c is mostly noop except excluding dladdr/dlopen. Since XsessionWMcommand/AWTIsHeadless are not used at least in the mainline(jdk16).
>> The changes in the mlib look fine.
>> 
>> The testing is in progress.
>
> please merge the master to this branch, it is quite outdated, and update the last copyright date to 2020.

@mrserb I have rebased PR on the master, but `XsessionWMcommand` and `AWTIsHeadless` functions are still at `XToolkit.c` in the mainline. So, to prevent the conflicting symbols error during static libraries linkage (`libawt.a` and `libawt_xawt.a`), we need to rename or to hide conflicting functions.

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

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

From aivanov at openjdk.java.net  Mon Nov 30 23:13:04 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 30 Nov 2020 23:13:04 GMT
Subject: <AWT Dev> RFR: 8256373: [Windows/HiDPI] The Frame#setBounds
 does not work in a minimized state
In-Reply-To: <rnMuc8fXGxVXCbogchpWBX_95FZkt1NrSC52QfdfhwU=.4473141b-66d1-4f0a-aa3a-6d4b9e4f575c@github.com>
References: <rnMuc8fXGxVXCbogchpWBX_95FZkt1NrSC52QfdfhwU=.4473141b-66d1-4f0a-aa3a-6d4b9e4f575c@github.com>
Message-ID: <r29FIlatjUDu2ZKpBQjYF4hI25Sv6r_O_wB73BDeFEs=.fdf09fba-a968-4361-927b-5767da68844f@github.com>

On Mon, 16 Nov 2020 03:02:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> On HIDPI Windows, the Frame#setBounds does not work in a minimized state. The bug found during the development of JDK-8211999. When the frame is iconized and we try to save new bounds for future use, we store the coordinates in the user's space to the field which use device space:
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664

Marked as reviewed by aivanov (Reviewer).

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

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