From serb at openjdk.java.net  Wed Dec  1 04:30:28 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 1 Dec 2021 04:30:28 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy
In-Reply-To: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
Message-ID: <OYJhpnOMxPPAdK4Eq0vTWtvyT2uefgmivsw0KcfvxzU=.bab976ad-ab84-4fd6-8cf4-faf805a54a64@github.com>

On Tue, 30 Nov 2021 01:31:24 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).

As of the usefulness of the serializations tests in Swing - it is a good coverage of the cleaning code in the L&fs. Each L&F should clean all its data when the app switch one LF to another, but if old L&F forget to cleanup then the app will get a memory leak.

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

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


From serb at openjdk.java.net  Wed Dec  1 04:44:26 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 1 Dec 2021 04:44:26 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy
In-Reply-To: <zGxFr0_MqwFe1GB9uRdo_NsVlrJv4weEwt37k3nwxyo=.c5364c7f-1e60-4722-b020-522a2615bd54@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <zGxFr0_MqwFe1GB9uRdo_NsVlrJv4weEwt37k3nwxyo=.c5364c7f-1e60-4722-b020-522a2615bd54@github.com>
Message-ID: <mBdcBpXJZbQRzAHPfPDbppSPpEr338kIap8jUG0IfcM=.774774e9-1c16-479d-978d-dcb5c7cf7823@github.com>

On Tue, 30 Nov 2021 20:46:34 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> I regenerated it by following the instructions to compile and run the test class as a standalone tool on `x86_64 GNU/Linux`, which updated all of the existing files. I verified it fixes the test on that platform, I don't have a great way to test it on the other platforms right now.

As far as I remember the previous fix regenerated the binary files only, for a specific reason - before that a couple of commits fixed a memory leak which prevents the Aqua L&F deletes all its delegates during cleanup step. This cleanup step is executed in two cases, when we serialize the component or when we switch one L&F to another.

Since the fix for JDK-8276665 exposed another bug you will need:
 1. Regenerate the data on macOS
 2. If the test will fail while use the new regenerated data, then you will need to fix the Aqua to properly delete the references to the Aqua specific objects.

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

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


From serb at openjdk.java.net  Wed Dec  1 04:47:32 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 1 Dec 2021 04:47:32 GMT
Subject: RFR: 8264666: Reuse Math.multiplyExact/addExact in the
 LCMSImageLayout class
In-Reply-To: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
Message-ID: <96-wh0UfZ8HmfbhrPDzh1dZkpUF76GikHRPkGMMW9Mk=.6b38168f-2617-4b6d-9027-a169fff5dd9e@github.com>

On Fri, 2 Apr 2021 23:02:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions.
> - Cleanup: the usage of do/while(false) is removed

not now

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

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


From serb at openjdk.java.net  Wed Dec  1 04:48:28 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 1 Dec 2021 04:48:28 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <RbNXQvBrVWXflRPpNFufOOsFznKIM1tflikz1Dc3UMI=.5455d25b-7360-4d69-a9fe-50baeb37f193@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

Any volunteers?

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

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


From serb at openjdk.java.net  Wed Dec  1 04:48:29 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 1 Dec 2021 04:48:29 GMT
Subject: RFR: 8225122: Test AncestorResized.java fails when Windows desktop
 is scaled.
In-Reply-To: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
References: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
Message-ID: <jf4HR4GRhq5r2g2asNfrJH8u3X8-6pQ83w-c1A9T-vw=.b23445ee-0b1d-4f3d-8ba4-2ab1e8d03a64@github.com>

On Mon, 27 Sep 2021 03:33:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This test depends on the next windows UI performance option:
> ?Show window contents while dragging?, see https://answers.microsoft.com/en-us/windows/forum/all/in-windows-7-how-do-i-show-window-contents-while/18e3aee2-bcc7-4005-a45d-c5613cf6eb3c
> 
> In the default configuration, the windows may decide that the system is slow and this option should be disabled. I have found that this usually happens in the virtual environment.
> 
> When that option is disabled the resize events have come when the user completes the resize, before that the only border "rectangle" is moved.
> 
> This fix changes the test to release the mouse and complete the resize, and only after that checks the result.
> 
> Also, some old machinery is removed.

Any volunteers?

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

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


From jdv at openjdk.java.net  Wed Dec  1 06:15:27 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 1 Dec 2021 06:15:27 GMT
Subject: RFR: 8266435: WBMPImageReader.read() should not truncate the input
 stream
In-Reply-To: <icd3sXDFOf8TQx78hDgO9wULkZ0ah_yVrNvrQESsB0k=.f091df72-107b-4208-b651-9e142b60665e@github.com>
References: <dgFDpOpF6ONZCwgc9eJxvqQcESf8-WmmLAi4eHNeJjg=.33280dd0-fbff-4fa7-a90f-d6b9d7f35225@github.com>
 <icd3sXDFOf8TQx78hDgO9wULkZ0ah_yVrNvrQESsB0k=.f091df72-107b-4208-b651-9e142b60665e@github.com>
Message-ID: <iLTDuw7aF9WP50tRBAoAVPQzOks1qXjdaTJY-dCk3jo=.4c1d28d5-5dd9-4cfb-90dd-c66472f5a410@github.com>

On Thu, 25 Nov 2021 03:56:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> If we use a custom stream and specify limit on stream.read() length, WBMPImageReader.read() doesnt verify whether we are decoded complete data or not. We can check the length of data decoded and rerun the stream.read() or use readFully(). In case of other decoders like BMP we are using readFully(), so i have updated WBMPImageReader.read() to use readFully().
>
> test/jdk/javax/imageio/plugins/wbmp/WBMPStreamTruncateTest.java line 61:
> 
>> 59:         File imageFile = File.
>> 60:                 createTempFile("test", ".wbmp", new File(filePath));
>> 61:         imageFile.deleteOnExit();
> 
> In one another review I saw the deleteOnExit() usage, I remember that in case of full testrun via makefile, such files were not deleted, can you please confirm that it is work fine? probably that it was fixed already. Note that the full test run uses custom tmp folder inside the result dir.

@mrserb I ran the test using "make test" and i dont see any .wbmp file after test run in results directory.
Also i verified that it doesn't leave any image in test directory of CI machines.

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

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


From myano at openjdk.java.net  Wed Dec  1 06:21:36 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 1 Dec 2021 06:21:36 GMT
Subject: Integrated: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException
In-Reply-To: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
Message-ID: <Q4XxMtpuQgwIuI0x9lZ5OGNx67WrRP6WxEwZunsJ5kQ=.1d4a4d88-340d-4b68-907e-b0aaf547952a@github.com>

On Thu, 28 Oct 2021 09:29:13 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 8262297 bug fixes?
> 
> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.

This pull request has now been integrated.

Changeset: c7331935
Author:    Masanori Yano <myano at openjdk.org>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c73319354399596ab2b9aab0a7f62e8fa0ab9365
Stats:     86 lines in 2 files changed: 84 ins; 0 del; 2 mod

8262297: ImageIO.write() method will throw IndexOutOfBoundsException

Reviewed-by: serb, jdv

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

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


From jdv at openjdk.java.net  Wed Dec  1 07:00:30 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 1 Dec 2021 07:00:30 GMT
Subject: RFR: 8272392 Lanai: SwingSet2. Black background on expanding tree
 node [v2]
In-Reply-To: <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>
References: <j43XsVmt-JoPBbf2zmSprcycbHlkZF2GSBXas3T7BRk=.fcee72ac-9edf-423d-b71d-89612e6d2e52@github.com>
 <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>
Message-ID: <kh9XZb18l6kGUaPl8qTOpiz0e-aANWYBZVep-_iN-7U=.08df80e2-5530-40ad-bf6f-31f24fe96b09@github.com>

On Fri, 26 Nov 2021 09:02:37 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Removed creation of the separate encoder depending on destination properties as we don't use this info to customize the encoder properties
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272392 Lanai: SwingSet2. Black background on expanding tree node
>   
>   Fixed incorrect addition of the values into pipeline state cache. Refactored index initialization. Removed unused flags from MTLClip.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/EncoderManager.m line 44:

> 42: 
> 43: - (void)reset:(id<MTLTexture>)destination
> 44:          isAA:(jboolean)isAA

I think by mistake isText argument is also removed. It is not matching reset() implementation.

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

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


From jdv at openjdk.java.net  Wed Dec  1 07:11:29 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 1 Dec 2021 07:11:29 GMT
Subject: RFR: 8272392 Lanai: SwingSet2. Black background on expanding tree
 node [v2]
In-Reply-To: <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>
References: <j43XsVmt-JoPBbf2zmSprcycbHlkZF2GSBXas3T7BRk=.fcee72ac-9edf-423d-b71d-89612e6d2e52@github.com>
 <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>
Message-ID: <zWjBqDsiQ9dNdsHxxtaEGOgqB3XEZGMoeRT9ti5pwak=.7b688ada-3005-4276-a6f0-7e8c9046a9d6@github.com>

On Fri, 26 Nov 2021 09:02:37 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Removed creation of the separate encoder depending on destination properties as we don't use this info to customize the encoder properties
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272392 Lanai: SwingSet2. Black background on expanding tree node
>   
>   Fixed incorrect addition of the values into pipeline state cache. Refactored index initialization. Removed unused flags from MTLClip.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLClip.m line 61:

> 59:     BOOL _stencilMaskGenerationInProgress;
> 60:     BOOL _stencilMaskGenerationStarted;
> 61:     BOOL _clipReady;

This looks like cleanup and not related to this change. Sometime back i also had question on why this was needed. Thanks.

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

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


From psadhukhan at openjdk.java.net  Wed Dec  1 07:37:29 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 1 Dec 2021 07:37:29 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <YiD77xLG0VKrLp006_WlNtqMBRD-wDDsGPqP_nDzbRQ=.d5e79ac8-5bc2-49e4-a6a8-9af26f906a17@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

It seems CheckCommonColors still fails intermittently even with this fix in macos aarch64 along with others
open/test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java, 
open/test/jdk/java/awt/ColorClass/AlphaColorTest.java, 
open/test/jdk/java/awt/AlphaComposite/WindowAlphaCompositeTest.java

CheckCommonColors fails with this log
---------System.out:(3/175)----------
color = java.awt.Color[r=255,g=255,b=255], useRect = true
color = java.awt.Color[r=255,g=255,b=255], useRect = false
color = java.awt.Color[r=192,g=192,b=192], useRect = true
----------System.err:(17/897)----------
Expected: java.awt.Color[r=192,g=192,b=192]
Actual: java.awt.Color[r=199,g=199,b=199]
Point: java.awt.Point[x=960,y=600]
Dump screen to: ScreenCapture.png

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

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


From jdv at openjdk.java.net  Wed Dec  1 07:58:28 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 1 Dec 2021 07:58:28 GMT
Subject: RFR: 8272392 Lanai: SwingSet2. Black background on expanding tree
 node [v2]
In-Reply-To: <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>
References: <j43XsVmt-JoPBbf2zmSprcycbHlkZF2GSBXas3T7BRk=.fcee72ac-9edf-423d-b71d-89612e6d2e52@github.com>
 <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>
Message-ID: <K7LmUFlnX3OT5aRI9mIvYtVrhwQLxvyjdQ87OZzaAWo=.195c33d3-c7dc-4f82-90e5-e71fc2aab953@github.com>

On Fri, 26 Nov 2021 09:02:37 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Removed creation of the separate encoder depending on destination properties as we don't use this info to customize the encoder properties
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272392 Lanai: SwingSet2. Black background on expanding tree node
>   
>   Fixed incorrect addition of the values into pipeline state cache. Refactored index initialization. Removed unused flags from MTLClip.

I used test case present in https://bugs.openjdk.java.net/browse/JDK-8267963 to check how it behaves with this PR and noticed that it is causes regresssion related to how ruler text looks and also if we move Ruler between monitors it doesnt draw.

Thought this may be because of state's not getting reset since there is mismatch in EncoderManager.reset() arguments. Updated code to add isText argument over this PR, but i continue to see the regressions.

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

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


From jdv at openjdk.java.net  Wed Dec  1 10:08:37 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 1 Dec 2021 10:08:37 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v5]
In-Reply-To: <U2NwWg-Qzc6gjAUIPs_v-B14fG4UPFPd0ELpAfw-xkU=.de144f74-eb1c-47b5-a198-245566b1d81e@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <U2NwWg-Qzc6gjAUIPs_v-B14fG4UPFPd0ELpAfw-xkU=.de144f74-eb1c-47b5-a198-245566b1d81e@github.com>
Message-ID: <SniwEMbSvc9v2COxfMhVB367rz5bbnUspnlF0IPuqFE=.3231ac5d-2613-4798-b39d-bdf9f29e06ba@github.com>

On Wed, 24 Nov 2021 11:09:42 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8262297 bug fixes?
>> 
>> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8262297: ImageIO.write() method will throw IndexOutOfBoundsException

This change has caused regression : https://bugs.openjdk.java.net/browse/JDK-8278047
So this change will be reverted for further analysis.

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

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


From jdv at openjdk.java.net  Wed Dec  1 10:14:49 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 1 Dec 2021 10:14:49 GMT
Subject: RFR: 8278047: Few javax/imageio test regressed after JDK-8262297 fix
Message-ID: <Ft8NQimVdq6Ng4TCHUJlGeqhjHxWm-EZQP5gTLOGK8s=.a9b856a0-9a56-4a41-a645-6c0dffd0a159@github.com>

Looks like we have 8 test cases where we are trying to write 15bpp BMP images and after JDK-8262297 all of them are failing.
We need to update these test cases to not encode 15bpp BMP images or supporting 15bpp BMP images is valid use case. This needs more investigation. I am backing out changes done under JDK-8262297 for further analysis.

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

Commit messages:
 - 8278047: Few javax/imageio test regressed after JDK-8262297 fix

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

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


From tschatzl at openjdk.java.net  Wed Dec  1 10:25:31 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 1 Dec 2021 10:25:31 GMT
Subject: RFR: 8278047: Few javax/imageio test regressed after JDK-8262297
 fix
In-Reply-To: <Ft8NQimVdq6Ng4TCHUJlGeqhjHxWm-EZQP5gTLOGK8s=.a9b856a0-9a56-4a41-a645-6c0dffd0a159@github.com>
References: <Ft8NQimVdq6Ng4TCHUJlGeqhjHxWm-EZQP5gTLOGK8s=.a9b856a0-9a56-4a41-a645-6c0dffd0a159@github.com>
Message-ID: <m0FKescSnYDuuo4cMkDA8FBi15h4b-PwrPeNYwf3Gwo=.f3263df0-e3c0-4102-a60f-5b0cfca1ee6e@github.com>

On Wed, 1 Dec 2021 10:07:30 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Looks like we have 8 test cases where we are trying to write 15bpp BMP images and after JDK-8262297 all of them are failing.
> We need to update these test cases to not encode 15bpp BMP images or supporting 15bpp BMP images is valid use case. This needs more investigation. I am backing out changes done under JDK-8262297 for further analysis.

Lgtm, is a clean backout. It would be nice to link the old changes directly for easier comparison in the PR text next time.

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

Marked as reviewed by tschatzl (Reviewer).

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


From jdv at openjdk.java.net  Wed Dec  1 10:25:31 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 1 Dec 2021 10:25:31 GMT
Subject: RFR: 8278047: Few javax/imageio test regressed after JDK-8262297
 fix
In-Reply-To: <m0FKescSnYDuuo4cMkDA8FBi15h4b-PwrPeNYwf3Gwo=.f3263df0-e3c0-4102-a60f-5b0cfca1ee6e@github.com>
References: <Ft8NQimVdq6Ng4TCHUJlGeqhjHxWm-EZQP5gTLOGK8s=.a9b856a0-9a56-4a41-a645-6c0dffd0a159@github.com>
 <m0FKescSnYDuuo4cMkDA8FBi15h4b-PwrPeNYwf3Gwo=.f3263df0-e3c0-4102-a60f-5b0cfca1ee6e@github.com>
Message-ID: <WB-EBpwjUhWpJRlreR5SbmltFAMWmm_nOI9ATmNtKUg=.0f83a3d1-895a-4ba4-a610-20c95373d9a5@github.com>

On Wed, 1 Dec 2021 10:19:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Lgtm, is a clean backout. It would be nice to link the old changes directly for easier comparison in the PR text next time.

Thanks Thomas. Sure will do.

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

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


From jdv at openjdk.java.net  Wed Dec  1 10:25:31 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 1 Dec 2021 10:25:31 GMT
Subject: Integrated: 8278047: Few javax/imageio test regressed after
 JDK-8262297 fix
In-Reply-To: <Ft8NQimVdq6Ng4TCHUJlGeqhjHxWm-EZQP5gTLOGK8s=.a9b856a0-9a56-4a41-a645-6c0dffd0a159@github.com>
References: <Ft8NQimVdq6Ng4TCHUJlGeqhjHxWm-EZQP5gTLOGK8s=.a9b856a0-9a56-4a41-a645-6c0dffd0a159@github.com>
Message-ID: <8khf9PfDbdEvM0CPb5RJn0P-uijRj-SSKeyiZBnVCJE=.66b503a7-d91d-4d31-a6d0-dd72f96b2ad9@github.com>

On Wed, 1 Dec 2021 10:07:30 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Looks like we have 8 test cases where we are trying to write 15bpp BMP images and after JDK-8262297 all of them are failing.
> We need to update these test cases to not encode 15bpp BMP images or supporting 15bpp BMP images is valid use case. This needs more investigation. I am backing out changes done under JDK-8262297 for further analysis.

This pull request has now been integrated.

Changeset: 84aa0a19
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/84aa0a191b085a3d7cb338fd5e67281d0e4b57be
Stats:     86 lines in 2 files changed: 0 ins; 84 del; 2 mod

8278047: Few javax/imageio test regressed after JDK-8262297 fix

Reviewed-by: tschatzl

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

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


From dbatrak at openjdk.java.net  Wed Dec  1 10:58:40 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Wed, 1 Dec 2021 10:58:40 GMT
Subject: RFR: 8278050: Armenian text isn't rendered on macOS if text layout is
 performed
Message-ID: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>

The problem is related to the implementation of font fallback on macOS, specifically to the path used when text layout
is performed, i.e. the one using `FontSubstitution` and cascade lists. `CTFontCopyDefaultCascadeListForLanguages`'s output contains an entry for the font, able to render Armenian text ('NotoSansArmenian-Regular'), but `CFont.createCompositeFont` cannot find this font amongst registered fonts, and the entry is skipped, resulting in broken rendering.
System font loading (performed by `CFontManager.loadNativeFonts`) relies on `[NSFontManager availableFontFamilies]`, but its output doesn't contain 'Noto Sans Armenian' (which is a family for 'NotoSansArmenian-Regular' font). 'Noto Sans Armenian' is recognized by `[NSFontManager availableMembersOfFontFamily:]` though, 'NotoSansArmenian-Regular' is contained in `[NSFontManager availableFonts]` output, and the font can be created and used normally, just like any other system font. Not sure why its family is 'hidden', maybe macOS developers wanted to limit the number of options
displayed in font selection drop-downs.
For reference, another cascade list item, ignored in similar way is 'NotoSansZawgyi-Regular'.

Proposed fix is to create `CFont` objects for cascade list items explicitly, if corresponding fonts are not registered. These objects are re-used between different fonts as their fallback components (to enable caching of char-to-glyph mapping), but are not made available to public font APIs.
I've considered an alternative solution - using `[NSFontManager availableFonts]` instead of
`[NSFontManager availableFontFamilies]` to load system fonts. Two factors complicate it though - `loadNativeFonts` will
take more time (on my machine about 170 additional fonts will be loaded) and the order of font loading will change (which
impacts the selection of 'preferred' plain/bold/italic/bolditalic components in `FontFamily` class). Both factors can be
dealt with, but they make the solution more complicated and prone to regressions. For now, it seems not worth it.

I've not created a test, as it would rely on macOS providing a fallback font for Armenian script, which is not guaranteed.
Existing tests pass fine with the fix.

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

Commit messages:
 - ensure all fallback components are used

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

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


From asemenov at openjdk.java.net  Wed Dec  1 12:25:56 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Wed, 1 Dec 2021 12:25:56 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v5]
In-Reply-To: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
Message-ID: <z9mC6c44JuBjy1SA6crXIOPuLhQhKGDiy4Zztn-yo7k=.2a52d334-0ec9-46a4-b038-4de68243d132@github.com>

> Testing https://bugs.openjdk.java.net/browse/JDK-8271071 
> Step to reproduce 
> 1) Run SwingSet2 in JDK 18 ( I used b24 ) 
> 2) Enable Voiceover. 
> 3) Select JTable demo 
> 4) Click any row in the table or select the first row . Observe that row is selected & VoiceOver reads the column values or navigate the columns one by one by pressing tab key. When the focus reaches the last column ( Favourite Food ) Observe that column value is read as null. If you hear the same then the bug is reproduced.

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

  8277497: Last column cell in the JTAble row is read as empty cell

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6538/files
  - new: https://git.openjdk.java.net/jdk/pull/6538/files/2199bd53..22dfb014

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

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

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


From asemenov at openjdk.java.net  Wed Dec  1 12:29:27 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Wed, 1 Dec 2021 12:29:27 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v3]
In-Reply-To: <EQnkRK_iV0WV5D2YppyoeEKTNSPec0NdZhD4LYnIqSA=.6344ec75-896e-4ee0-af46-c02ca3158faa@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
 <FaRdPReanZ4yCDyfLPQnZNjHZGCxtx9YNoDRssy1P-w=.3a819ed2-7b6c-45db-ac4f-3f196103953e@github.com>
 <p_g-qKuMtrK3M16iCkvdmgjnBWZTpWMxzkLT_4p5X5E=.fea38522-8074-4238-9df9-d89aff13ec53@github.com>
 <EQnkRK_iV0WV5D2YppyoeEKTNSPec0NdZhD4LYnIqSA=.6344ec75-896e-4ee0-af46-c02ca3158faa@github.com>
Message-ID: <96BzzDB31C1RtKlS5NjrVRyA8lRvR5k3ugBbPu2XYYg=.05fdca6d-ec05-4a9f-9228-88977d89ffa0@github.com>

On Fri, 26 Nov 2021 01:54:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Done. thank you very much.
>
> I few questions to thinking about:
>  - If the label and icon is not accessible then should we say something? Or we should ignore it like we do for any other non-accessible components?
>  - Why the image text is used, don't we need to use the "javax.accessibility.AccessibleRole#ICON" role for such label/icon and allow the reader to say something standard for the icon. Does the voiceover has some default text for the icon/image when the alt text is not set?

Thank you very much. We've made a change. A comparison of the behavior before and after the changes is below.

### On MAcOS.
#### State before our changes .:
- in a standalone label with an icon without text, VO says Image;
- in a standalone label with an icon with text VO speaks the text of the label;
- If a label without text with an icon is in the table VO says "Empty cell".

#### If you add just a role change:
- in a standalone label with an icon without text, VO says Image;
- in a standalone label with an icon with text VO speaks the text of the label;
- In the table for a label with an icon without text, when navigating horizontally, VO does not say anything;
- In the table for a label with an icon without text for vertical navigation, VO says "image cell".

Unacceptable option.

#### With a complete fix:
- in a standalone label with an icon without text, VO says Image;
- in a standalone label with an icon with text VO speaks the text of the label;
- In the table for a label with an icon without text, for any navigation, VO says "image".

### ON Windows.

#### State before our changes:
- in a standalone label with an icon and text, the label text is spoken;
- in a standalone label with an icon without text, the label is skipped;
- In the table, a label with an icon without text is not spoken, the column heading is spoken.

#### With full patch:
- in a standalone label with an icon and text, the label text is spoken;
- in a standalone label with an icon without text the "Image icon" is spoken;
- In the table, a label with an icon without text is pronounced as "Image".

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

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


From cushon at openjdk.java.net  Wed Dec  1 16:42:57 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 1 Dec 2021 16:42:57 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v2]
In-Reply-To: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
Message-ID: <FbOvW3EIwqqRch7vKhpx25O77cchxccquEWCo8ORIao=.4e9a054f-7f6b-4420-8351-ad84790aae97@github.com>

> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).

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

  8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6603/files
  - new: https://git.openjdk.java.net/jdk/pull/6603/files/ad9665ff..8b68c150

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

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

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


From serb at openjdk.java.net  Wed Dec  1 16:50:23 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 1 Dec 2021 16:50:23 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <YiD77xLG0VKrLp006_WlNtqMBRD-wDDsGPqP_nDzbRQ=.d5e79ac8-5bc2-49e4-a6a8-9af26f906a17@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
 <YiD77xLG0VKrLp006_WlNtqMBRD-wDDsGPqP_nDzbRQ=.d5e79ac8-5bc2-49e4-a6a8-9af26f906a17@github.com>
Message-ID: <3hifIGaT4Skr3LNoFLelBjwk-Klkf1Sj2xl2K9KHPoQ=.791262e7-e7ae-4672-ae6c-158a44908582@github.com>

On Wed, 1 Dec 2021 07:34:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems CheckCommonColors still fails intermittently even with this fix in macos aarch64 along with others open/test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java, open/test/jdk/java/awt/ColorClass/AlphaColorTest.java, open/test/jdk/java/awt/AlphaComposite/WindowAlphaCompositeTest.java

They could fail because of cursor location, or some other bug in our code or in the macOS. It will be good to debug it on that system where it fail.

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

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


From prr at openjdk.java.net  Wed Dec  1 17:37:28 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 1 Dec 2021 17:37:28 GMT
Subject: RFR: 8278050: Armenian text isn't rendered on macOS if text layout
 is performed
In-Reply-To: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
References: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
Message-ID: <dTa8ToEjtbOZm9JzLxUn7SY8quVuPDr-wYm6-Myr8k8=.a1f7c769-7df9-45a7-bf21-caad4ec8af06@github.com>

On Wed, 1 Dec 2021 10:52:38 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The problem is related to the implementation of font fallback on macOS, specifically to the path used when text layout
> is performed, i.e. the one using `FontSubstitution` and cascade lists. `CTFontCopyDefaultCascadeListForLanguages`'s output contains an entry for the font, able to render Armenian text ('NotoSansArmenian-Regular'), but `CFont.createCompositeFont` cannot find this font amongst registered fonts, and the entry is skipped, resulting in broken rendering.
> System font loading (performed by `CFontManager.loadNativeFonts`) relies on `[NSFontManager availableFontFamilies]`, but its output doesn't contain 'Noto Sans Armenian' (which is a family for 'NotoSansArmenian-Regular' font). 'Noto Sans Armenian' is recognized by `[NSFontManager availableMembersOfFontFamily:]` though, 'NotoSansArmenian-Regular' is contained in `[NSFontManager availableFonts]` output, and the font can be created and used normally, just like any other system font. Not sure why its family is 'hidden', maybe macOS developers wanted to limit the number of options
> displayed in font selection drop-downs.
> For reference, another cascade list item, ignored in similar way is 'NotoSansZawgyi-Regular'.
> 
> Proposed fix is to create `CFont` objects for cascade list items explicitly, if corresponding fonts are not registered. These objects are re-used between different fonts as their fallback components (to enable caching of char-to-glyph mapping), but are not made available to public font APIs.
> I've considered an alternative solution - using `[NSFontManager availableFonts]` instead of
> `[NSFontManager availableFontFamilies]` to load system fonts. Two factors complicate it though - `loadNativeFonts` will
> take more time (on my machine about 170 additional fonts will be loaded) and the order of font loading will change (which
> impacts the selection of 'preferred' plain/bold/italic/bolditalic components in `FontFamily` class). Both factors can be
> dealt with, but they make the solution more complicated and prone to regressions. For now, it seems not worth it.
> 
> I've not created a test, as it would rely on macOS providing a fallback font for Armenian script, which is not guaranteed.
> Existing tests pass fine with the fix.

Looks reasonable. FWIW the rendering being present in the non-layout case is likely due to the magic JRS fall back code .. some day we need to unify this so that at least we are consistent.

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

Marked as reviewed by prr (Reviewer).

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


From cushon at openjdk.java.net  Wed Dec  1 18:12:51 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 1 Dec 2021 18:12:51 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v3]
In-Reply-To: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
Message-ID: <y_5NNZh13M0aOunbDfLa4uwDfBR9DdTol_uTPtYYauM=.e2a4bb86-977c-46db-bc75-a3520239847f@github.com>

> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).

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

  8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6603/files
  - new: https://git.openjdk.java.net/jdk/pull/6603/files/8b68c150..6c858cd8

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

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

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


From cushon at openjdk.java.net  Wed Dec  1 18:18:27 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 1 Dec 2021 18:18:27 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy
In-Reply-To: <mBdcBpXJZbQRzAHPfPDbppSPpEr338kIap8jUG0IfcM=.774774e9-1c16-479d-978d-dcb5c7cf7823@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <zGxFr0_MqwFe1GB9uRdo_NsVlrJv4weEwt37k3nwxyo=.c5364c7f-1e60-4722-b020-522a2615bd54@github.com>
 <mBdcBpXJZbQRzAHPfPDbppSPpEr338kIap8jUG0IfcM=.774774e9-1c16-479d-978d-dcb5c7cf7823@github.com>
Message-ID: <A2UL7pvN09aUyk3iAhTQ5Soz24RhvPT6GRsiWE_XO44=.79dbb6be-a8c2-4ad1-964c-a15fc9e05a0b@github.com>

On Wed, 1 Dec 2021 04:41:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I couldn't find the review either.
>> 
>> I regenerated it by following the instructions to compile and run the test class as a standalone tool on `x86_64 GNU/Linux`, which updated all of the existing files. I verified it fixes the test on that platform, I don't have a great way to test it on the other platforms right now.
>> 
>> * https://github.com/openjdk/jdk/blob/5a4a9bb9d55134deac0e02cf37f31d1dd2223024/test/jdk/java/awt/dnd/BadSerializationTest/BadSerializationTest.java#L64-L65
>> 
>> * https://github.com/openjdk/jdk/blob/5a4a9bb9d55134deac0e02cf37f31d1dd2223024/test/jdk/java/awt/dnd/BadSerializationTest/BadSerializationTest.java#L95-L96
>> 
>> I started investigating this when I thought it was related to [JDK-8271623](https://bugs.openjdk.java.net/browse/JDK-8271623), if anyone wants to take this over (especially now that it's problem-listed) please feel free :)
>
>> I regenerated it by following the instructions to compile and run the test class as a standalone tool on `x86_64 GNU/Linux`, which updated all of the existing files. I verified it fixes the test on that platform, I don't have a great way to test it on the other platforms right now.
> 
> As far as I remember the previous fix regenerated the binary files only, for a specific reason - before that a couple of commits fixed a memory leak which prevents the Aqua L&F deletes all its delegates during cleanup step. This cleanup step is executed in two cases, when we serialize the component or when we switch one L&F to another.
> 
> Since the fix for JDK-8276665 exposed another bug you will need:
>  1. Regenerate the data on macOS
>  2. If the test will fail while use the new regenerated data, then you will need to fix the Aqua to properly delete the references to the Aqua specific objects.

Thanks @mrserb! I regenerated the binary files on macOS, and that caused the test to fail on linux.

I don't have a lot of context here, but as far as I can tell `BasicPanelUI` was installing (but not uninstalling) a reference to the color `Panel.background`, which for Aqua is an instance of `com.apple.laf.AquaImageFactory$SystemColorProxy`.

* https://github.com/openjdk/jdk/blob/a363b7b9217cbb9a7580a87b812da8d5a4215326/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPanelUI.java#L81-L83

* https://github.com/openjdk/jdk/blob/4efcd2006f00a6347987ecdacd6e09d59a0006f4/src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java#L391-L392

* https://github.com/openjdk/jdk/blob/4efcd2006f00a6347987ecdacd6e09d59a0006f4/src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java#L469-L471

I included a fix to `BasicPanelUI`, but the test now fails with a different issue:


Caused by: java.lang.ClassNotFoundException: com.apple.laf.AquaFonts$DerivedUIResourceFont
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)

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

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


From bchristi at openjdk.java.net  Wed Dec  1 18:21:04 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 1 Dec 2021 18:21:04 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal [v2]
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <m-ud7vTqLEF_8-DW2uxNLYZL7U0orlenSQXjZ4wmUgw=.7872b89e-a5f2-48dd-b17f-8b263fb07024@github.com>

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - Merge branch 'master' into 8276447
 - merge
 - @SuppressWarnings(removal) in Windows CKey.java
 - Add jls tag to runFinalization methods
 - Update wording of Object.finalize, new paragraph is now bold
 - update Object.finalize javadoc
 - update Object.finalize JavaDoc and @deprecated tag
 - Update Object.finalize deprecation message
 - Indicate that runFinalizers does nothing if finalization is disabled or removed
 - Fix @since on @Deprecated for java.lang.Enum
 - ... and 22 more: https://git.openjdk.java.net/jdk/compare/a363b7b9...e4986a48

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

Changes: https://git.openjdk.java.net/jdk/pull/6465/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=01
  Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465

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


From cushon at openjdk.java.net  Wed Dec  1 18:34:56 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 1 Dec 2021 18:34:56 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v4]
In-Reply-To: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
Message-ID: <KlEUcr5IrpWyOahj_WeBOgFxJB6FFznacsH2uJr-Zg4=.c96272eb-b788-4847-ae9d-3cdf8d038734@github.com>

> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).

Liam Miller-Cushon 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:

  8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6603/files
  - new: https://git.openjdk.java.net/jdk/pull/6603/files/6c858cd8..4166dfd0

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

  Stats: 3103 lines in 138 files changed: 1948 ins; 675 del; 480 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6603.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6603/head:pull/6603

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


From prr at openjdk.java.net  Wed Dec  1 18:34:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 1 Dec 2021 18:34:57 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy
In-Reply-To: <OYJhpnOMxPPAdK4Eq0vTWtvyT2uefgmivsw0KcfvxzU=.bab976ad-ab84-4fd6-8cf4-faf805a54a64@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <OYJhpnOMxPPAdK4Eq0vTWtvyT2uefgmivsw0KcfvxzU=.bab976ad-ab84-4fd6-8cf4-faf805a54a64@github.com>
Message-ID: <HZu4cdQG9eNgD7xdXIHFk2X34ytNoUgQV3sUBEiJCQc=.f0397e25-38dc-43a0-80c2-2fb0ef58d36e@github.com>

On Wed, 1 Dec 2021 04:27:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As of the usefulness of the serializations tests in Swing - it is a good coverage of the cleaning code in the L&fs. Each L&F should clean all its data when the app switch one LF to another, but if old L&F forget to cleanup then the app will get a memory leak.

This test doesn't switch L&Fs .. if it wasn't for mac defaulting to Aqua they'd all be using Metal.

So this is an accidental by-product, not the goal of the test.

And that goal be met by the test writing out the serialized objects and reading them back all at "test time", can't it ?

Seems to me right now we are stumbling over cases where what is serialized is inappropriate for persistent serialization.

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

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


From cushon at openjdk.java.net  Wed Dec  1 18:35:03 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 1 Dec 2021 18:35:03 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v3]
In-Reply-To: <y_5NNZh13M0aOunbDfLa4uwDfBR9DdTol_uTPtYYauM=.e2a4bb86-977c-46db-bc75-a3520239847f@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <y_5NNZh13M0aOunbDfLa4uwDfBR9DdTol_uTPtYYauM=.e2a4bb86-977c-46db-bc75-a3520239847f@github.com>
Message-ID: <mCfIHr_52amMFWR8y6GRc3Fi4uoE7YU_xBUxYSgxgCo=.8c7029b9-5b24-4057-bbd0-36c15ee341aa@github.com>

On Wed, 1 Dec 2021 18:12:51 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Ok the other issue was another instance of the same problem with `BasicPanelUI`.

I now have the test passing on both linux and mac, after regenerating the binary files on mac.

I'm still not sure if this is the best approach, does this fix belong in `BasicPanelUI`? You mentioned fixing 'Aqua to properly delete the references to the Aqua specific objects', does it make sense to handle this in aqua specific code instead?

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

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


From bchristi at openjdk.java.net  Wed Dec  1 19:23:59 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 1 Dec 2021 19:23:59 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal [v3]
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <zORovjOCVMm-8yG6qtNfIrH5ICFkC5WJzL1LKMVyOJ8=.6e92825a-9fc5-4878-9659-aa70da4ed0cc@github.com>

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - Merge branch 'master' into 8276447
 - Merge branch 'master' into 8276447
 - merge
 - @SuppressWarnings(removal) in Windows CKey.java
 - Add jls tag to runFinalization methods
 - Update wording of Object.finalize, new paragraph is now bold
 - update Object.finalize javadoc
 - update Object.finalize JavaDoc and @deprecated tag
 - Update Object.finalize deprecation message
 - Indicate that runFinalizers does nothing if finalization is disabled or removed
 - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674

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

Changes: https://git.openjdk.java.net/jdk/pull/6465/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=02
  Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465

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


From serb at openjdk.java.net  Wed Dec  1 22:18:28 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 1 Dec 2021 22:18:28 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v3]
In-Reply-To: <mCfIHr_52amMFWR8y6GRc3Fi4uoE7YU_xBUxYSgxgCo=.8c7029b9-5b24-4057-bbd0-36c15ee341aa@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <y_5NNZh13M0aOunbDfLa4uwDfBR9DdTol_uTPtYYauM=.e2a4bb86-977c-46db-bc75-a3520239847f@github.com>
 <mCfIHr_52amMFWR8y6GRc3Fi4uoE7YU_xBUxYSgxgCo=.8c7029b9-5b24-4057-bbd0-36c15ee341aa@github.com>
Message-ID: <_vz3JjOjXjatc2N63LFHgHSzMz2e8i26nbjEQ6FAVyo=.abef7fb9-34fa-49b7-86d1-b3f4a5fb21b2@github.com>

On Wed, 1 Dec 2021 18:28:43 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Ok the other issue was another instance of the same problem with `BasicPanelUI`.
> 
> I now have the test passing on both linux and mac, after regenerating the binary files on mac.

> I'm still not sure if this is the best approach, does this fix belong in `BasicPanelUI`? You mentioned fixing 'Aqua to properly delete the references to the Aqua specific objects', does it make sense to handle this in aqua specific code instead?

Usually the delegate which install some properties/listeners/etc is responsible for cleanup.

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

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


From serb at openjdk.java.net  Wed Dec  1 22:18:28 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 1 Dec 2021 22:18:28 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy
In-Reply-To: <HZu4cdQG9eNgD7xdXIHFk2X34ytNoUgQV3sUBEiJCQc=.f0397e25-38dc-43a0-80c2-2fb0ef58d36e@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <OYJhpnOMxPPAdK4Eq0vTWtvyT2uefgmivsw0KcfvxzU=.bab976ad-ab84-4fd6-8cf4-faf805a54a64@github.com>
 <HZu4cdQG9eNgD7xdXIHFk2X34ytNoUgQV3sUBEiJCQc=.f0397e25-38dc-43a0-80c2-2fb0ef58d36e@github.com>
Message-ID: <dy0rAsksagY2EmZ4uq0_568lAwGldXlXmbQlIsjYcIQ=.a69c018b-47ab-40a8-b436-75f333f4a000@github.com>

On Wed, 1 Dec 2021 18:28:13 GMT, Phil Race <prr at openjdk.org> wrote:

> This test doesn't switch L&Fs .. if it wasn't for mac defaulting to Aqua they'd all be using Metal.

It does not change the L&F but it will trigger the same cleanup step.

> So this is an accidental by-product, not the goal of the test.

yes we found one additional product bug.

> And that goal be met by the test writing out the serialized objects and reading them back all at "test time", can't it ?

No it cannot write and read it back in during test execution, the binary files should be created on the "patched" version of JDK.

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

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


From serb at openjdk.java.net  Wed Dec  1 22:45:24 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 1 Dec 2021 22:45:24 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v5]
In-Reply-To: <z9mC6c44JuBjy1SA6crXIOPuLhQhKGDiy4Zztn-yo7k=.2a52d334-0ec9-46a4-b038-4de68243d132@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
 <z9mC6c44JuBjy1SA6crXIOPuLhQhKGDiy4Zztn-yo7k=.2a52d334-0ec9-46a4-b038-4de68243d132@github.com>
Message-ID: <qvNTKq6m78KedXfUASlA4SkP0Ds7sF8hpTiBib5REHs=.9108f4be-e1a7-4596-ad3f-1aa49ca00757@github.com>

On Wed, 1 Dec 2021 12:25:56 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> Testing https://bugs.openjdk.java.net/browse/JDK-8271071 
>> Step to reproduce 
>> 1) Run SwingSet2 in JDK 18 ( I used b24 ) 
>> 2) Enable Voiceover. 
>> 3) Select JTable demo 
>> 4) Click any row in the table or select the first row . Observe that row is selected & VoiceOver reads the column values or navigate the columns one by one by pressing tab key. When the focus reaches the last column ( Favourite Food ) Observe that column value is read as null. If you hear the same then the bug is reproduced.
>
> Artem Semenov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

src/java.desktop/share/classes/javax/swing/JLabel.java line 1110:

> 1108:                     }
> 1109:                 }
> 1110:                 if ((name == null) || name.isEmpty()) {

I continue our discussion from code line above.

Why for the empty label and non-accessible image we should say "image", and not for example the "empty label" or just ignore it? 

I mean that if the icon used by the label does not have an "accessible" icon, or any other accessible component why we will try to mention it to the user?

If non-accessible component should not be mentioned to user then you do not need to add a new code here, we already have the "getAccessibleIcon" method which can be called for example from the "CAccessibility" every time we request name/description/text and it empty while the icon is not null and accessible - this will cover all  accesible components not only JLabel.

BTW it could be a SwingSet/App bug that the provided image does not have a description (similar to the common bug in html when the image tag does not have an alt).

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

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


From cushon at openjdk.java.net  Wed Dec  1 22:56:28 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 1 Dec 2021 22:56:28 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v3]
In-Reply-To: <_vz3JjOjXjatc2N63LFHgHSzMz2e8i26nbjEQ6FAVyo=.abef7fb9-34fa-49b7-86d1-b3f4a5fb21b2@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <y_5NNZh13M0aOunbDfLa4uwDfBR9DdTol_uTPtYYauM=.e2a4bb86-977c-46db-bc75-a3520239847f@github.com>
 <mCfIHr_52amMFWR8y6GRc3Fi4uoE7YU_xBUxYSgxgCo=.8c7029b9-5b24-4057-bbd0-36c15ee341aa@github.com>
 <_vz3JjOjXjatc2N63LFHgHSzMz2e8i26nbjEQ6FAVyo=.abef7fb9-34fa-49b7-86d1-b3f4a5fb21b2@github.com>
Message-ID: <mrxWcG3UfSrqErLvbFO9Xc-Re5iG-YzQFqSX43l0DMc=.1aba1cef-c56a-489b-aa9f-164ece79a614@github.com>

On Wed, 1 Dec 2021 22:14:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Usually the delegate which install some properties/listeners/etc is responsible for cleanup.

I'm not sure I understand, aren't these being installed in `BasicPanelUI`?

https://github.com/openjdk/jdk/blob/4166dfd004d16769f8ea1d3441d3d19dedfd6867/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPanelUI.java#L81-L85

Would it make sense to create a corresponding `LookAndFeel.installColorsAndFont` method that would be called from `BasicPanelUI. uninstallDefaults`?

(Sorry for the naive questions here--as I mentioned I started investigating this when I thought it was related to JDK-8271623, and am not familiar with this code.)

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

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


From serb at openjdk.java.net  Thu Dec  2 00:03:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Dec 2021 00:03:31 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v5]
In-Reply-To: <qvNTKq6m78KedXfUASlA4SkP0Ds7sF8hpTiBib5REHs=.9108f4be-e1a7-4596-ad3f-1aa49ca00757@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
 <z9mC6c44JuBjy1SA6crXIOPuLhQhKGDiy4Zztn-yo7k=.2a52d334-0ec9-46a4-b038-4de68243d132@github.com>
 <qvNTKq6m78KedXfUASlA4SkP0Ds7sF8hpTiBib5REHs=.9108f4be-e1a7-4596-ad3f-1aa49ca00757@github.com>
Message-ID: <HL1lu9Eh1nHTkr8qVN-vScbpF_5_ESEe03e3bLzLKEg=.9b6e208c-8060-4906-969d-49648cf96311@github.com>

On Wed, 1 Dec 2021 22:41:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Artem Semenov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8277497: Last column cell in the JTAble row is read as empty cell
>
> src/java.desktop/share/classes/javax/swing/JLabel.java line 1110:
> 
>> 1108:                     }
>> 1109:                 }
>> 1110:                 if ((name == null) || name.isEmpty()) {
> 
> I continue our discussion from code line above.
> 
> Why for the empty label and non-accessible image we should say "image", and not for example the "empty label" or just ignore it? 
> 
> I mean that if the icon used by the label does not have an "accessible" icon, or any other accessible component why we will try to mention it to the user?
> 
> If non-accessible component should not be mentioned to user then you do not need to add a new code here, we already have the "getAccessibleIcon" method which can be called for example from the "CAccessibility" every time we request name/description/text and it empty while the icon is not null and accessible - this will cover all  accesible components not only JLabel.
> 
> BTW it could be a SwingSet/App bug that the provided image does not have a description (similar to the common bug in html when the image tag does not have an alt).

Looks like If the change will be done in the "CAccessibility" it will cover the custom components as well.

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

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


From serb at openjdk.java.net  Thu Dec  2 00:13:27 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Dec 2021 00:13:27 GMT
Subject: RFR: 8266435: WBMPImageReader.read() should not truncate the input
 stream
In-Reply-To: <iLTDuw7aF9WP50tRBAoAVPQzOks1qXjdaTJY-dCk3jo=.4c1d28d5-5dd9-4cfb-90dd-c66472f5a410@github.com>
References: <dgFDpOpF6ONZCwgc9eJxvqQcESf8-WmmLAi4eHNeJjg=.33280dd0-fbff-4fa7-a90f-d6b9d7f35225@github.com>
 <icd3sXDFOf8TQx78hDgO9wULkZ0ah_yVrNvrQESsB0k=.f091df72-107b-4208-b651-9e142b60665e@github.com>
 <iLTDuw7aF9WP50tRBAoAVPQzOks1qXjdaTJY-dCk3jo=.4c1d28d5-5dd9-4cfb-90dd-c66472f5a410@github.com>
Message-ID: <uFwC7blqHHeyj7H1uZOkuYK3ffahcSMpGvPnijerYrY=.33d2acde-2958-44c2-9392-ed0568d6cc58@github.com>

On Wed, 1 Dec 2021 06:12:29 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> test/jdk/javax/imageio/plugins/wbmp/WBMPStreamTruncateTest.java line 61:
>> 
>>> 59:         File imageFile = File.
>>> 60:                 createTempFile("test", ".wbmp", new File(filePath));
>>> 61:         imageFile.deleteOnExit();
>> 
>> In one another review I saw the deleteOnExit() usage, I remember that in case of full testrun via makefile, such files were not deleted, can you please confirm that it is work fine? probably that it was fixed already. Note that the full test run uses custom tmp folder inside the result dir.
>
> @mrserb I ran the test using "make test" and i dont see any .wbmp file after test run in results directory.
> Also i verified that it doesn't leave any image in test directory of CI machines.

Ok, thank you for confirmation.

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

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


From serb at openjdk.java.net  Thu Dec  2 00:29:27 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Dec 2021 00:29:27 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v3]
In-Reply-To: <mrxWcG3UfSrqErLvbFO9Xc-Re5iG-YzQFqSX43l0DMc=.1aba1cef-c56a-489b-aa9f-164ece79a614@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <y_5NNZh13M0aOunbDfLa4uwDfBR9DdTol_uTPtYYauM=.e2a4bb86-977c-46db-bc75-a3520239847f@github.com>
 <mCfIHr_52amMFWR8y6GRc3Fi4uoE7YU_xBUxYSgxgCo=.8c7029b9-5b24-4057-bbd0-36c15ee341aa@github.com>
 <_vz3JjOjXjatc2N63LFHgHSzMz2e8i26nbjEQ6FAVyo=.abef7fb9-34fa-49b7-86d1-b3f4a5fb21b2@github.com>
 <mrxWcG3UfSrqErLvbFO9Xc-Re5iG-YzQFqSX43l0DMc=.1aba1cef-c56a-489b-aa9f-164ece79a614@github.com>
Message-ID: <q2Zn9vSy900JJ3BrNB9WwjHI47iIZtsikHniLIB25og=.28a6ae10-2367-4f94-878d-5ca9812a8c0d@github.com>

On Wed, 1 Dec 2021 22:53:47 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> I'm not sure I understand, aren't these being installed in `BasicPanelUI`?

If it is installs in the BasicListUI only then yes the fix belongs to this class. These properties changing also in some other classes as well, but some other classes cleanup it properly for example see BasicListUI.uninstallDefaults(), but I am not sure that all of them do this.

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

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


From serb at openjdk.java.net  Thu Dec  2 00:53:27 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Dec 2021 00:53:27 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows [v3]
In-Reply-To: <xH3TupkjWB_vf4TLi9gu1HBVki8MO0SmkTPZtPzLGlc=.e11331c3-c639-4b47-8138-23992aaa1e27@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
 <vZdJqlPw_-3v2JnC8K4qxzW8SCwPCvQcbUmy9X4jBRs=.20d73184-0584-4058-8e2d-02d62957592b@github.com>
 <xH3TupkjWB_vf4TLi9gu1HBVki8MO0SmkTPZtPzLGlc=.e11331c3-c639-4b47-8138-23992aaa1e27@github.com>
Message-ID: <l3cNPeoV0gh2UhSU-pQbfDaEVujGRzUrqgWHtbUcJOY=.6ea85ba3-5d76-4a99-a815-1c9f5f227b69@github.com>

On Fri, 26 Nov 2021 11:50:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The error occurs when starting the tests from the Windows Task scheduler; however when running from the task scheduler the error occurs with the fastdebug-JVM not when running the opt/product JVM.

Probably in that case we try to log something and that logging include jni upcall?

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

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


From smarks at openjdk.java.net  Thu Dec  2 01:26:30 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 2 Dec 2021 01:26:30 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal [v3]
In-Reply-To: <zORovjOCVMm-8yG6qtNfIrH5ICFkC5WJzL1LKMVyOJ8=.6e92825a-9fc5-4878-9659-aa70da4ed0cc@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
 <zORovjOCVMm-8yG6qtNfIrH5ICFkC5WJzL1LKMVyOJ8=.6e92825a-9fc5-4878-9659-aa70da4ed0cc@github.com>
Message-ID: <nJKHDn0E59sPCmNw72xg_Pm22IB4JtQmufM09mM7Dek=.9e48eca8-07c1-40b2-ad90-4c8df399b59e@github.com>

On Wed, 1 Dec 2021 19:23:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
>> 
>> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
>> 
>> The CSR has been approved.
>> An automated test build+test run passes cleanly (FWIW :D ).
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - Merge branch 'master' into 8276447
>  - Merge branch 'master' into 8276447
>  - merge
>  - @SuppressWarnings(removal) in Windows CKey.java
>  - Add jls tag to runFinalization methods
>  - Update wording of Object.finalize, new paragraph is now bold
>  - update Object.finalize javadoc
>  - update Object.finalize JavaDoc and @deprecated tag
>  - Update Object.finalize deprecation message
>  - Indicate that runFinalizers does nothing if finalization is disabled or removed
>  - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674

Marked as reviewed by smarks (Reviewer).

src/jdk.jconsole/share/classes/sun/tools/jconsole/SummaryTab.java line 116:

> 114:     StringBuilder buf;
> 115: 
> 116:     @SuppressWarnings("deprecation")

Item for future cleanup: refactor the call to `getObjectPendingFinalizationCount()` at line 219 (!) into a local variable declaration, and then move the warnings suppression to that declaration. This reduces the scope of warnings suppression.

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

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


From jdv at openjdk.java.net  Thu Dec  2 05:04:31 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 2 Dec 2021 05:04:31 GMT
Subject: Integrated: 8266435: WBMPImageReader.read() should not truncate the
 input stream
In-Reply-To: <dgFDpOpF6ONZCwgc9eJxvqQcESf8-WmmLAi4eHNeJjg=.33280dd0-fbff-4fa7-a90f-d6b9d7f35225@github.com>
References: <dgFDpOpF6ONZCwgc9eJxvqQcESf8-WmmLAi4eHNeJjg=.33280dd0-fbff-4fa7-a90f-d6b9d7f35225@github.com>
Message-ID: <Hm7F5q8uOUHSsbiINMwVmCT2m7PdvUNOLn-kKE_7VNk=.69ab3570-6149-4673-becd-262ce70730df@github.com>

On Tue, 23 Nov 2021 11:05:27 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> If we use a custom stream and specify limit on stream.read() length, WBMPImageReader.read() doesnt verify whether we are decoded complete data or not. We can check the length of data decoded and rerun the stream.read() or use readFully(). In case of other decoders like BMP we are using readFully(), so i have updated WBMPImageReader.read() to use readFully().

This pull request has now been integrated.

Changeset: 8198807b
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8198807b4a811040c7d9f65fb98494fc7d840814
Stats:     122 lines in 2 files changed: 118 ins; 0 del; 4 mod

8266435: WBMPImageReader.read() should not truncate the input stream

Reviewed-by: serb

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

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


From jdv at openjdk.java.net  Thu Dec  2 05:42:27 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 2 Dec 2021 05:42:27 GMT
Subject: RFR: 8272392 Lanai: SwingSet2. Black background on expanding tree
 node [v2]
In-Reply-To: <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>
References: <j43XsVmt-JoPBbf2zmSprcycbHlkZF2GSBXas3T7BRk=.fcee72ac-9edf-423d-b71d-89612e6d2e52@github.com>
 <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>
Message-ID: <4YShRQ35kVnGeZrS_HwO6ki-M2WZOYifQgL6kyECNPk=.f27fc2c0-8647-43b6-bbe0-5c7530636c18@github.com>

On Fri, 26 Nov 2021 09:02:37 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Removed creation of the separate encoder depending on destination properties as we don't use this info to customize the encoder properties
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272392 Lanai: SwingSet2. Black background on expanding tree node
>   
>   Fixed incorrect addition of the values into pipeline state cache. Refactored index initialization. Removed unused flags from MTLClip.

jtreg & JCK tests are not showing any major failures in our CI with this patch.

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

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


From cushon at openjdk.java.net  Thu Dec  2 06:27:01 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Thu, 2 Dec 2021 06:27:01 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v5]
In-Reply-To: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
Message-ID: <lsnERzsABwhOgn2Itr7MazN_fUZBEH_nB9e_j7g_7BY=.6b45f8fc-9537-40dc-979c-1d5f8e1aec26@github.com>

> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Add uninstallColorsAndFont

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6603/files
  - new: https://git.openjdk.java.net/jdk/pull/6603/files/4166dfd0..de2e597e

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

  Stats: 70 lines in 21 files changed: 57 ins; 10 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6603.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6603/head:pull/6603

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


From cushon at openjdk.java.net  Thu Dec  2 06:27:02 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Thu, 2 Dec 2021 06:27:02 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v3]
In-Reply-To: <q2Zn9vSy900JJ3BrNB9WwjHI47iIZtsikHniLIB25og=.28a6ae10-2367-4f94-878d-5ca9812a8c0d@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <y_5NNZh13M0aOunbDfLa4uwDfBR9DdTol_uTPtYYauM=.e2a4bb86-977c-46db-bc75-a3520239847f@github.com>
 <mCfIHr_52amMFWR8y6GRc3Fi4uoE7YU_xBUxYSgxgCo=.8c7029b9-5b24-4057-bbd0-36c15ee341aa@github.com>
 <_vz3JjOjXjatc2N63LFHgHSzMz2e8i26nbjEQ6FAVyo=.abef7fb9-34fa-49b7-86d1-b3f4a5fb21b2@github.com>
 <mrxWcG3UfSrqErLvbFO9Xc-Re5iG-YzQFqSX43l0DMc=.1aba1cef-c56a-489b-aa9f-164ece79a614@github.com>
 <q2Zn9vSy900JJ3BrNB9WwjHI47iIZtsikHniLIB25og=.28a6ae10-2367-4f94-878d-5ca9812a8c0d@github.com>
Message-ID: <s2cyjzPB8N_dtZ_jE6kvH0FCqvKHV4HAy8cyISg67MU=.be97b3d2-d0b4-4aa4-bc3f-61a14f8bc8ea@github.com>

On Thu, 2 Dec 2021 00:26:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> These properties changing also in some other classes as well, but some other classes cleanup it properly for example see BasicListUI.uninstallDefaults(), but I am not sure that all of them do this.

I looked through other uses of `installColorsAndFont`, and most of them don't seem to be uninstalling the properties. I updated the ones I found, and added a `uninstallColorsAndFont` method to avoid copying the logic around.

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

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


From psadhukhan at openjdk.java.net  Thu Dec  2 08:19:41 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 2 Dec 2021 08:19:41 GMT
Subject: RFR: 8172065: javax/swing/JTree/4908142/bug4908142.java The selected
 index should be aad
Message-ID: <1bFLgdrkpH1rWjwpQS16m87kA1E4Z35C2STeYWyDCrA=.73d51aaf-ad43-4470-a1aa-aa8d026ce7d8@github.com>

Test is failing in macosx-12 in aarch64 system. Added stability fixes of delay after frame is visible, making frame to center of screen to make the test stable in macos12-aarch64 system too.
Modified test passes in all CI platforms including osx-aarch64 system in osx11 and osx12.

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

Commit messages:
 - 8172065: javax/swing/JTree/4908142/bug4908142.java The selected index should be aad

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

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


From psadhukhan at openjdk.java.net  Thu Dec  2 08:37:36 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 2 Dec 2021 08:37:36 GMT
Subject: RFR: 8278119: ProblemList few headful test failing in macosx12-aarch64
 system
Message-ID: <d0l3FH5X7vlqm6Cw4wwx9AV_1QWexJ-ckTCtKMu2IwA=.af9c4737-afee-497b-86fe-8cf15a519950@github.com>

Few tests are failing on macos12-aarch64 systems due to mismatch in color value obtained from robot.getPixelColor and expected color.
More details on the failures can be seen in JDK-8277816. Till the root cause is investigated, it is better to problemlist it as it causing failures in CI run.

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

Commit messages:
 - 8278119: ProblemList few headful test failing in macosx12-aarch64 system
 - 8278119: ProblemList few headful test failing in macosx12-aarch64 system

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

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


From lbourges at openjdk.java.net  Thu Dec  2 08:50:30 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 2 Dec 2021 08:50:30 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v10]
In-Reply-To: <W1sc79kkjjEU2gMwVffM-tW9nvdr4hIkRNvWJrkPzXY=.0d9881e6-2761-4fe2-81e3-86abb50fd5ca@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <W1sc79kkjjEU2gMwVffM-tW9nvdr4hIkRNvWJrkPzXY=.0d9881e6-2761-4fe2-81e3-86abb50fd5ca@github.com>
Message-ID: <3uufgOtPTZSkBTdD-OZNpoFkhB10u74Ir66bQ1-5uP4=.8acd2a40-bb4c-4fb3-8be2-fc0110f51171@github.com>

On Fri, 19 Nov 2021 19:09:54 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   Addressing code review feedback: "Use BigDecomal.setScale(40) to ascertain precision."
>   
>   The geom.* unit tests passed before & after this change.
>   
>   https://github.com/openjdk/jdk/pull/6227#discussion_r752908494

@jddarcy could you have a look on FP Math precision ?

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

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


From dbatrak at openjdk.java.net  Thu Dec  2 09:43:24 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Thu, 2 Dec 2021 09:43:24 GMT
Subject: RFR: 8278050: Armenian text isn't rendered on macOS if text layout
 is performed
In-Reply-To: <dTa8ToEjtbOZm9JzLxUn7SY8quVuPDr-wYm6-Myr8k8=.a1f7c769-7df9-45a7-bf21-caad4ec8af06@github.com>
References: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
 <dTa8ToEjtbOZm9JzLxUn7SY8quVuPDr-wYm6-Myr8k8=.a1f7c769-7df9-45a7-bf21-caad4ec8af06@github.com>
Message-ID: <IN5PSt1iLlQ696Z9faeCUkPKm9Iu_FjMa5V1VlRlMIo=.305bb864-68f0-4248-adb0-c4b21315b71c@github.com>

On Wed, 1 Dec 2021 17:34:58 GMT, Phil Race <prr at openjdk.org> wrote:

> FWIW the rendering being present in the non-layout case is likely due to the magic JRS fall back code .. some day we need to unify this so that at least we are consistent.

That's what I'm working on now - getting rid of `JRSFontCreateFallbackFontForCharacters` and replace it with cascade list approach. The plan is to have it tested with JetBrains Runtime first (both internally and with external users). If all goes well, I'll submit corresponding PR in several months, after our IDEs' next public release.

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

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


From achung at openjdk.java.net  Thu Dec  2 19:57:54 2021
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 2 Dec 2021 19:57:54 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v7]
In-Reply-To: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
Message-ID: <29otHmFYbrgY0zuOeXw2NFz5V2Q0YZIKu18THN1yGPQ=.3ca8bf18-8c44-402c-a971-eece3da26c4c@github.com>

> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.

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

  removed robot mouse moves, use pixel colors to check

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6374/files
  - new: https://git.openjdk.java.net/jdk/pull/6374/files/02ae001c..52edbf4e

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

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

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


From achung at openjdk.java.net  Thu Dec  2 20:22:16 2021
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 2 Dec 2021 20:22:16 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v4]
In-Reply-To: <heJWxX2cWSgjLWJPo2p-AJEoLSONuHy3xsiU1z6gEPA=.da4827c5-ee15-43ab-a3fd-3847ea5b6ed5@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <icSGKnOryPHI_yd-HKjSmURmjwpfb0joZm533GHrsEo=.231a05f3-31a7-4c31-8aa1-01aa0ea5fe8f@github.com>
 <zxNsIG35aBhe9D8ry7rs8s1vnYtqZXcVSj13IGwYPs4=.baeb4de9-3292-4a97-9cc0-f441aebd1b12@github.com>
 <lL2zcy61qbI4QXPWknffRqvgQfU3zS49BvrUQFgrSXE=.fe7927c5-e2fc-4ea5-a852-2773e841de21@github.com>
 <heJWxX2cWSgjLWJPo2p-AJEoLSONuHy3xsiU1z6gEPA=.da4827c5-ee15-43ab-a3fd-3847ea5b6ed5@github.com>
Message-ID: <mmmup2BcJqqo5hEL_kZQox0XclYD8JcNhNy44C-ufTc=.7b8b7759-2920-48eb-9e57-193ea37d97e5@github.com>

On Wed, 24 Nov 2021 06:07:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Just updated the automation. I added a robot to try to move the thumb into the red zone, then had the robot click again to see if the thumb is under the cursor. If the behavior is correct, the thumb should have stopped before entering the red zone and scrollbar mouseListener should only detect 1 click. Otherwise it will detect 2 clicks (thumb is under cursor) and test fails. Is my logic correct?
>
> But it is not necessary to use the robot at all? Can you try to set the scollbar thumb position/move it programmatically w/o a robot? If it is possible then it will be rendered on top of the red area -> it will be possible to render it to the buffered image and just check the pixel in the right position(is it red or not).

Is using robot to get the pixel color alright?

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

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


From duke at openjdk.java.net  Thu Dec  2 21:02:40 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Dec 2021 21:02:40 GMT
Subject: RFR: JDK-8276681: Malformed Javadoc inline tags in JDK source
 jdk/internal/net/http/ResponseSubscribers.java
Message-ID: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>

JDK-8276681: Malformed Javadoc inline tags in JDK source jdk/internal/net/http/ResponseSubscribers.java

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

Commit messages:
 - Merge branch 'master' into JDK-8276681
 - Fix missing '@' in javadoc for JDK-8276681

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

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


From aivanov at openjdk.java.net  Thu Dec  2 21:02:23 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 2 Dec 2021 21:02:23 GMT
Subject: Integrated: JDK-8277396: [TESTBUG] In
 DefaultButtonModelCrashTest.java, frame is accessed from main thread
In-Reply-To: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
References: <OAy9L-TVBAxbz8CKnM4LTRzJqydEsFdQCbF_1Uj4j84=.97cca419-3d46-420f-a269-81f1ca04a552@github.com>
Message-ID: <kJZqIbqIeCHVT1cQvf7e7llyvkn_eGXN8mZaDuY-4a8=.0147e991-c2b8-4541-a181-23c82e293960@github.com>

On Thu, 18 Nov 2021 13:17:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> It's a little cleanup: make sure `frame` is accessed from EDT only, remove unused variables and imports.

This pull request has now been integrated.

Changeset: b310f301
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b310f301efd5390408fb56b62cc09eb9a1604413
Stats:     23 lines in 1 file changed: 9 ins; 8 del; 6 mod

8277396: [TESTBUG] In DefaultButtonModelCrashTest.java, frame is accessed from main thread

Reviewed-by: serb, psadhukhan

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

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


From lancea at openjdk.java.net  Thu Dec  2 21:08:17 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 2 Dec 2021 21:08:17 GMT
Subject: RFR: JDK-8276681: Malformed Javadoc inline tags in JDK source
 jdk/internal/net/http/ResponseSubscribers.java
In-Reply-To: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
References: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
Message-ID: <BirNhh9Ja_VPIbBsvqXQE9qnyVxSyIi1FqufTfgDhR0=.20a63cea-3b4d-4d8f-9f23-8e060321eff0@github.com>

On Sat, 20 Nov 2021 04:09:51 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8276681: Malformed Javadoc inline tags in JDK source jdk/internal/net/http/ResponseSubscribers.java

Marked as reviewed by lancea (Reviewer).

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

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


From duke at openjdk.java.net  Thu Dec  2 21:25:53 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Dec 2021 21:25:53 GMT
Subject: RFR: JDK-8276681: Additional malformed Javadoc inline tags in JDK
 source [v2]
In-Reply-To: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
References: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
Message-ID: <GbmF-XM7XVPim_elGvQ6JdprN0moW9rcXDFloSFV32g=.5df294e6-a3f0-4043-bd7b-aebef585ba87@github.com>

> JDK-8276681: Additional malformed Javadoc inline tags in JDK source

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

 - Merge branch 'master' into JDK-8276681
 - Merge branch 'master' into JDK-8276681
 - Fix missing '@' in javadoc for JDK-8276681

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6486/files
  - new: https://git.openjdk.java.net/jdk/pull/6486/files/e8071197..8eaf05bc

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

  Stats: 29529 lines in 653 files changed: 17761 ins; 7341 del; 4427 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6486.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6486/head:pull/6486

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


From duke at openjdk.java.net  Thu Dec  2 21:25:54 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Dec 2021 21:25:54 GMT
Subject: Integrated: JDK-8276681: Additional malformed Javadoc inline tags in
 JDK source
In-Reply-To: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
References: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
Message-ID: <bWDNIhKSRZioOMEelJEP6XLFWIVlsL4db0dq8ci1uc8=.65ffd2fa-81ab-43c5-9b2e-f16adc02e97f@github.com>

On Sat, 20 Nov 2021 04:09:51 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8276681: Additional malformed Javadoc inline tags in JDK source

This pull request has now been integrated.

Changeset: b8ac0d20
Author:    Tim Prinzing <tim.prinzing at oracle.com>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b8ac0d20ceec26b3a1dd0b9577817fa6320ea9ef
Stats:     11 lines in 9 files changed: 0 ins; 0 del; 11 mod

8276681: Additional malformed Javadoc inline tags in JDK source

Reviewed-by: lancea

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

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


From kizune at openjdk.java.net  Thu Dec  2 22:05:00 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 2 Dec 2021 22:05:00 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits [v3]
In-Reply-To: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
Message-ID: <lGOPpqu2uYGZHV_GkjysSB5dyq9Z9AOEIRZbr_vMahU=.398430c1-2050-4c19-a352-fe4738507ca2@github.com>

> Made colorBits and maskBits arrays dynamic so they are allocated on heap instead of stack.
> Added regression test.

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

  Eliminate potential resource leak.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6473/files
  - new: https://git.openjdk.java.net/jdk/pull/6473/files/16d3eadc..c8d8ee23

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

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

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


From kizune at openjdk.java.net  Thu Dec  2 22:05:05 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 2 Dec 2021 22:05:05 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits [v2]
In-Reply-To: <MQgleFlF0fjC7LpAsyLD7g-ok0uCqyGSihb3t-E8ybo=.7e85045f-e327-45f7-8634-ae88edf0df4f@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
 <eSI-MbnnR26q3Ic8BsE0XbZnC89i-bkpE-1OU5JcB7s=.0f6b3395-c28b-427e-9612-b3bd56187303@github.com>
 <MQgleFlF0fjC7LpAsyLD7g-ok0uCqyGSihb3t-E8ybo=.7e85045f-e327-45f7-8634-ae88edf0df4f@github.com>
Message-ID: <0rffkwaE4OTR6mh-HQ3dYMZa0eCv8BtCZxi3Xva63Jw=.240921f3-f3b9-4dbd-b9cf-7f7e4c076d08@github.com>

On Mon, 22 Nov 2021 19:13:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added bad_malloc handling
>>   Fixed insets
>>   Declaration and assignment are now joined
>
> src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1097:
> 
>> 1095:             free(colorBits);
>> 1096: 
>> 1097:             CATCH_BAD_ALLOC_RET(NULL);
> 
> I believe we leak `dc` as well as `iconInfo.hbmColor` and `iconInfo.hbmMask` if `std::bad_alloc` is thrown.

Fixed. Now we will release these resources on exit in case of bad_alloc.

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

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


From darcy at openjdk.java.net  Fri Dec  3 01:25:33 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 3 Dec 2021 01:25:33 GMT
Subject: RFR: JDK-8278175: Enable all doclint warnings for build of
 java.desktop
Message-ID: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>

In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

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

Commit messages:
 - JDK-8278175: Enable all doclint warnings for build of java.desktop

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

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


From jjg at openjdk.java.net  Fri Dec  3 01:41:15 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 3 Dec 2021 01:41:15 GMT
Subject: RFR: JDK-8278175: Enable all doclint warnings for build of
 java.desktop
In-Reply-To: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
References: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
Message-ID: <yjrXkkRAV00sp4zj3ioEVzJmQ1OTb6dWWYcK37P0f_c=.ac1be279-c5f8-416f-bd05-81cbfafe0b67@github.com>

On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

Looks OK to me, although I don't consider myself a Reviewer for this code.

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

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


From duke at openjdk.java.net  Fri Dec  3 05:14:19 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 3 Dec 2021 05:14:19 GMT
Subject: Withdrawn: 8274304: Update or Problem List tests which may fail with
 uiScale=2 on macOS
In-Reply-To: <j-ULwTmOaaJyAo9uzLv-mI9OLjIvpEVoE1iY52j_vv0=.98b2f37f-d11d-49fb-a2ab-dd6472829db7@github.com>
References: <j-ULwTmOaaJyAo9uzLv-mI9OLjIvpEVoE1iY52j_vv0=.98b2f37f-d11d-49fb-a2ab-dd6472829db7@github.com>
Message-ID: <6aPAeqyJ3aFe-x8ykt9LrDUcKkBbjWqbj9YKkrN2tyE=.5b61da18-2a56-4f1b-a1ad-3d4c262b0f08@github.com>

On Thu, 30 Sep 2021 04:43:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The fix for 8274296 added uiScale=1 to some of the tests to fix the problem of incorrect pixel color capture by the robot.
> In both cases uiScale=1 or uiScale=2 the same call should be made to the macOS. But if uiScale=1 is set we just read one pixel on the screen, but if uiScale=2 is set we prepare the data in some clumsy way(at the end we should also read just one pixel).
> 
> Since uiScale=1 affects the test case execution means that we probably have some bugs in the coordinate/size calculation of the area. Note that none of these tests have dependencies on the precise rendering, so it is quite a common use-case and may affect any external applications.
> 
> This is a request to update the https://github.com/openjdk/jdk/pull/5687/files
> and move all tests to the problem list.

This pull request has been closed without being integrated.

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

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


From psadhukhan at openjdk.java.net  Fri Dec  3 06:18:43 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 3 Dec 2021 06:18:43 GMT
Subject: RFR: 8172065: javax/swing/JTree/4908142/bug4908142.java The
 selected index should be "aad" [v2]
In-Reply-To: <1bFLgdrkpH1rWjwpQS16m87kA1E4Z35C2STeYWyDCrA=.73d51aaf-ad43-4470-a1aa-aa8d026ce7d8@github.com>
References: <1bFLgdrkpH1rWjwpQS16m87kA1E4Z35C2STeYWyDCrA=.73d51aaf-ad43-4470-a1aa-aa8d026ce7d8@github.com>
Message-ID: <cIiNd7_OlcuF54mLU-tXw38x6-qA_elCpSSKYQMRHD4=.c46ab68f-9b52-45e4-ade5-bd4c811db50c@github.com>

> Test is failing in macosx-12 in aarch64 system. Added stability fixes of delay after frame is visible, making frame to center of screen to make the test stable in macos12-aarch64 system too.
> Modified test passes in all CI platforms including osx-aarch64 system in osx11 and osx12.

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

  Add waitForIdle

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6661/files
  - new: https://git.openjdk.java.net/jdk/pull/6661/files/4f267d7f..6d561fa0

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

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

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


From duke at openjdk.java.net  Fri Dec  3 06:41:43 2021
From: duke at openjdk.java.net (ANUPAM DEV)
Date: Fri, 3 Dec 2021 06:41:43 GMT
Subject: RFR: 8247973: Javadoc incorrect for IdentityArrayList,
 IdentityLinkedList
Message-ID: <LACyavvgS7OmNoMGbfv5tlwXpaoHmqq5A4zu-uQpN0M=.f6be9232-a5e7-42ca-a4c4-8f9a17ae9a24@github.com>

Updated sun.awt.util.IdentityArrayList and sun.awt.util.IdentityLinkedList

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

Commit messages:
 - Javadoc incorrect for IdentityArrayList, IdentityLinkedList
 - Merge pull request #1 from anupamdev20/JDK-8255675
 - 8255675: Typo in java.net.HttpURLConnection

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

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


From duke at openjdk.java.net  Fri Dec  3 06:55:23 2021
From: duke at openjdk.java.net (ANUPAM DEV)
Date: Fri, 3 Dec 2021 06:55:23 GMT
Subject: Withdrawn: 8247973: Javadoc incorrect for IdentityArrayList,
 IdentityLinkedList
In-Reply-To: <LACyavvgS7OmNoMGbfv5tlwXpaoHmqq5A4zu-uQpN0M=.f6be9232-a5e7-42ca-a4c4-8f9a17ae9a24@github.com>
References: <LACyavvgS7OmNoMGbfv5tlwXpaoHmqq5A4zu-uQpN0M=.f6be9232-a5e7-42ca-a4c4-8f9a17ae9a24@github.com>
Message-ID: <T4IO8ZK4frUuSuELDuw-pg2ASjVxBcHhwL4M9npDFoc=.b90978d6-36e1-4b16-a5be-b9815c4fff77@github.com>

On Fri, 3 Dec 2021 06:33:45 GMT, ANUPAM DEV <duke at openjdk.java.net> wrote:

> The following methods were having improper improper as they mentioned 'equals()' while comparing two objects. The comments have been changed to reflect the comparison of two objects using == operator.
> 
> sun.awt.util.IdentityLinkedList#contains
> sun.awt.util.IdentityArrayList#contains
> sun.awt.util.IdentityArrayList#indexOf
> sun.awt.util.IdentityArrayList#lastIndexOf
> sun.awt.util.IdentityArrayList#remove(java.lang.Object) 
> 
> Please review the changes.
> Thanks!

This pull request has been closed without being integrated.

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

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


From duke at openjdk.java.net  Fri Dec  3 07:41:31 2021
From: duke at openjdk.java.net (ANUPAM DEV)
Date: Fri, 3 Dec 2021 07:41:31 GMT
Subject: RFR: 8247973: Javadoc incorrect for IdentityArrayList,
 IdentityLinkedList
Message-ID: <M8D6vzLV708k3DW5xYBFws6TEvcbxx6aN0Bn9frPNKA=.31525fad-c291-4954-9edd-5005147158e7@github.com>

The documentation for following methods used equals() for object equality:

sun.awt.util.IdentityLinkedList#contains
sun.awt.util.IdentityArrayList#contains
sun.awt.util.IdentityArrayList#indexOf
sun.awt.util.IdentityArrayList#lastIndexOf
sun.awt.util.IdentityArrayList#remove(java.lang.Object)

I have updated the comments to use "==" operator for object equality. Kindly review the changes for the same.

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

Commit messages:
 - 8247973: Javadoc incorrect for IdentityArrayList, IdentityLinkedList
 - Merge pull request #1 from anupamdev20/JDK-8255675
 - 8255675: Typo in java.net.HttpURLConnection

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

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


From asemenov at openjdk.java.net  Fri Dec  3 09:18:45 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Fri, 3 Dec 2021 09:18:45 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v6]
In-Reply-To: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
Message-ID: <Rq2d6DYYkYzUOQnI6Dj9mk59S1oo7NNmmKCtUHf2JdA=.3ac81926-6b29-4dc4-90c6-a32e1abef742@github.com>

> Testing https://bugs.openjdk.java.net/browse/JDK-8271071 
> Step to reproduce 
> 1) Run SwingSet2 in JDK 18 ( I used b24 ) 
> 2) Enable Voiceover. 
> 3) Select JTable demo 
> 4) Click any row in the table or select the first row . Observe that row is selected & VoiceOver reads the column values or navigate the columns one by one by pressing tab key. When the focus reaches the last column ( Favourite Food ) Observe that column value is read as null. If you hear the same then the bug is reproduced.

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

  8277497: Last column cell in the JTAble row is read as empty cell

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6538/files
  - new: https://git.openjdk.java.net/jdk/pull/6538/files/22dfb014..f5f1ac19

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

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

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


From asemenov at openjdk.java.net  Fri Dec  3 09:27:11 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Fri, 3 Dec 2021 09:27:11 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v5]
In-Reply-To: <HL1lu9Eh1nHTkr8qVN-vScbpF_5_ESEe03e3bLzLKEg=.9b6e208c-8060-4906-969d-49648cf96311@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
 <z9mC6c44JuBjy1SA6crXIOPuLhQhKGDiy4Zztn-yo7k=.2a52d334-0ec9-46a4-b038-4de68243d132@github.com>
 <qvNTKq6m78KedXfUASlA4SkP0Ds7sF8hpTiBib5REHs=.9108f4be-e1a7-4596-ad3f-1aa49ca00757@github.com>
 <HL1lu9Eh1nHTkr8qVN-vScbpF_5_ESEe03e3bLzLKEg=.9b6e208c-8060-4906-969d-49648cf96311@github.com>
Message-ID: <ZVN34GJpxsyzXCyy0s92lti42f50lxuAchPAMUkl3As=.80f272f6-1540-46a1-bbba-476f51163ee4@github.com>

On Thu, 2 Dec 2021 00:00:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JLabel.java line 1110:
>> 
>>> 1108:                     }
>>> 1109:                 }
>>> 1110:                 if ((name == null) || name.isEmpty()) {
>> 
>> I continue our discussion from code line above.
>> 
>> Why for the empty label and non-accessible image we should say "image", and not for example the "empty label" or just ignore it? 
>> 
>> I mean that if the icon used by the label does not have an "accessible" icon, or any other accessible component why we will try to mention it to the user?
>> 
>> If non-accessible component should not be mentioned to user then you do not need to add a new code here, we already have the "getAccessibleIcon" method which can be called for example from the "CAccessibility" every time we request name/description/text and it empty while the icon is not null and accessible - this will cover all  accesible components not only JLabel.
>> 
>> BTW it could be a SwingSet/App bug that the provided image does not have a description (similar to the common bug in html when the image tag does not have an alt).
>
> Looks like If the change will be done in the "CAccessibility" it will cover the custom components as well.

Thank you. We?ve considered your suggestion and found it reasonable. Indeed, it should be enough here to propagate the icon?s accessible name when it exists. Also, we will change SwingSet2 so that those icons had accessible names.

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

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


From myano at openjdk.java.net  Fri Dec  3 10:26:21 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 3 Dec 2021 10:26:21 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
Message-ID: <PyyuhaeOtPFhDQnjUyhLtSSRu11ROhrCCgM0k3JpH-A=.d2e3a25e-93ac-4f73-9988-b19f7951f3fc@github.com>

On Thu, 28 Oct 2021 08:27:44 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8275715 bug fixes?
>> 
>> I think D3DScreenUpdateManager posts unnecessary PaintEvent during processing PaintEvent. When the validate method is called from createGraphics, repaintPeerTarget should not be called.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8275715: D3D pipeline processes multiple PaintEvent at initial drawing

@mrserb Could you please check this pull request?

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

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


From duke at openjdk.java.net  Fri Dec  3 13:08:21 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 3 Dec 2021 13:08:21 GMT
Subject: Integrated: 8274640: Cleanup unnecessary null comparison before
 instanceof check in java.desktop
In-Reply-To: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
Message-ID: <nviCUnBSCr_a5OPYXWpQYR3wpwlcFJmyjqw3v5U3dBY=.0223d336-418e-4fa2-915e-915a7b884915@github.com>

On Sat, 11 Sep 2021 14:59:21 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Updated code checks both non-null and instance of a class in java.desktop module classes.
> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. 
> Similar cleanups
> 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming
> 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base

This pull request has now been integrated.

Changeset: 18c54b4e
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/18c54b4e1ade2ea5531054ed19441d5bff84fcdc
Stats:     526 lines in 122 files changed: 0 ins; 115 del; 411 mod

8274640: Cleanup unnecessary null comparison before instanceof check in java.desktop

Reviewed-by: aivanov

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

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


From erikj at openjdk.java.net  Fri Dec  3 13:40:22 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 3 Dec 2021 13:40:22 GMT
Subject: RFR: JDK-8278175: Enable all doclint warnings for build of
 java.desktop
In-Reply-To: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
References: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
Message-ID: <8e0538sQHtH4cYq5PU1oDgvcfFiUsvtB1gD3UACkFzc=.72d78b9e-5b18-4f05-8fe6-57acaccf9a99@github.com>

On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

Build change looks good.

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

Marked as reviewed by erikj (Reviewer).

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


From aivanov at openjdk.java.net  Fri Dec  3 13:46:13 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 3 Dec 2021 13:46:13 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits [v3]
In-Reply-To: <lGOPpqu2uYGZHV_GkjysSB5dyq9Z9AOEIRZbr_vMahU=.398430c1-2050-4c19-a352-fe4738507ca2@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
 <lGOPpqu2uYGZHV_GkjysSB5dyq9Z9AOEIRZbr_vMahU=.398430c1-2050-4c19-a352-fe4738507ca2@github.com>
Message-ID: <UnIxQhGmGoSevWYrHsHgaqG4X5FCT8ZEemLq2F3qQv4=.c439ac5a-7e1a-4e0b-ab1b-9181fd1ff19c@github.com>

On Thu, 2 Dec 2021 22:05:00 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Made colorBits and maskBits arrays dynamic so they are allocated on heap instead of stack.
>> Added regression test.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Eliminate potential resource leak.

Changes requested by aivanov (Reviewer).

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1068:

> 1066:             }
> 1067: 
> 1068:             if (colorBits != NULL) {

I think this way defeats the use of exception to handle allocation error. You could use:
```c++
long *colorBits = (long*)malloc(MAX_ICON_SIZE * MAX_ICON_SIZE * sizeof(long));
if (colorBits != NULL) {

to achieve the same effect, which is shorter and clearer.

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1102:

> 1100:                 }
> 1101:                 // Release DC
> 1102:                 ReleaseDC(NULL, dc);

The DC has to be released even if `colorBits` allocation failed, so this needs to be after `if (colorBits != NULL)`.

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

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


From avu at openjdk.java.net  Fri Dec  3 15:25:51 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 3 Dec 2021 15:25:51 GMT
Subject: RFR: 8272392 Lanai: SwingSet2. Black background on expanding tree
 node [v3]
In-Reply-To: <j43XsVmt-JoPBbf2zmSprcycbHlkZF2GSBXas3T7BRk=.fcee72ac-9edf-423d-b71d-89612e6d2e52@github.com>
References: <j43XsVmt-JoPBbf2zmSprcycbHlkZF2GSBXas3T7BRk=.fcee72ac-9edf-423d-b71d-89612e6d2e52@github.com>
Message-ID: <psIipeZin8Lr8AoY465gt76yYFPeqQPcjTxo5Eck17o=.7937e614-5db1-4b6b-9749-41f71803ccc4@github.com>

> Removed creation of the separate encoder depending on destination properties as we don't use this info to customize the encoder properties

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

  8272392 Lanai: SwingSet2. Black background on expanding tree node
  
  Corrected prototype of the reset method

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6529/files
  - new: https://git.openjdk.java.net/jdk/pull/6529/files/89138dfa..94c39ae6

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

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

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


From avu at openjdk.java.net  Fri Dec  3 15:39:12 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 3 Dec 2021 15:39:12 GMT
Subject: RFR: 8272392 Lanai: SwingSet2. Black background on expanding tree
 node [v2]
In-Reply-To: <kh9XZb18l6kGUaPl8qTOpiz0e-aANWYBZVep-_iN-7U=.08df80e2-5530-40ad-bf6f-31f24fe96b09@github.com>
References: <j43XsVmt-JoPBbf2zmSprcycbHlkZF2GSBXas3T7BRk=.fcee72ac-9edf-423d-b71d-89612e6d2e52@github.com>
 <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>
 <kh9XZb18l6kGUaPl8qTOpiz0e-aANWYBZVep-_iN-7U=.08df80e2-5530-40ad-bf6f-31f24fe96b09@github.com>
Message-ID: <-u5hMVCfn6XtH1W65ISOYBk0p3XPsAAWgRse7Y1Xzm4=.6fce7378-d3b6-4000-9a05-763717e30a4b@github.com>

On Wed, 1 Dec 2021 06:57:25 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8272392 Lanai: SwingSet2. Black background on expanding tree node
>>   
>>   Fixed incorrect addition of the values into pipeline state cache. Refactored index initialization. Removed unused flags from MTLClip.
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/EncoderManager.m line 44:
> 
>> 42: 
>> 43: - (void)reset:(id<MTLTexture>)destination
>> 44:          isAA:(jboolean)isAA
> 
> I think by mistake isText argument is also removed. It is not matching reset() implementation.

Thanks for the findings! Fixed.

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

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


From avu at openjdk.java.net  Fri Dec  3 15:39:13 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 3 Dec 2021 15:39:13 GMT
Subject: RFR: 8272392 Lanai: SwingSet2. Black background on expanding tree
 node [v3]
In-Reply-To: <zWjBqDsiQ9dNdsHxxtaEGOgqB3XEZGMoeRT9ti5pwak=.7b688ada-3005-4276-a6f0-7e8c9046a9d6@github.com>
References: <j43XsVmt-JoPBbf2zmSprcycbHlkZF2GSBXas3T7BRk=.fcee72ac-9edf-423d-b71d-89612e6d2e52@github.com>
 <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>
 <zWjBqDsiQ9dNdsHxxtaEGOgqB3XEZGMoeRT9ti5pwak=.7b688ada-3005-4276-a6f0-7e8c9046a9d6@github.com>
Message-ID: <V3_sxY0494s7AwnPCXH_9hIJz0hsgG3zysh3KhkqKd4=.b8f7e52b-cf11-44c9-a4ba-98df594bd5df@github.com>

On Wed, 1 Dec 2021 07:08:39 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8272392 Lanai: SwingSet2. Black background on expanding tree node
>>   
>>   Corrected prototype of the reset method
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLClip.m line 61:
> 
>> 59:     BOOL _stencilMaskGenerationInProgress;
>> 60:     BOOL _stencilMaskGenerationStarted;
>> 61:     BOOL _clipReady;
> 
> This looks like cleanup and not related to this change. Sometime back i also had question on why this was needed. Thanks.

Yes, It's small clean-up here

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

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


From avu at openjdk.java.net  Fri Dec  3 15:42:12 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 3 Dec 2021 15:42:12 GMT
Subject: RFR: 8272392 Lanai: SwingSet2. Black background on expanding tree
 node [v2]
In-Reply-To: <K7LmUFlnX3OT5aRI9mIvYtVrhwQLxvyjdQ87OZzaAWo=.195c33d3-c7dc-4f82-90e5-e71fc2aab953@github.com>
References: <j43XsVmt-JoPBbf2zmSprcycbHlkZF2GSBXas3T7BRk=.fcee72ac-9edf-423d-b71d-89612e6d2e52@github.com>
 <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>
 <K7LmUFlnX3OT5aRI9mIvYtVrhwQLxvyjdQ87OZzaAWo=.195c33d3-c7dc-4f82-90e5-e71fc2aab953@github.com>
Message-ID: <B61IptEwXdJP-IbySF2OroCk3lYR_Bs8n_aC9euZGYQ=.39cfca56-1f8d-444c-85e9-948e520051b2@github.com>

On Wed, 1 Dec 2021 07:55:30 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> I used test case present in https://bugs.openjdk.java.net/browse/JDK-8267963 to check how it behaves with this PR and noticed that it is causes regresssion related to how ruler text looks and also if we move Ruler between monitors it doesnt draw.
> 
> Thought this may be because of state's not getting reset since there is mismatch in EncoderManager.reset() arguments. Updated code to add isText argument over this PR, but i continue to see the regressions.

@jayathirthrao  could you please provide some more info about your environment. I cannot reproduce the problems that you've reported with the test from JDK-8267963.

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

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


From dcubed at openjdk.java.net  Fri Dec  3 16:22:17 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 3 Dec 2021 16:22:17 GMT
Subject: RFR: 8278119: ProblemList few headful test failing in
 macosx12-aarch64 system
In-Reply-To: <d0l3FH5X7vlqm6Cw4wwx9AV_1QWexJ-ckTCtKMu2IwA=.af9c4737-afee-497b-86fe-8cf15a519950@github.com>
References: <d0l3FH5X7vlqm6Cw4wwx9AV_1QWexJ-ckTCtKMu2IwA=.af9c4737-afee-497b-86fe-8cf15a519950@github.com>
Message-ID: <RiIrHNcv4gholkYUWlLEW_hnR_2X7Epy2y2aK2wJc1A=.c4ce0d1a-0973-4ad8-9537-716fed1e7e71@github.com>

On Thu, 2 Dec 2021 08:27:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few tests are failing on macos12-aarch64 systems due to mismatch in color value obtained from robot.getPixelColor and expected color.
> More details on the failures can be seen in JDK-8277816. Till the root cause is investigated, it is better to problemlist it as it causing failures in CI run.

javax/swing/JTree/4908142/bug4908142.java has
also shown up in some of the sightings on these
machines. You should add that one also.

java/awt/GraphicsDevice/CheckDisplayModes.java has also been
showing up recently, but it has a different failure "exit code 133".
I don't know if you want to include that one.

So there are 8 pretty much solid failures and 2 others that also
show up, but not in every run.

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

Changes requested by dcubed (Reviewer).

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


From psadhukhan at openjdk.java.net  Fri Dec  3 16:57:11 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 3 Dec 2021 16:57:11 GMT
Subject: RFR: 8278119: ProblemList few headful test failing in
 macosx12-aarch64 system
In-Reply-To: <d0l3FH5X7vlqm6Cw4wwx9AV_1QWexJ-ckTCtKMu2IwA=.af9c4737-afee-497b-86fe-8cf15a519950@github.com>
References: <d0l3FH5X7vlqm6Cw4wwx9AV_1QWexJ-ckTCtKMu2IwA=.af9c4737-afee-497b-86fe-8cf15a519950@github.com>
Message-ID: <NtCjR2Xt9biXwXG7RsA0nl0mHoDtsKurPjE0KFmbCdI=.674d414b-e3af-4a93-86f7-b68384173e6a@github.com>

On Thu, 2 Dec 2021 08:27:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few tests are failing on macos12-aarch64 systems due to mismatch in color value obtained from robot.getPixelColor and expected color.
> More details on the failures can be seen in JDK-8277816. Till the root cause is investigated, it is better to problemlist it as it causing failures in CI run.

javax/swing/JTree/4908142/bug4908142.java I have a separate review going on for that https://github.com/openjdk/jdk/pull/6661..It has different issue and not color related..
java/awt/GraphicsDevice/CheckDisplayModes.java also has different root cause unlike present in JDK-8277816 so I would like it to be not here..

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

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


From dcubed at openjdk.java.net  Fri Dec  3 17:07:18 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 3 Dec 2021 17:07:18 GMT
Subject: RFR: 8278119: ProblemList few headful test failing in
 macosx12-aarch64 system
In-Reply-To: <d0l3FH5X7vlqm6Cw4wwx9AV_1QWexJ-ckTCtKMu2IwA=.af9c4737-afee-497b-86fe-8cf15a519950@github.com>
References: <d0l3FH5X7vlqm6Cw4wwx9AV_1QWexJ-ckTCtKMu2IwA=.af9c4737-afee-497b-86fe-8cf15a519950@github.com>
Message-ID: <ATQVglb58t9fYzhx0y3jvmmL8qPCNCINMibhyeBP-h4=.f2c10d30-9c8f-4bb1-a5d5-70a82af9ac38@github.com>

On Thu, 2 Dec 2021 08:27:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few tests are failing on macos12-aarch64 systems due to mismatch in color value obtained from robot.getPixelColor and expected color.
> More details on the failures can be seen in JDK-8277816. Till the root cause is investigated, it is better to problemlist it as it causing failures in CI run.

Thanks for the clarifications!

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

Marked as reviewed by dcubed (Reviewer).

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


From psadhukhan at openjdk.java.net  Fri Dec  3 17:14:18 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 3 Dec 2021 17:14:18 GMT
Subject: Integrated: 8278119: ProblemList few headful test failing in
 macosx12-aarch64 system
In-Reply-To: <d0l3FH5X7vlqm6Cw4wwx9AV_1QWexJ-ckTCtKMu2IwA=.af9c4737-afee-497b-86fe-8cf15a519950@github.com>
References: <d0l3FH5X7vlqm6Cw4wwx9AV_1QWexJ-ckTCtKMu2IwA=.af9c4737-afee-497b-86fe-8cf15a519950@github.com>
Message-ID: <1KkO7IheijnvpBOxkbi_ObDhJEbfKkFBlB9ycAMBnV0=.aab1dfdd-bbe1-4793-a3c6-dea6262c4e42@github.com>

On Thu, 2 Dec 2021 08:27:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few tests are failing on macos12-aarch64 systems due to mismatch in color value obtained from robot.getPixelColor and expected color.
> More details on the failures can be seen in JDK-8277816. Till the root cause is investigated, it is better to problemlist it as it causing failures in CI run.

This pull request has now been integrated.

Changeset: 660f21a4
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/660f21a418ee4c616d0b91133fd44e74a77d4d53
Stats:     10 lines in 1 file changed: 9 ins; 0 del; 1 mod

8278119: ProblemList few headful test failing in macosx12-aarch64 system

Reviewed-by: dcubed

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

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


From serb at openjdk.java.net  Fri Dec  3 18:15:21 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Dec 2021 18:15:21 GMT
Subject: RFR: 8275843: Random crashes while the UI code is executed
In-Reply-To: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
References: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
Message-ID: <VwkOmrV7k59LiEsNvmpmyXPUjHwlPKceNNbb0K7YpgY=.6823cefd-4cd0-4372-9ab4-d11ea1a31aac@github.com>

On Mon, 1 Nov 2021 20:03:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please take a look to one more wagon in this train:
> [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795)->[JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931)->[JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579)->[JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392)->[Current issue](https://bugs.openjdk.java.net/browse/JDK-8275843). 
> 
> #### The short description:
> 
> We have an inconsistent between xrender java code and the x11 window. The java code thinks that all our windows support only two types of color models: IntRgbX11 and IntArgbPreX11, but the x11 window supports more types. If such inconsistency occurs we render some garbage, or just crash since our "blits" will assume the wrong data layout. This issue was reported and fixed [before](http://hg.openjdk.java.net/jdk/jdk/rev/c53905e7dc57) but it was not realized why the rendering was wrong and that it can cause a crash. The fix is similar to the old one.
> 
> #### The long description:
> 
>  * Once upon a time this bug was filed [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) it was about the rendering of colors to the volatile image, the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8176795?focusedCommentId=14138323&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14138323) In short: the volatile images in the xrender use intArgbPre color model, it means that the SunGraphics2D object [convert](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1753) the argb value to the argbPre before passing it to the pipeline, and the xrender pipeline [convert](http://hg.openjdk.java.net/jdk/jdk/rev/e4b03365ddbf) this value to the argbPre one more time -> double-conversion-> the bug is reproduced. The fix for that bug disabled the second conversion in the xrender. but it does not take into account that this code path is u
 sed for rendering to the ARGB X11 window where the shared code does not convert the color, so the next bug was filed.
>  * The second bug is [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931), the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8204931?focusedCommentId=14199800&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14199800). In short the bug was about rendering directly to the window and missing color conversion removed previously. The fix for that bug changed the surface type used by the window, so the shared code start to convert the color from ARGB to argbPre, but it does not take into account that we do not control the color model of the window, see how many of them we actually [support](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceData.java#L501) Also note in the link above that if we do not recognize the type we do not fallback to something but throw InvalidPipeException, this is because the blits(and other primitives) may use t
 his type to access the data directly. So the next bug was reported:
>  * This is the third issue [JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579). The fix for that issue tried to roll back the previous one but does not take into account that the conversion removed by the first issue should be rollback as well, so the last bug was filed.
>  * The "last" issue is [JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392) rollback the previous one. So the bug reported in the third report come back.
> 
> #### Fix description
> 
> The fix for the current issue contains a few parts:
>  * Rollback of the [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931) so we will use the proper surface data for the window.
>  * Return conversion in the xrender pipeline removed by the [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) So we will convert it when we render to the volatile image(argbPre) and to the window(argb). We need to convert in both cases since the xrender API which we use expects the argbPre colors.
>  * Start to use the [eargb](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1752) value( instead of pixel) stored in the SunGraphics2D so we did not get the double conversion.
> 
> Some tests are updated and one more is added.
> 
> ### Note
> I have checked the performance implication of this change and it looks like after this change the sequence window.setvisible(true)/window.dispose() will work 30% faster, this may affect the tests which does not wait enough time to make the window visible. Probably this is the reason why some of our tests became more stable at some point in jdk11.
> 
> 
> I have tested this by the jck and jdk_desktop tests. But any additional verification/testing is welcome.

Any volunteers to review?

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

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


From lbourges at openjdk.java.net  Fri Dec  3 18:30:14 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 3 Dec 2021 18:30:14 GMT
Subject: RFR: 8275843: Random crashes while the UI code is executed
In-Reply-To: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
References: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
Message-ID: <CmgIfF1UJ4n9vSzha4FB4jqb6Uhv_LlyRS9fXMuYEfM=.27127780-7479-4d24-af8c-87b36fb8e784@github.com>

On Mon, 1 Nov 2021 20:03:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please take a look to one more wagon in this train:
> [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795)->[JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931)->[JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579)->[JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392)->[Current issue](https://bugs.openjdk.java.net/browse/JDK-8275843). 
> 
> #### The short description:
> 
> We have an inconsistent between xrender java code and the x11 window. The java code thinks that all our windows support only two types of color models: IntRgbX11 and IntArgbPreX11, but the x11 window supports more types. If such inconsistency occurs we render some garbage, or just crash since our "blits" will assume the wrong data layout. This issue was reported and fixed [before](http://hg.openjdk.java.net/jdk/jdk/rev/c53905e7dc57) but it was not realized why the rendering was wrong and that it can cause a crash. The fix is similar to the old one.
> 
> #### The long description:
> 
>  * Once upon a time this bug was filed [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) it was about the rendering of colors to the volatile image, the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8176795?focusedCommentId=14138323&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14138323) In short: the volatile images in the xrender use intArgbPre color model, it means that the SunGraphics2D object [convert](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1753) the argb value to the argbPre before passing it to the pipeline, and the xrender pipeline [convert](http://hg.openjdk.java.net/jdk/jdk/rev/e4b03365ddbf) this value to the argbPre one more time -> double-conversion-> the bug is reproduced. The fix for that bug disabled the second conversion in the xrender. but it does not take into account that this code path is u
 sed for rendering to the ARGB X11 window where the shared code does not convert the color, so the next bug was filed.
>  * The second bug is [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931), the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8204931?focusedCommentId=14199800&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14199800). In short the bug was about rendering directly to the window and missing color conversion removed previously. The fix for that bug changed the surface type used by the window, so the shared code start to convert the color from ARGB to argbPre, but it does not take into account that we do not control the color model of the window, see how many of them we actually [support](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceData.java#L501) Also note in the link above that if we do not recognize the type we do not fallback to something but throw InvalidPipeException, this is because the blits(and other primitives) may use t
 his type to access the data directly. So the next bug was reported:
>  * This is the third issue [JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579). The fix for that issue tried to roll back the previous one but does not take into account that the conversion removed by the first issue should be rollback as well, so the last bug was filed.
>  * The "last" issue is [JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392) rollback the previous one. So the bug reported in the third report come back.
> 
> #### Fix description
> 
> The fix for the current issue contains a few parts:
>  * Rollback of the [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931) so we will use the proper surface data for the window.
>  * Return conversion in the xrender pipeline removed by the [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) So we will convert it when we render to the volatile image(argbPre) and to the window(argb). We need to convert in both cases since the xrender API which we use expects the argbPre colors.
>  * Start to use the [eargb](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1752) value( instead of pixel) stored in the SunGraphics2D so we did not get the double conversion.
> 
> Some tests are updated and one more is added.
> 
> ### Note
> I have checked the performance implication of this change and it looks like after this change the sequence window.setvisible(true)/window.dispose() will work 30% faster, this may affect the tests which does not wait enough time to make the window visible. Probably this is the reason why some of our tests became more stable at some point in jdk11.
> 
> 
> I have tested this by the jck and jdk_desktop tests. But any additional verification/testing is welcome.

Looks good to me, not an official reviewer

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

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


From serb at openjdk.java.net  Fri Dec  3 19:16:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Dec 2021 19:16:15 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v4]
In-Reply-To: <mmmup2BcJqqo5hEL_kZQox0XclYD8JcNhNy44C-ufTc=.7b8b7759-2920-48eb-9e57-193ea37d97e5@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <icSGKnOryPHI_yd-HKjSmURmjwpfb0joZm533GHrsEo=.231a05f3-31a7-4c31-8aa1-01aa0ea5fe8f@github.com>
 <zxNsIG35aBhe9D8ry7rs8s1vnYtqZXcVSj13IGwYPs4=.baeb4de9-3292-4a97-9cc0-f441aebd1b12@github.com>
 <lL2zcy61qbI4QXPWknffRqvgQfU3zS49BvrUQFgrSXE=.fe7927c5-e2fc-4ea5-a852-2773e841de21@github.com>
 <heJWxX2cWSgjLWJPo2p-AJEoLSONuHy3xsiU1z6gEPA=.da4827c5-ee15-43ab-a3fd-3847ea5b6ed5@github.com>
 <mmmup2BcJqqo5hEL_kZQox0XclYD8JcNhNy44C-ufTc=.7b8b7759-2920-48eb-9e57-193ea37d97e5@github.com>
Message-ID: <JpTi6eQxwsNVbuVusQepyScPFN2BVaQYuzWxLIyiDnY=.3877aa41-6743-4f05-b3a8-f1eaa93b57e0@github.com>

On Thu, 2 Dec 2021 20:18:51 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> But it is not necessary to use the robot at all? Can you try to set the scollbar thumb position/move it programmatically w/o a robot? If it is possible then it will be rendered on top of the red area -> it will be possible to render it to the buffered image and just check the pixel in the right position(is it red or not).
>
> Is using robot to get the pixel color alright?

You can render directly to the BufferedImage instead of the JFrame, so in this case, it will not be necessary to use a robot, you will be able to check the pixel directly.

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

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


From serb at openjdk.java.net  Fri Dec  3 19:16:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Dec 2021 19:16:15 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v4]
In-Reply-To: <JpTi6eQxwsNVbuVusQepyScPFN2BVaQYuzWxLIyiDnY=.3877aa41-6743-4f05-b3a8-f1eaa93b57e0@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <icSGKnOryPHI_yd-HKjSmURmjwpfb0joZm533GHrsEo=.231a05f3-31a7-4c31-8aa1-01aa0ea5fe8f@github.com>
 <zxNsIG35aBhe9D8ry7rs8s1vnYtqZXcVSj13IGwYPs4=.baeb4de9-3292-4a97-9cc0-f441aebd1b12@github.com>
 <lL2zcy61qbI4QXPWknffRqvgQfU3zS49BvrUQFgrSXE=.fe7927c5-e2fc-4ea5-a852-2773e841de21@github.com>
 <heJWxX2cWSgjLWJPo2p-AJEoLSONuHy3xsiU1z6gEPA=.da4827c5-ee15-43ab-a3fd-3847ea5b6ed5@github.com>
 <mmmup2BcJqqo5hEL_kZQox0XclYD8JcNhNy44C-ufTc=.7b8b7759-2920-48eb-9e57-193ea37d97e5@github.com>
 <JpTi6eQxwsNVbuVusQepyScPFN2BVaQYuzWxLIyiDnY=.3877aa41-6743-4f05-b3a8-f1eaa93b57e0@github.com>
Message-ID: <KQs-SPRW1jQvyJKBUgN7X5Z2hddDa2HUlivHXatlFNk=.24644c1a-0442-428d-8924-34117e606f27@github.com>

On Fri, 3 Dec 2021 19:11:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Is using robot to get the pixel color alright?
>
> You can render directly to the BufferedImage instead of the JFrame, so in this case, it will not be necessary to use a robot, you will be able to check the pixel directly.

For example, you can take a look at the JButtonPaintNPE or TestBadBreak tests.

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

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


From kizune at openjdk.java.net  Fri Dec  3 20:18:18 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 3 Dec 2021 20:18:18 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits [v3]
In-Reply-To: <UnIxQhGmGoSevWYrHsHgaqG4X5FCT8ZEemLq2F3qQv4=.c439ac5a-7e1a-4e0b-ab1b-9181fd1ff19c@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
 <lGOPpqu2uYGZHV_GkjysSB5dyq9Z9AOEIRZbr_vMahU=.398430c1-2050-4c19-a352-fe4738507ca2@github.com>
 <UnIxQhGmGoSevWYrHsHgaqG4X5FCT8ZEemLq2F3qQv4=.c439ac5a-7e1a-4e0b-ab1b-9181fd1ff19c@github.com>
Message-ID: <8No3mHp1lnZqHb2ptNIhnqk0By-nvY_ziROsgwiw5vo=.8461c16a-f88d-40de-ae2f-c3af16aad281@github.com>

On Fri, 3 Dec 2021 13:26:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Eliminate potential resource leak.
>
> src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1068:
> 
>> 1066:             }
>> 1067: 
>> 1068:             if (colorBits != NULL) {
> 
> I think this way defeats the use of exception to handle allocation error. You could use:
> ```c++
> long *colorBits = (long*)malloc(MAX_ICON_SIZE * MAX_ICON_SIZE * sizeof(long));
> if (colorBits != NULL) {
> 
> to achieve the same effect, which is shorter and clearer.

Yes, but then handle_bad_alloc() will not be called which will not raise the OutOfMemoryError on the java side.

> src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1102:
> 
>> 1100:                 }
>> 1101:                 // Release DC
>> 1102:                 ReleaseDC(NULL, dc);
> 
> The DC has to be released even if `colorBits` allocation failed, so this needs to be after `if (colorBits != NULL)`.

Fixed.

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

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


From aivanov at openjdk.java.net  Fri Dec  3 20:24:12 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 3 Dec 2021 20:24:12 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits [v3]
In-Reply-To: <8No3mHp1lnZqHb2ptNIhnqk0By-nvY_ziROsgwiw5vo=.8461c16a-f88d-40de-ae2f-c3af16aad281@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
 <lGOPpqu2uYGZHV_GkjysSB5dyq9Z9AOEIRZbr_vMahU=.398430c1-2050-4c19-a352-fe4738507ca2@github.com>
 <UnIxQhGmGoSevWYrHsHgaqG4X5FCT8ZEemLq2F3qQv4=.c439ac5a-7e1a-4e0b-ab1b-9181fd1ff19c@github.com>
 <8No3mHp1lnZqHb2ptNIhnqk0By-nvY_ziROsgwiw5vo=.8461c16a-f88d-40de-ae2f-c3af16aad281@github.com>
Message-ID: <_p_UCYxPb7a8sImvlIBHWSywpCU4fh7Vht2KJniHhFo=.2d0a9c43-b8ca-44d6-b86e-1f4f45e123d2@github.com>

On Fri, 3 Dec 2021 20:14:23 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Yes, but then handle_bad_alloc() will not be called which will not raise the OutOfMemoryError on the java side.

Can't we call it explicitly in the case where `colorBits == NULL`?

Alternatively, since you don't use the macros for try and catch, you can re-arrange code and perform cleanup after the catch-block. Just an idea? It may not work.

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

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


From aivanov at openjdk.java.net  Fri Dec  3 21:31:17 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 3 Dec 2021 21:31:17 GMT
Subject: RFR: 8247973: Javadoc incorrect for IdentityArrayList,
 IdentityLinkedList
In-Reply-To: <M8D6vzLV708k3DW5xYBFws6TEvcbxx6aN0Bn9frPNKA=.31525fad-c291-4954-9edd-5005147158e7@github.com>
References: <M8D6vzLV708k3DW5xYBFws6TEvcbxx6aN0Bn9frPNKA=.31525fad-c291-4954-9edd-5005147158e7@github.com>
Message-ID: <6bFmmHOLj2bz5qLB5u1XLoJbPfe3WRST7U_QvjVZUpQ=.81aeacef-1207-424f-b8a2-f35f1ab96ac0@github.com>

On Fri, 3 Dec 2021 07:30:43 GMT, ANUPAM DEV <duke at openjdk.java.net> wrote:

> The documentation for following methods used equals() for object equality:
> 
> sun.awt.util.IdentityLinkedList#contains
> sun.awt.util.IdentityArrayList#contains
> sun.awt.util.IdentityArrayList#indexOf
> sun.awt.util.IdentityArrayList#lastIndexOf
> sun.awt.util.IdentityArrayList#remove(java.lang.Object)
> 
> I have updated the comments to use "==" operator for object equality. Kindly review the changes for the same.

I propose removing changes to `HttpURLConnection.java` from this PR. Both `IdentityArrayList`, `IdentityLinkedList` are in `java.desktop` module but `HttpURLConnection` is in `java.base` module. Submit a new issue to fix spelling errors in `HttpURLConnection.java`.

src/java.desktop/share/classes/sun/awt/util/IdentityArrayList.java line 219:

> 217:      * in this list, or -1 if this list does not contain the element.
> 218:      * More formally, returns the lowest index {@code i} such that
> 219:      * {@code get(i)==o},

Shall it have spaces on either side of `==`?
Suggestion:

     * {@code get(i) == o},


I see `IdentityLinkedList.java` doesn't have spaces around `==` in this case. Yet in this case, probably `{@code o == e}` should not have the spaces too.

src/java.desktop/share/classes/sun/awt/util/IdentityArrayList.java line 399:

> 397:     }
> 398: 
> 399:      /**

An extra space.

src/java.desktop/share/classes/sun/awt/util/IdentityArrayList.java line 401:

> 399:      /**
> 400:      * Removes the first occurrence of the specified element from this list,
> 401:      * if it is present.  If this list does not contain the element, it is

Suggestion:

     * if it is present.  If this list does not contain the element, the list is

I think it adds clarification to _what_ is unchanged.

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

Changes requested by aivanov (Reviewer).

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


From prr at openjdk.java.net  Sat Dec  4 00:48:13 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 4 Dec 2021 00:48:13 GMT
Subject: RFR: JDK-8278175: Enable all doclint warnings for build of
 java.desktop
In-Reply-To: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
References: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
Message-ID: <lq-_QB_2lqzAo79lab-b5ME_S7lJYWlfGCiAumNXm8w=.c890f4f2-612d-4822-b20a-399e2010fd77@github.com>

On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

Looks OK. Could you file a P4 bug showing the warnings/errors that would be generated so that we know what we need to work on to later remove these the right way.

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

Marked as reviewed by prr (Reviewer).

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


From duke at openjdk.java.net  Sat Dec  4 01:59:20 2021
From: duke at openjdk.java.net (duke)
Date: Sat, 4 Dec 2021 01:59:20 GMT
Subject: Withdrawn: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing
In-Reply-To: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
Message-ID: <2GKuOTkaq-hN4CVVEzfbJAojquckOeYs1wDKa-L3BlQ=.1c1d2884-57cb-4081-b9b7-bfee5b9487c3@github.com>

On Mon, 13 Sep 2021 18:03:39 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.

This pull request has been closed without being integrated.

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

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


From darcy at openjdk.java.net  Sat Dec  4 02:16:15 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 4 Dec 2021 02:16:15 GMT
Subject: RFR: JDK-8278175: Enable all doclint warnings for build of
 java.desktop
In-Reply-To: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
References: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
Message-ID: <hHoiIcihO5v4zEoXp7iiAAmwEY552379dJq5puMYzp8=.5e5ce6fa-a1fe-4491-b4eb-6998e1a8c941@github.com>

On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

> 

Sure; filed JDK-8278254 Cleanup doclint warnings in java.desktop module

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

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


From darcy at openjdk.java.net  Sat Dec  4 02:16:15 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 4 Dec 2021 02:16:15 GMT
Subject: Integrated: JDK-8278175: Enable all doclint warnings for build of
 java.desktop
In-Reply-To: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
References: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
Message-ID: <zgNP6WHnr2gT8YTi2LlPqdYrbyyF7uBjvaJM2fSeV70=.739ab508-0f62-4bd1-a437-9826b68e50f6@github.com>

On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

This pull request has now been integrated.

Changeset: 02ee337a
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/02ee337ae0d163ae44b1691eb9de12c5608ba178
Stats:     34 lines in 20 files changed: 16 ins; 0 del; 18 mod

8278175: Enable all doclint warnings for build of java.desktop

Reviewed-by: erikj, prr

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

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


From duke at openjdk.java.net  Sat Dec  4 02:50:20 2021
From: duke at openjdk.java.net (ANUPAM DEV)
Date: Sat, 4 Dec 2021 02:50:20 GMT
Subject: Withdrawn: 8247973: Javadoc incorrect for IdentityArrayList,
 IdentityLinkedList
In-Reply-To: <M8D6vzLV708k3DW5xYBFws6TEvcbxx6aN0Bn9frPNKA=.31525fad-c291-4954-9edd-5005147158e7@github.com>
References: <M8D6vzLV708k3DW5xYBFws6TEvcbxx6aN0Bn9frPNKA=.31525fad-c291-4954-9edd-5005147158e7@github.com>
Message-ID: <OOc6USSVhl_byRtQlMzSwTIp2yZkXNrhnh4x5XDJPRk=.256286be-7d0c-4163-981a-8de8262f13f0@github.com>

On Fri, 3 Dec 2021 07:30:43 GMT, ANUPAM DEV <duke at openjdk.java.net> wrote:

> The documentation for following methods used equals() for object equality:
> 
> sun.awt.util.IdentityLinkedList#contains
> sun.awt.util.IdentityArrayList#contains
> sun.awt.util.IdentityArrayList#indexOf
> sun.awt.util.IdentityArrayList#lastIndexOf
> sun.awt.util.IdentityArrayList#remove(java.lang.Object)
> 
> I have updated the comments to use "==" operator for object equality. Kindly review the changes for the same.

This pull request has been closed without being integrated.

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

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


From duke at openjdk.java.net  Sat Dec  4 03:13:36 2021
From: duke at openjdk.java.net (ANUPAM DEV)
Date: Sat, 4 Dec 2021 03:13:36 GMT
Subject: RFR: 8247973: Javadoc incorrect for IdentityArrayList,
 IdentityLinkedList
Message-ID: <uioAisr6LX3jfKFbYZ-KiDVpjE9LFVoJfDG6FVlDh4Q=.25e6d8a5-b9fd-463f-bd56-451b48062007@github.com>

The documentation for following methods used object equality mentioning 'equals()'. I have replaced the equals() with == operator where necessary with some formattings.

sun.awt.util.IdentityLinkedList#contains
sun.awt.util.IdentityArrayList#contains
sun.awt.util.IdentityArrayList#indexOf
sun.awt.util.IdentityArrayList#lastIndexOf
sun.awt.util.IdentityArrayList#remove(java.lang.Object) 

Kindly review the change.

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

Commit messages:
 - 8247973: Javadoc incorrect for IdentityArrayList, IdentityLinkedList
 - Merge branch 'openjdk:master' into master
 - Merge pull request #1 from anupamdev20/JDK-8255675
 - 8255675: Typo in java.net.HttpURLConnection

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

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


From kizune at openjdk.java.net  Sat Dec  4 05:04:10 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 4 Dec 2021 05:04:10 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits [v3]
In-Reply-To: <_p_UCYxPb7a8sImvlIBHWSywpCU4fh7Vht2KJniHhFo=.2d0a9c43-b8ca-44d6-b86e-1f4f45e123d2@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
 <lGOPpqu2uYGZHV_GkjysSB5dyq9Z9AOEIRZbr_vMahU=.398430c1-2050-4c19-a352-fe4738507ca2@github.com>
 <UnIxQhGmGoSevWYrHsHgaqG4X5FCT8ZEemLq2F3qQv4=.c439ac5a-7e1a-4e0b-ab1b-9181fd1ff19c@github.com>
 <8No3mHp1lnZqHb2ptNIhnqk0By-nvY_ziROsgwiw5vo=.8461c16a-f88d-40de-ae2f-c3af16aad281@github.com>
 <_p_UCYxPb7a8sImvlIBHWSywpCU4fh7Vht2KJniHhFo=.2d0a9c43-b8ca-44d6-b86e-1f4f45e123d2@github.com>
Message-ID: <s7C3pSlSZ1Uug3nZVmOWXJnPToIGN8CC83uEL7wHi_s=.04db1301-87b9-4243-b650-1bdb64ca8c92@github.com>

On Fri, 3 Dec 2021 20:20:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Can't we call it explicitly in the case where colorBits == NULL?

I would use the default handlers for bad_alloc since they can be changed in feature and keeping code that is intended to be used in two places is usually not a good idea.

> Alternatively, since you don't use the macros for try and catch, you can re-arrange code and perform cleanup after the catch-block. Just an idea? It may not work.

That might require a lot of code reformatting and the benefits are unclear.

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

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


From serb at openjdk.java.net  Sat Dec  4 06:47:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 4 Dec 2021 06:47:31 GMT
Subject: RFR: 8278251: Enable "missing-explicit-ctor" check in the
 jdk.unsupported.desktop module
Message-ID: <4f-QfTpojcbsiww5G7DrU7daNRNW0scSjxsPOUODdTo=.c578c7b1-2f75-4734-ae75-9c1a5c3214f4@github.com>

The "missing-explicit-ctor" check was disabled by the [JDK-8071961](https://bugs.openjdk.java.net/browse/JDK-8071961) and later was fixed by the [JDK-8250853](https://bugs.openjdk.java.net/browse/JDK-8250853). So we can re-enable this check again.

The fix will remove the "Java.gmk" file and as a result the "jdk.unsupported.desktop" folder.

All "Pre-submit tests" builds are green.

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

Commit messages:
 - Delete Java.gmk

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

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


From aivanov at openjdk.java.net  Sat Dec  4 17:46:13 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 4 Dec 2021 17:46:13 GMT
Subject: RFR: 8247973: Javadoc incorrect for IdentityArrayList,
 IdentityLinkedList
In-Reply-To: <uioAisr6LX3jfKFbYZ-KiDVpjE9LFVoJfDG6FVlDh4Q=.25e6d8a5-b9fd-463f-bd56-451b48062007@github.com>
References: <uioAisr6LX3jfKFbYZ-KiDVpjE9LFVoJfDG6FVlDh4Q=.25e6d8a5-b9fd-463f-bd56-451b48062007@github.com>
Message-ID: <gFKRBm4OZeLdatELxxtodHmhOE5QhneBCNtUYXv5p6w=.c5a4f18f-41f1-40da-941f-dfe262ece19e@github.com>

On Sat, 4 Dec 2021 03:07:03 GMT, ANUPAM DEV <duke at openjdk.java.net> wrote:

> The documentation for following methods used object equality mentioning 'equals()'. I have replaced the equals() with == operator where necessary with some formattings.
> 
> sun.awt.util.IdentityLinkedList#contains
> sun.awt.util.IdentityArrayList#contains
> sun.awt.util.IdentityArrayList#indexOf
> sun.awt.util.IdentityArrayList#lastIndexOf
> sun.awt.util.IdentityArrayList#remove(java.lang.Object) 
> 
> Kindly review the change.

Was the previous PR #6694 not good enough?  
The previous PR has comments to the changes thus you should've referenced it when you created the new one.

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

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


From aivanov at openjdk.java.net  Sat Dec  4 19:36:17 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 4 Dec 2021 19:36:17 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits [v3]
In-Reply-To: <s7C3pSlSZ1Uug3nZVmOWXJnPToIGN8CC83uEL7wHi_s=.04db1301-87b9-4243-b650-1bdb64ca8c92@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
 <lGOPpqu2uYGZHV_GkjysSB5dyq9Z9AOEIRZbr_vMahU=.398430c1-2050-4c19-a352-fe4738507ca2@github.com>
 <UnIxQhGmGoSevWYrHsHgaqG4X5FCT8ZEemLq2F3qQv4=.c439ac5a-7e1a-4e0b-ab1b-9181fd1ff19c@github.com>
 <8No3mHp1lnZqHb2ptNIhnqk0By-nvY_ziROsgwiw5vo=.8461c16a-f88d-40de-ae2f-c3af16aad281@github.com>
 <_p_UCYxPb7a8sImvlIBHWSywpCU4fh7Vht2KJniHhFo=.2d0a9c43-b8ca-44d6-b86e-1f4f45e123d2@github.com>
 <s7C3pSlSZ1Uug3nZVmOWXJnPToIGN8CC83uEL7wHi_s=.04db1301-87b9-4243-b650-1bdb64ca8c92@github.com>
Message-ID: <LW_FNYfYokGel6M-2ac2-5DELKlMxxFpsmrN4GR-xyk=.1231a46b-cfac-4644-a8bd-1b8dccebd0d3@github.com>

On Sat, 4 Dec 2021 05:01:06 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> > Alternatively, since you don't use the macros for try and catch, you can re-arrange code and perform cleanup after the catch-block. Just an idea? It may not work.
> 
> That might require a lot of code reformatting and the benefits are unclear.

I tried it, it doesn't, [see this diff](https://github.com/aivanov-jdk/jdk/commit/ccf7500cf0e4614b12c0882204a81d928fce0a82). It's close to your latest code, however, there's only one `catch` that handles both allocations and there are no `if`'s inside the `try`-block.

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

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


From aivanov at openjdk.java.net  Sat Dec  4 19:36:18 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 4 Dec 2021 19:36:18 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits [v3]
In-Reply-To: <8No3mHp1lnZqHb2ptNIhnqk0By-nvY_ziROsgwiw5vo=.8461c16a-f88d-40de-ae2f-c3af16aad281@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
 <lGOPpqu2uYGZHV_GkjysSB5dyq9Z9AOEIRZbr_vMahU=.398430c1-2050-4c19-a352-fe4738507ca2@github.com>
 <UnIxQhGmGoSevWYrHsHgaqG4X5FCT8ZEemLq2F3qQv4=.c439ac5a-7e1a-4e0b-ab1b-9181fd1ff19c@github.com>
 <8No3mHp1lnZqHb2ptNIhnqk0By-nvY_ziROsgwiw5vo=.8461c16a-f88d-40de-ae2f-c3af16aad281@github.com>
Message-ID: <s4EPZaFNzLmm3G94B5SoMBDQPDD1Z6MTofQg19OYUcU=.38f4f2bb-3625-4977-adeb-e4d4fa4b7d9e@github.com>

On Fri, 3 Dec 2021 20:14:43 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1102:
>> 
>>> 1100:                 }
>>> 1101:                 // Release DC
>>> 1102:                 ReleaseDC(NULL, dc);
>> 
>> The DC has to be released even if `colorBits` allocation failed, so this needs to be after `if (colorBits != NULL)`.
>
> Fixed.

Probably, you hasn't pushed the change for releasing the DC.

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

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


From duke at openjdk.java.net  Sun Dec  5 03:58:12 2021
From: duke at openjdk.java.net (ANUPAM DEV)
Date: Sun, 5 Dec 2021 03:58:12 GMT
Subject: RFR: 8247973: Javadoc incorrect for IdentityArrayList,
 IdentityLinkedList
In-Reply-To: <gFKRBm4OZeLdatELxxtodHmhOE5QhneBCNtUYXv5p6w=.c5a4f18f-41f1-40da-941f-dfe262ece19e@github.com>
References: <uioAisr6LX3jfKFbYZ-KiDVpjE9LFVoJfDG6FVlDh4Q=.25e6d8a5-b9fd-463f-bd56-451b48062007@github.com>
 <gFKRBm4OZeLdatELxxtodHmhOE5QhneBCNtUYXv5p6w=.c5a4f18f-41f1-40da-941f-dfe262ece19e@github.com>
Message-ID: <cHOeUlg4cPUa6Hx1hIkdsjLeO-moKcKrFE-d24TXudw=.44992eac-c462-4ca0-ba97-0b3619bfa439@github.com>

On Sat, 4 Dec 2021 17:42:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The documentation for following methods used object equality mentioning 'equals()'. I have replaced the equals() with == operator where necessary with some formattings.
>> 
>> sun.awt.util.IdentityLinkedList#contains
>> sun.awt.util.IdentityArrayList#contains
>> sun.awt.util.IdentityArrayList#indexOf
>> sun.awt.util.IdentityArrayList#lastIndexOf
>> sun.awt.util.IdentityArrayList#remove(java.lang.Object) 
>> 
>> Kindly review the change.
>
> Was the previous PR #6694 not good enough?  
> The previous PR has comments to the changes thus you should've referenced it when you created the new one.

@aivanov-jdk The PR #6694 included HttpURLConnection too. I therefore closed that PR (https://github.com/openjdk/jdk/pull/6694#pullrequestreview-823124988) and initiated new requested with correct files and changes. As I am slightly new to git I did not know how to update the PR, so I filed a new one.

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

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


From psadhukhan at openjdk.java.net  Mon Dec  6 07:09:11 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 6 Dec 2021 07:09:11 GMT
Subject: RFR: 8172065: javax/swing/JTree/4908142/bug4908142.java The
 selected index should be "aad" [v2]
In-Reply-To: <cIiNd7_OlcuF54mLU-tXw38x6-qA_elCpSSKYQMRHD4=.c46ab68f-9b52-45e4-ade5-bd4c811db50c@github.com>
References: <1bFLgdrkpH1rWjwpQS16m87kA1E4Z35C2STeYWyDCrA=.73d51aaf-ad43-4470-a1aa-aa8d026ce7d8@github.com>
 <cIiNd7_OlcuF54mLU-tXw38x6-qA_elCpSSKYQMRHD4=.c46ab68f-9b52-45e4-ade5-bd4c811db50c@github.com>
Message-ID: <ctPL4VIjHZCTITORBHch-Pv4NgADcyvMNKtbCavad6Q=.2d856131-6d9b-4787-868b-df483fbc9838@github.com>

On Fri, 3 Dec 2021 06:18:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test is failing in macosx-12 in aarch64 system. Added stability fixes of delay after frame is visible, making frame to center of screen to make the test stable in macos12-aarch64 system too.
>> Modified test passes in all CI platforms including osx-aarch64 system in osx11 and osx12.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add waitForIdle

Any reviewer please?

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

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


From dbatrak at openjdk.java.net  Mon Dec  6 08:53:07 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Mon, 6 Dec 2021 08:53:07 GMT
Subject: RFR: 8278050: Armenian text isn't rendered on macOS if text layout
 is performed
In-Reply-To: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
References: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
Message-ID: <ID9I0ZE3HtdAlg6mwXWkqQjL1jFHhgSHkOSdNtLvDM0=.b02ada54-537d-47f7-b625-317461db76fc@github.com>

On Wed, 1 Dec 2021 10:52:38 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The problem is related to the implementation of font fallback on macOS, specifically to the path used when text layout
> is performed, i.e. the one using `FontSubstitution` and cascade lists. `CTFontCopyDefaultCascadeListForLanguages`'s output contains an entry for the font, able to render Armenian text ('NotoSansArmenian-Regular'), but `CFont.createCompositeFont` cannot find this font amongst registered fonts, and the entry is skipped, resulting in broken rendering.
> System font loading (performed by `CFontManager.loadNativeFonts`) relies on `[NSFontManager availableFontFamilies]`, but its output doesn't contain 'Noto Sans Armenian' (which is a family for 'NotoSansArmenian-Regular' font). 'Noto Sans Armenian' is recognized by `[NSFontManager availableMembersOfFontFamily:]` though, 'NotoSansArmenian-Regular' is contained in `[NSFontManager availableFonts]` output, and the font can be created and used normally, just like any other system font. Not sure why its family is 'hidden', maybe macOS developers wanted to limit the number of options
> displayed in font selection drop-downs.
> For reference, another cascade list item, ignored in similar way is 'NotoSansZawgyi-Regular'.
> 
> Proposed fix is to create `CFont` objects for cascade list items explicitly, if corresponding fonts are not registered. These objects are re-used between different fonts as their fallback components (to enable caching of char-to-glyph mapping), but are not made available to public font APIs.
> I've considered an alternative solution - using `[NSFontManager availableFonts]` instead of
> `[NSFontManager availableFontFamilies]` to load system fonts. Two factors complicate it though - `loadNativeFonts` will
> take more time (on my machine about 170 additional fonts will be loaded) and the order of font loading will change (which
> impacts the selection of 'preferred' plain/bold/italic/bolditalic components in `FontFamily` class). Both factors can be
> dealt with, but they make the solution more complicated and prone to regressions. For now, it seems not worth it.
> 
> I've not created a test, as it would rely on macOS providing a fallback font for Armenian script, which is not guaranteed.
> Existing tests pass fine with the fix.

Any other volunteers to review?

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

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


From ant at openjdk.java.net  Mon Dec  6 09:14:14 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Mon, 6 Dec 2021 09:14:14 GMT
Subject: RFR: 8277497 Last column cell in the JTAble row is read as empty
 cell [v6]
In-Reply-To: <Rq2d6DYYkYzUOQnI6Dj9mk59S1oo7NNmmKCtUHf2JdA=.3ac81926-6b29-4dc4-90c6-a32e1abef742@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
 <Rq2d6DYYkYzUOQnI6Dj9mk59S1oo7NNmmKCtUHf2JdA=.3ac81926-6b29-4dc4-90c6-a32e1abef742@github.com>
Message-ID: <FseV4IQYN66wuOkYeyFGwpa--eBwQva596dKpo-Nnlo=.f499d979-f8ea-49dc-a965-209fa9064679@github.com>

On Fri, 3 Dec 2021 09:18:45 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> Testing https://bugs.openjdk.java.net/browse/JDK-8271071 
>> Step to reproduce 
>> 1) Run SwingSet2 in JDK 18 ( I used b24 ) 
>> 2) Enable Voiceover. 
>> 3) Select JTable demo 
>> 4) Click any row in the table or select the first row . Observe that row is selected & VoiceOver reads the column values or navigate the columns one by one by pressing tab key. When the focus reaches the last column ( Favourite Food ) Observe that column value is read as null. If you hear the same then the bug is reproduced.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277497: Last column cell in the JTAble row is read as empty cell

Marked as reviewed by ant (Reviewer).

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

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


From ihse at openjdk.java.net  Mon Dec  6 11:50:16 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 6 Dec 2021 11:50:16 GMT
Subject: RFR: 8278251: Enable "missing-explicit-ctor" check in the
 jdk.unsupported.desktop module
In-Reply-To: <4f-QfTpojcbsiww5G7DrU7daNRNW0scSjxsPOUODdTo=.c578c7b1-2f75-4734-ae75-9c1a5c3214f4@github.com>
References: <4f-QfTpojcbsiww5G7DrU7daNRNW0scSjxsPOUODdTo=.c578c7b1-2f75-4734-ae75-9c1a5c3214f4@github.com>
Message-ID: <LFzMNyGzsoDVxrY4PmSvwWJ_Oukb_Y2skwa9XNGbg6k=.d6852cf1-920e-4a1e-a90e-34ac941d10f0@github.com>

On Fri, 3 Dec 2021 20:55:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "missing-explicit-ctor" check was disabled by the [JDK-8071961](https://bugs.openjdk.java.net/browse/JDK-8071961) and later was fixed by the [JDK-8250853](https://bugs.openjdk.java.net/browse/JDK-8250853). So we can re-enable this check again.
> 
> The fix will remove the "Java.gmk" file and as a result the "jdk.unsupported.desktop" folder.
> 
> All "Pre-submit tests" builds are green.

LGTM.

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

Marked as reviewed by ihse (Reviewer).

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


From kizune at openjdk.java.net  Mon Dec  6 12:49:47 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 6 Dec 2021 12:49:47 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits [v4]
In-Reply-To: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
Message-ID: <Wt1c0MSiZ4g5cS7ckwWve0eJco9HZpxuVcduSVsNrXk=.2b4d73b6-8ec4-441c-9004-66b6a04b567b@github.com>

> Made colorBits and maskBits arrays dynamic so they are allocated on heap instead of stack.
> Added regression test.

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

  elease device context even if colorBits buffer can not be allocated.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6473/files
  - new: https://git.openjdk.java.net/jdk/pull/6473/files/c8d8ee23..d72abd92

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

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

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


From kizune at openjdk.java.net  Mon Dec  6 12:49:48 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 6 Dec 2021 12:49:48 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits [v3]
In-Reply-To: <s4EPZaFNzLmm3G94B5SoMBDQPDD1Z6MTofQg19OYUcU=.38f4f2bb-3625-4977-adeb-e4d4fa4b7d9e@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
 <lGOPpqu2uYGZHV_GkjysSB5dyq9Z9AOEIRZbr_vMahU=.398430c1-2050-4c19-a352-fe4738507ca2@github.com>
 <UnIxQhGmGoSevWYrHsHgaqG4X5FCT8ZEemLq2F3qQv4=.c439ac5a-7e1a-4e0b-ab1b-9181fd1ff19c@github.com>
 <8No3mHp1lnZqHb2ptNIhnqk0By-nvY_ziROsgwiw5vo=.8461c16a-f88d-40de-ae2f-c3af16aad281@github.com>
 <s4EPZaFNzLmm3G94B5SoMBDQPDD1Z6MTofQg19OYUcU=.38f4f2bb-3625-4977-adeb-e4d4fa4b7d9e@github.com>
Message-ID: <kFWFERgyorjxQ5Fhrj4A1fOxGUPQqTCM4yMY3q8IjkM=.b81250ae-57a0-49e8-b9cb-7f559f4a6c3e@github.com>

On Sat, 4 Dec 2021 19:32:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Fixed.
>
> Probably, you hasn't pushed the change for releasing the DC.

Indeed.

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

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


From aivanov at openjdk.java.net  Mon Dec  6 15:21:16 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 6 Dec 2021 15:21:16 GMT
Subject: RFR: 8172065: javax/swing/JTree/4908142/bug4908142.java The
 selected index should be "aad" [v2]
In-Reply-To: <cIiNd7_OlcuF54mLU-tXw38x6-qA_elCpSSKYQMRHD4=.c46ab68f-9b52-45e4-ade5-bd4c811db50c@github.com>
References: <1bFLgdrkpH1rWjwpQS16m87kA1E4Z35C2STeYWyDCrA=.73d51aaf-ad43-4470-a1aa-aa8d026ce7d8@github.com>
 <cIiNd7_OlcuF54mLU-tXw38x6-qA_elCpSSKYQMRHD4=.c46ab68f-9b52-45e4-ade5-bd4c811db50c@github.com>
Message-ID: <c4gA9-CHPb6unVJhZYWIU1XKbgmtmIyLxbawrqtiWqo=.7749c0f4-55f3-4e50-86f4-b57b223c8f3e@github.com>

On Fri, 3 Dec 2021 06:18:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test is failing in macosx-12 in aarch64 system. Added stability fixes of delay after frame is visible, making frame to center of screen to make the test stable in macos12-aarch64 system too.
>> Modified test passes in all CI platforms including osx-aarch64 system in osx11 and osx12.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add waitForIdle

Marked as reviewed by aivanov (Reviewer).

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

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


From duke at openjdk.java.net  Mon Dec  6 15:58:28 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 6 Dec 2021 15:58:28 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs
Message-ID: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>

JListBox is invalid component. CellTableEditor Interface doesn't support JComboBox and JTree components. Hence its removed from Documentation.

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

Commit messages:
 - 6465404: some problems in CellEditor related API docs

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

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


From duke at openjdk.java.net  Mon Dec  6 15:59:29 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 6 Dec 2021 15:59:29 GMT
Subject: RFR: 6462028: MaskFormatter API documentation refers to
 getDisplayValue
Message-ID: <-SOfUt64IAtAG0_rLAwkmMCCd81ZaPuTuF5ORNYuIOs=.fd151cd5-71c7-4e21-bd62-aeec7d296e76@github.com>

MaskFormatter API doesn't have getDisplayValue method, hence removed from Documentation.

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

Commit messages:
 - 6462028:MaskFormatter API documentation refers to getDisplayValue

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

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


From psadhukhan at openjdk.java.net  Mon Dec  6 16:12:20 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 6 Dec 2021 16:12:20 GMT
Subject: RFR: 6462028: MaskFormatter API documentation refers to
 getDisplayValue
In-Reply-To: <-SOfUt64IAtAG0_rLAwkmMCCd81ZaPuTuF5ORNYuIOs=.fd151cd5-71c7-4e21-bd62-aeec7d296e76@github.com>
References: <-SOfUt64IAtAG0_rLAwkmMCCd81ZaPuTuF5ORNYuIOs=.fd151cd5-71c7-4e21-bd62-aeec7d296e76@github.com>
Message-ID: <VwFsWzE82HgyR2ic69BbCaOWbPD___2xKytgCsfg8Ww=.26051a8d-9417-4b1c-90e9-513c6616f2da@github.com>

On Thu, 25 Nov 2021 09:54:47 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> MaskFormatter API doesn't have getDisplayValue method, hence removed from Documentation.

Marked as reviewed by psadhukhan (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Mon Dec  6 16:14:23 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 6 Dec 2021 16:14:23 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs
In-Reply-To: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
Message-ID: <J_fI60I96wTmMUEX4rxe4ASFWckEE8O7QsyvLGySPQY=.2a4f5458-7102-4eaa-8c61-bee0bfe363b8@github.com>

On Tue, 30 Nov 2021 08:49:19 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> JListBox is invalid component. CellTableEditor Interface doesn't support JComboBox and JTree components. Hence its removed from Documentation.

Marked as reviewed by psadhukhan (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Mon Dec  6 16:15:22 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 6 Dec 2021 16:15:22 GMT
Subject: Integrated: 8172065: javax/swing/JTree/4908142/bug4908142.java The
 selected index should be "aad"
In-Reply-To: <1bFLgdrkpH1rWjwpQS16m87kA1E4Z35C2STeYWyDCrA=.73d51aaf-ad43-4470-a1aa-aa8d026ce7d8@github.com>
References: <1bFLgdrkpH1rWjwpQS16m87kA1E4Z35C2STeYWyDCrA=.73d51aaf-ad43-4470-a1aa-aa8d026ce7d8@github.com>
Message-ID: <VDg_XsRYTKfRbaE9ybPAHCq2jNmcT0HV0AicQaUiWVs=.4eca52f0-ddcb-4263-8e82-cf7a464ee84a@github.com>

On Thu, 2 Dec 2021 08:12:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test is failing in macosx-12 in aarch64 system. Added stability fixes of delay after frame is visible, making frame to center of screen to make the test stable in macos12-aarch64 system too.
> Modified test passes in all CI platforms including osx-aarch64 system in osx11 and osx12.

This pull request has now been integrated.

Changeset: 082fdf47
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/082fdf479367612a7bd795d3becfe9830db4b2d6
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8172065: javax/swing/JTree/4908142/bug4908142.java The selected index should be "aad"

Reviewed-by: aivanov

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

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


From aivanov at openjdk.java.net  Mon Dec  6 16:26:10 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 6 Dec 2021 16:26:10 GMT
Subject: RFR: 6462028: MaskFormatter API documentation refers to
 getDisplayValue
In-Reply-To: <-SOfUt64IAtAG0_rLAwkmMCCd81ZaPuTuF5ORNYuIOs=.fd151cd5-71c7-4e21-bd62-aeec7d296e76@github.com>
References: <-SOfUt64IAtAG0_rLAwkmMCCd81ZaPuTuF5ORNYuIOs=.fd151cd5-71c7-4e21-bd62-aeec7d296e76@github.com>
Message-ID: <62NcR6AEhkTmMH9YnM_KnoK_quyX1RlSC6nFc-dyg4U=.c078dcec-9805-4004-9d34-6eb4ae1635c7@github.com>

On Thu, 25 Nov 2021 09:54:47 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> MaskFormatter API doesn't have getDisplayValue method, hence removed from Documentation.

Please also update the copyright year at the start of the file.

src/java.desktop/share/classes/javax/swing/text/MaskFormatter.java line 103:

> 101:  *   MaskFormatter formatter = new MaskFormatter("###-####");
> 102:  *   formatter.setPlaceholderCharacter('_');
> 103:  *   formatter.getDisplayValue(tf, "123");

This code is part of an example, without this line, the following lines of documentation do not make sense. Probably, `getDisplayValue` should be replaced with `valueToString`. You should check that and ensure the sample and the expected output, as discussed in the following sentences, is correct.

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

Changes requested by aivanov (Reviewer).

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


From aivanov at openjdk.java.net  Mon Dec  6 16:40:16 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 6 Dec 2021 16:40:16 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs
In-Reply-To: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
Message-ID: <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>

On Tue, 30 Nov 2021 08:49:19 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> JListBox is invalid component. CellTableEditor Interface doesn't support JComboBox and JTree components. Hence its removed from Documentation.

Please also update the copyright year.

Please also expand the wildcard import at line 30:

import javax.swing.*;

to a specific class import. In fact, this interface imports only `JTable` with the wildcard since `CellEditor` is already imported explicitly.

src/java.desktop/share/classes/javax/swing/table/TableCellEditor.java line 35:

> 33:  * This interface defines the method any object that would like to be
> 34:  * an editor of values for the component <code>JTable</code> that
> 35:  * needs to implement.

Suggestion:

 * an editor of values for the {@code JTable} component needs to implement.

_?that?_ after `JTable` shouldn't be there.

However, I would suggest rephrasing the Javadoc to make it easier to understand: the sentence has two levels of dependent clauses.

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

Changes requested by aivanov (Reviewer).

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


From vdyakov at openjdk.java.net  Mon Dec  6 16:40:16 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Mon, 6 Dec 2021 16:40:16 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs
In-Reply-To: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
Message-ID: <hy0cyu-uLpt5Kr2qIbRibrw0vI09gIJzk4TuBGs_Zfg=.f1b22540-379f-4df9-a8ce-d4d4caad94ad@github.com>

On Tue, 30 Nov 2021 08:49:19 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> JListBox is invalid component. CellTableEditor Interface doesn't support JComboBox and JTree components. Hence its removed from Documentation.

@azuev-java please review

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

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


From aivanov at openjdk.java.net  Mon Dec  6 16:54:11 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 6 Dec 2021 16:54:11 GMT
Subject: RFR: 8247973: Javadoc incorrect for IdentityArrayList,
 IdentityLinkedList
In-Reply-To: <gFKRBm4OZeLdatELxxtodHmhOE5QhneBCNtUYXv5p6w=.c5a4f18f-41f1-40da-941f-dfe262ece19e@github.com>
References: <uioAisr6LX3jfKFbYZ-KiDVpjE9LFVoJfDG6FVlDh4Q=.25e6d8a5-b9fd-463f-bd56-451b48062007@github.com>
 <gFKRBm4OZeLdatELxxtodHmhOE5QhneBCNtUYXv5p6w=.c5a4f18f-41f1-40da-941f-dfe262ece19e@github.com>
Message-ID: <UkWYlOSxqpJWGYj_B-qayG8iFmL6BxkUK1cw9ll-JWY=.aa6d7690-2a0b-42e8-8a66-7f5b62bbee31@github.com>

On Sat, 4 Dec 2021 17:42:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The documentation for following methods used object equality mentioning 'equals()'. I have replaced the equals() with == operator where necessary with some formattings.
>> 
>> sun.awt.util.IdentityLinkedList#contains
>> sun.awt.util.IdentityArrayList#contains
>> sun.awt.util.IdentityArrayList#indexOf
>> sun.awt.util.IdentityArrayList#lastIndexOf
>> sun.awt.util.IdentityArrayList#remove(java.lang.Object) 
>> 
>> Kindly review the change.
>
> Was the previous PR #6694 not good enough?  
> The previous PR has comments to the changes thus you should've referenced it when you created the new one.

> @aivanov-jdk The PR #6694 included HttpURLConnection too. I therefore closed that PR ([#6694 (review)](https://github.com/openjdk/jdk/pull/6694#pullrequestreview-823124988)) and initiated new requested with correct files and changes. As I am slightly new to git I did not know how to update the PR, so I filed a new one.

You could've just reverted the changes to `HttpURLConnection` in your branch and pushed. Effectively, it would've removed the change from the PR.

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

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


From aivanov at openjdk.java.net  Mon Dec  6 17:01:19 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 6 Dec 2021 17:01:19 GMT
Subject: RFR: 8247973: Javadoc incorrect for IdentityArrayList,
 IdentityLinkedList
In-Reply-To: <uioAisr6LX3jfKFbYZ-KiDVpjE9LFVoJfDG6FVlDh4Q=.25e6d8a5-b9fd-463f-bd56-451b48062007@github.com>
References: <uioAisr6LX3jfKFbYZ-KiDVpjE9LFVoJfDG6FVlDh4Q=.25e6d8a5-b9fd-463f-bd56-451b48062007@github.com>
Message-ID: <g3tNGpQTyRUTgyc_vAIvGw33RqsGThoVWSHmbRLb3UY=.4524d647-0b38-4bcf-939b-e68ee77a0ac8@github.com>

On Sat, 4 Dec 2021 03:07:03 GMT, ANUPAM DEV <duke at openjdk.java.net> wrote:

> The documentation for following methods used object equality mentioning 'equals()'. I have replaced the equals() with == operator where necessary with some formattings.
> 
> sun.awt.util.IdentityLinkedList#contains
> sun.awt.util.IdentityArrayList#contains
> sun.awt.util.IdentityArrayList#indexOf
> sun.awt.util.IdentityArrayList#lastIndexOf
> sun.awt.util.IdentityArrayList#remove(java.lang.Object) 
> 
> Kindly review the change.

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/sun/awt/util/IdentityLinkedList.java line 2:

> 1: /*
> 2:  * Copyright (c) 2007, 2021 Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2007, 2021, Oracle and/or its affiliates. All rights reserved.

There should be another comma.

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

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


From aivanov at openjdk.java.net  Mon Dec  6 17:10:14 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 6 Dec 2021 17:10:14 GMT
Subject: RFR: 8247973: Javadoc incorrect for IdentityArrayList,
 IdentityLinkedList
In-Reply-To: <g3tNGpQTyRUTgyc_vAIvGw33RqsGThoVWSHmbRLb3UY=.4524d647-0b38-4bcf-939b-e68ee77a0ac8@github.com>
References: <uioAisr6LX3jfKFbYZ-KiDVpjE9LFVoJfDG6FVlDh4Q=.25e6d8a5-b9fd-463f-bd56-451b48062007@github.com>
 <g3tNGpQTyRUTgyc_vAIvGw33RqsGThoVWSHmbRLb3UY=.4524d647-0b38-4bcf-939b-e68ee77a0ac8@github.com>
Message-ID: <QgcglhKNt2Dmc1P9RV-bNIopgZ3MlyrGIiDK-qCkKFI=.82abfaac-5c66-4a97-9f8c-665ee388aee3@github.com>

On Mon, 6 Dec 2021 16:57:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The documentation for following methods used object equality mentioning 'equals()'. I have replaced the equals() with == operator where necessary with some formattings.
>> 
>> sun.awt.util.IdentityLinkedList#contains
>> sun.awt.util.IdentityArrayList#contains
>> sun.awt.util.IdentityArrayList#indexOf
>> sun.awt.util.IdentityArrayList#lastIndexOf
>> sun.awt.util.IdentityArrayList#remove(java.lang.Object) 
>> 
>> Kindly review the change.
>
> src/java.desktop/share/classes/sun/awt/util/IdentityLinkedList.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2007, 2021 Oracle and/or its affiliates. All rights reserved.
> 
> Suggestion:
> 
>  * Copyright (c) 2007, 2021, Oracle and/or its affiliates. All rights reserved.
> 
> There should be another comma.

Other than that, the changes look good.

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

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


From prr at openjdk.java.net  Mon Dec  6 17:19:12 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 6 Dec 2021 17:19:12 GMT
Subject: RFR: 6462028: MaskFormatter API documentation refers to
 getDisplayValue
In-Reply-To: <62NcR6AEhkTmMH9YnM_KnoK_quyX1RlSC6nFc-dyg4U=.c078dcec-9805-4004-9d34-6eb4ae1635c7@github.com>
References: <-SOfUt64IAtAG0_rLAwkmMCCd81ZaPuTuF5ORNYuIOs=.fd151cd5-71c7-4e21-bd62-aeec7d296e76@github.com>
 <62NcR6AEhkTmMH9YnM_KnoK_quyX1RlSC6nFc-dyg4U=.c078dcec-9805-4004-9d34-6eb4ae1635c7@github.com>
Message-ID: <U2zUT6bIQ0DmXmFwLW-uVwpIxTTAIBroOstyjhqgNRI=.ed46dc9c-207f-46a1-982c-c45baac39f1f@github.com>

On Mon, 6 Dec 2021 16:21:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> MaskFormatter API doesn't have getDisplayValue method, hence removed from Documentation.
>
> src/java.desktop/share/classes/javax/swing/text/MaskFormatter.java line 103:
> 
>> 101:  *   MaskFormatter formatter = new MaskFormatter("###-####");
>> 102:  *   formatter.setPlaceholderCharacter('_');
>> 103:  *   formatter.getDisplayValue(tf, "123");
> 
> This code is part of an example, without this line, the following lines of documentation do not make sense. Probably, `getDisplayValue` should be replaced with `valueToString`. You should check that and ensure the sample and the expected output, as discussed in the following sentences, is correct.

I agree. Simply deleting this line solves nothing. The example needs to be reviewed and the text needs to say something correct and useful.

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

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


From prr at openjdk.java.net  Mon Dec  6 17:24:12 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 6 Dec 2021 17:24:12 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs
In-Reply-To: <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>
Message-ID: <_yyT1DE1iec1ea6SsjCE-wT6fBrkBrws9Co61mbukNs=.572220ae-c3a4-4363-864a-bcfcc51c0e73@github.com>

On Mon, 6 Dec 2021 16:29:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> JListBox is invalid component. CellTableEditor Interface doesn't support JComboBox and JTree components. Hence its removed from Documentation.
>
> src/java.desktop/share/classes/javax/swing/table/TableCellEditor.java line 35:
> 
>> 33:  * This interface defines the method any object that would like to be
>> 34:  * an editor of values for the component <code>JTable</code> that
>> 35:  * needs to implement.
> 
> Suggestion:
> 
>  * an editor of values for the {@code JTable} component needs to implement.
> 
> _?that?_ after `JTable` shouldn't be there.
> 
> However, I would suggest rephrasing the Javadoc to make it easier to understand: the sentence has two levels of dependent clauses.

I'm not sure this fix is going in the right direction. Isn't the doc saying that if you want to use one of these components as the cell of a JTable it should implement this interface ?
And the problem with JListBox is that it is actually just called JList ?

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

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


From asemenov at openjdk.java.net  Mon Dec  6 17:43:20 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Mon, 6 Dec 2021 17:43:20 GMT
Subject: Integrated: 8277497 Last column cell in the JTAble row is read as
 empty cell
In-Reply-To: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
References: <4U4YMD6EbbtbUdEXp7fLovboOhmYXUmug-7I-2EIwDU=.b46b4469-d651-4799-a2cf-120383139cb6@github.com>
Message-ID: <XKoeHyLdtm3__feG3nqGECKlg_WgpH40Hmikv-0thhg=.6ba23ba9-94b0-40c8-bce1-66779c015ac1@github.com>

On Wed, 24 Nov 2021 15:16:54 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> Testing https://bugs.openjdk.java.net/browse/JDK-8271071 
> Step to reproduce 
> 1) Run SwingSet2 in JDK 18 ( I used b24 ) 
> 2) Enable Voiceover. 
> 3) Select JTable demo 
> 4) Click any row in the table or select the first row . Observe that row is selected & VoiceOver reads the column values or navigate the columns one by one by pressing tab key. When the focus reaches the last column ( Favourite Food ) Observe that column value is read as null. If you hear the same then the bug is reproduced.

This pull request has now been integrated.

Changeset: 70bad89b
Author:    Artem Semenov <asemenov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/70bad89b012eb200ca1e76f384a6e5fb307cf26d
Stats:     22 lines in 1 file changed: 22 ins; 0 del; 0 mod

8277497: Last column cell in the JTAble row is read as empty cell

Reviewed-by: ant, kizune, pbansal

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

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


From prr at openjdk.java.net  Mon Dec  6 17:44:19 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 6 Dec 2021 17:44:19 GMT
Subject: RFR: 8247973: Javadoc incorrect for IdentityArrayList,
 IdentityLinkedList
In-Reply-To: <uioAisr6LX3jfKFbYZ-KiDVpjE9LFVoJfDG6FVlDh4Q=.25e6d8a5-b9fd-463f-bd56-451b48062007@github.com>
References: <uioAisr6LX3jfKFbYZ-KiDVpjE9LFVoJfDG6FVlDh4Q=.25e6d8a5-b9fd-463f-bd56-451b48062007@github.com>
Message-ID: <eY0T5MKfZXye3OFi6jqRoKZ2ea2TlbiU0rkmogkzRiQ=.d7fff83c-a245-4b27-9434-3e6f32d438c9@github.com>

On Sat, 4 Dec 2021 03:07:03 GMT, ANUPAM DEV <duke at openjdk.java.net> wrote:

> The documentation for following methods used object equality mentioning 'equals()'. I have replaced the equals() with == operator where necessary with some formattings.
> 
> sun.awt.util.IdentityLinkedList#contains
> sun.awt.util.IdentityArrayList#contains
> sun.awt.util.IdentityArrayList#indexOf
> sun.awt.util.IdentityArrayList#lastIndexOf
> sun.awt.util.IdentityArrayList#remove(java.lang.Object) 
> 
> Kindly review the change.

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.java.net  Mon Dec  6 17:45:16 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 6 Dec 2021 17:45:16 GMT
Subject: RFR: 8278251: Enable "missing-explicit-ctor" check in the
 jdk.unsupported.desktop module
In-Reply-To: <4f-QfTpojcbsiww5G7DrU7daNRNW0scSjxsPOUODdTo=.c578c7b1-2f75-4734-ae75-9c1a5c3214f4@github.com>
References: <4f-QfTpojcbsiww5G7DrU7daNRNW0scSjxsPOUODdTo=.c578c7b1-2f75-4734-ae75-9c1a5c3214f4@github.com>
Message-ID: <YhvPTCkgQWagURe3CpwEs582yZPqAHtcxwER3W9T3Kc=.e827d8c3-f24d-46b5-8698-c2c4b7ce49be@github.com>

On Fri, 3 Dec 2021 20:55:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "missing-explicit-ctor" check was disabled by the [JDK-8071961](https://bugs.openjdk.java.net/browse/JDK-8071961) and later was fixed by the [JDK-8250853](https://bugs.openjdk.java.net/browse/JDK-8250853). So we can re-enable this check again.
> 
> The fix will remove the "Java.gmk" file and as a result the "jdk.unsupported.desktop" folder.
> 
> All "Pre-submit tests" builds are green.

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.java.net  Mon Dec  6 17:54:18 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 6 Dec 2021 17:54:18 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v2]
In-Reply-To: <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
Message-ID: <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>

On Mon, 29 Nov 2021 08:18:47 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> Instead of something like
>> 
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>> 
>> we can use `return Long.compare(x, y);`
>> 
>> All replacements are done with IDE.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277868: Use Integer.signum() in BasicTableUI

src/java.desktop/share/classes/java/awt/geom/Line2D.java line 115:

> 113:          */
> 114:         public double getX1() {
> 115:             return x1;

What do these changes have to do with the subject of the PR ?

src/java.desktop/share/classes/sun/java2d/Spans.java line 322:

> 320:             float otherStart = otherSpan.getStart();
> 321: 
> 322:             return Float.compare(mStart, otherStart);

We don't need the variable any more, do we ?

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

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


From duke at openjdk.java.net  Mon Dec  6 17:54:41 2021
From: duke at openjdk.java.net (ANUPAM DEV)
Date: Mon, 6 Dec 2021 17:54:41 GMT
Subject: RFR: 8247973: Javadoc incorrect for IdentityArrayList,
 IdentityLinkedList [v2]
In-Reply-To: <uioAisr6LX3jfKFbYZ-KiDVpjE9LFVoJfDG6FVlDh4Q=.25e6d8a5-b9fd-463f-bd56-451b48062007@github.com>
References: <uioAisr6LX3jfKFbYZ-KiDVpjE9LFVoJfDG6FVlDh4Q=.25e6d8a5-b9fd-463f-bd56-451b48062007@github.com>
Message-ID: <isJhwPfkwRQv_qPqhaq1M4n7a7khteUkDlgg-qDrl18=.00a26ca8-9bb5-4136-a151-de7ae58e1aa4@github.com>

> The documentation for following methods used object equality mentioning 'equals()'. I have replaced the equals() with == operator where necessary with some formattings.
> 
> sun.awt.util.IdentityLinkedList#contains
> sun.awt.util.IdentityArrayList#contains
> sun.awt.util.IdentityArrayList#indexOf
> sun.awt.util.IdentityArrayList#lastIndexOf
> sun.awt.util.IdentityArrayList#remove(java.lang.Object) 
> 
> Kindly review the change.

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

  Update src/java.desktop/share/classes/sun/awt/util/IdentityLinkedList.java
  
  Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6710/files
  - new: https://git.openjdk.java.net/jdk/pull/6710/files/46a065c4..1bd337ac

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

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

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


From prr at openjdk.java.net  Mon Dec  6 17:57:14 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 6 Dec 2021 17:57:14 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal [v3]
In-Reply-To: <zORovjOCVMm-8yG6qtNfIrH5ICFkC5WJzL1LKMVyOJ8=.6e92825a-9fc5-4878-9659-aa70da4ed0cc@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
 <zORovjOCVMm-8yG6qtNfIrH5ICFkC5WJzL1LKMVyOJ8=.6e92825a-9fc5-4878-9659-aa70da4ed0cc@github.com>
Message-ID: <nSZ4HW0XPapNwI8DZeL4VLDLuQGT-Nl9z48R8lHsfHY=.d25aabd8-99e9-48d5-a5e0-eed809c72074@github.com>

On Wed, 1 Dec 2021 19:23:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
>> 
>> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
>> 
>> The CSR has been approved.
>> An automated test build+test run passes cleanly (FWIW :D ).
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - Merge branch 'master' into 8276447
>  - Merge branch 'master' into 8276447
>  - merge
>  - @SuppressWarnings(removal) in Windows CKey.java
>  - Add jls tag to runFinalization methods
>  - Update wording of Object.finalize, new paragraph is now bold
>  - update Object.finalize javadoc
>  - update Object.finalize JavaDoc and @deprecated tag
>  - Update Object.finalize deprecation message
>  - Indicate that runFinalizers does nothing if finalization is disabled or removed
>  - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674

Marked as reviewed by prr (Reviewer).

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

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


From aivanov at openjdk.java.net  Mon Dec  6 18:45:11 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 6 Dec 2021 18:45:11 GMT
Subject: RFR: 8247973: Javadoc incorrect for IdentityArrayList,
 IdentityLinkedList [v2]
In-Reply-To: <isJhwPfkwRQv_qPqhaq1M4n7a7khteUkDlgg-qDrl18=.00a26ca8-9bb5-4136-a151-de7ae58e1aa4@github.com>
References: <uioAisr6LX3jfKFbYZ-KiDVpjE9LFVoJfDG6FVlDh4Q=.25e6d8a5-b9fd-463f-bd56-451b48062007@github.com>
 <isJhwPfkwRQv_qPqhaq1M4n7a7khteUkDlgg-qDrl18=.00a26ca8-9bb5-4136-a151-de7ae58e1aa4@github.com>
Message-ID: <roAmsl-kOKdYV6su7EDy-Rpirt9ORrfTZBCObsI35Pw=.5b1b00c2-66ea-4f8e-90e9-f4a99a1e8c6c@github.com>

On Mon, 6 Dec 2021 17:54:41 GMT, ANUPAM DEV <duke at openjdk.java.net> wrote:

>> The documentation for following methods used object equality mentioning 'equals()'. I have replaced the equals() with == operator where necessary with some formattings.
>> 
>> sun.awt.util.IdentityLinkedList#contains
>> sun.awt.util.IdentityArrayList#contains
>> sun.awt.util.IdentityArrayList#indexOf
>> sun.awt.util.IdentityArrayList#lastIndexOf
>> sun.awt.util.IdentityArrayList#remove(java.lang.Object) 
>> 
>> Kindly review the change.
>
> ANUPAM DEV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.desktop/share/classes/sun/awt/util/IdentityLinkedList.java
>   
>   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

Marked as reviewed by aivanov (Reviewer).

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

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


From duke at openjdk.java.net  Mon Dec  6 18:50:17 2021
From: duke at openjdk.java.net (ANUPAM DEV)
Date: Mon, 6 Dec 2021 18:50:17 GMT
Subject: Integrated: 8247973: Javadoc incorrect for IdentityArrayList,
 IdentityLinkedList
In-Reply-To: <uioAisr6LX3jfKFbYZ-KiDVpjE9LFVoJfDG6FVlDh4Q=.25e6d8a5-b9fd-463f-bd56-451b48062007@github.com>
References: <uioAisr6LX3jfKFbYZ-KiDVpjE9LFVoJfDG6FVlDh4Q=.25e6d8a5-b9fd-463f-bd56-451b48062007@github.com>
Message-ID: <O2y4zYVBjxTyzx_JKo2_M6sgWXBiLrU1K7v8URwgGsI=.4c58580a-1a8c-4351-be2d-bce605e1fb53@github.com>

On Sat, 4 Dec 2021 03:07:03 GMT, ANUPAM DEV <duke at openjdk.java.net> wrote:

> The documentation for following methods used object equality mentioning 'equals()'. I have replaced the equals() with == operator where necessary with some formattings.
> 
> sun.awt.util.IdentityLinkedList#contains
> sun.awt.util.IdentityArrayList#contains
> sun.awt.util.IdentityArrayList#indexOf
> sun.awt.util.IdentityArrayList#lastIndexOf
> sun.awt.util.IdentityArrayList#remove(java.lang.Object) 
> 
> Kindly review the change.

This pull request has now been integrated.

Changeset: 239362da
Author:    ANUPAM DEV <anupam.dev at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/239362da51e70b9e968cb488b7c2ec9d91c32837
Stats:     19 lines in 2 files changed: 8 ins; 0 del; 11 mod

8247973: Javadoc incorrect for IdentityArrayList, IdentityLinkedList

Reviewed-by: aivanov, prr

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

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


From aivanov at openjdk.java.net  Mon Dec  6 19:03:17 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 6 Dec 2021 19:03:17 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs
In-Reply-To: <_yyT1DE1iec1ea6SsjCE-wT6fBrkBrws9Co61mbukNs=.572220ae-c3a4-4363-864a-bcfcc51c0e73@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>
 <_yyT1DE1iec1ea6SsjCE-wT6fBrkBrws9Co61mbukNs=.572220ae-c3a4-4363-864a-bcfcc51c0e73@github.com>
Message-ID: <V8DKXMIoAkndpo8wmWHKxpdV1TY3pFvrx1vnpYgHdPA=.810199ed-5248-4cab-8ab5-9dccb73fdbbb@github.com>

On Mon, 6 Dec 2021 17:21:34 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/table/TableCellEditor.java line 35:
>> 
>>> 33:  * This interface defines the method any object that would like to be
>>> 34:  * an editor of values for the component <code>JTable</code> that
>>> 35:  * needs to implement.
>> 
>> Suggestion:
>> 
>>  * an editor of values for the {@code JTable} component needs to implement.
>> 
>> _?that?_ after `JTable` shouldn't be there.
>> 
>> However, I would suggest rephrasing the Javadoc to make it easier to understand: the sentence has two levels of dependent clauses.
>
> I'm not sure this fix is going in the right direction. Isn't the doc saying that if you want to use one of these components as the cell of a JTable it should implement this interface ?
> And the problem with JListBox is that it is actually just called JList ?

As I read it, the interface `TableCellEditor` adds the `getTableCellEditorComponent` method to the generic `CellEditor` interface.

There's also `TreeCellEditor` interface which adds `getTreeCellEditorComponent` specifically for `JTree`. This one has a cleaner [Javadoc](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/tree/TreeCellEditor.html):

> Adds to CellEditor the extensions necessary to configure an editor in a tree.

The `TableCellEditor` interface should say something similar.

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

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


From aivanov at openjdk.java.net  Mon Dec  6 19:13:12 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 6 Dec 2021 19:13:12 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs
In-Reply-To: <V8DKXMIoAkndpo8wmWHKxpdV1TY3pFvrx1vnpYgHdPA=.810199ed-5248-4cab-8ab5-9dccb73fdbbb@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>
 <_yyT1DE1iec1ea6SsjCE-wT6fBrkBrws9Co61mbukNs=.572220ae-c3a4-4363-864a-bcfcc51c0e73@github.com>
 <V8DKXMIoAkndpo8wmWHKxpdV1TY3pFvrx1vnpYgHdPA=.810199ed-5248-4cab-8ab5-9dccb73fdbbb@github.com>
Message-ID: <CyqvNxiw5RTqonti_lmyB8fVpdt96p7gBRDyafiCWL4=.cc077480-3858-491b-9cda-11da95b95bdb@github.com>

On Mon, 6 Dec 2021 19:00:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I'm not sure this fix is going in the right direction. Isn't the doc saying that if you want to use one of these components as the cell of a JTable it should implement this interface ?
>> And the problem with JListBox is that it is actually just called JList ?
>
> As I read it, the interface `TableCellEditor` adds the `getTableCellEditorComponent` method to the generic `CellEditor` interface.
> 
> There's also `TreeCellEditor` interface which adds `getTreeCellEditorComponent` specifically for `JTree`. This one has a cleaner [Javadoc](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/tree/TreeCellEditor.html):
> 
>> Adds to CellEditor the extensions necessary to configure an editor in a tree.
> 
> The `TableCellEditor` interface should say something similar.

Currently, the Javadoc says, ??that would like to be an editor of values _for components_ such as JListBox, JComboBox, JTree, or JTable?? Yet the interface adds a method which is relevant for `JTable` only. `JList` has no cell editor. `JComboBox` uses its own `ComboBoxEditor` interface, and `JTree` uses `TreeCellEditor`.

So, I think we're in the right direction.

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

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


From darcy at openjdk.java.net  Mon Dec  6 19:35:17 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 6 Dec 2021 19:35:17 GMT
Subject: RFR: 8278251: Enable "missing-explicit-ctor" check in the
 jdk.unsupported.desktop module
In-Reply-To: <4f-QfTpojcbsiww5G7DrU7daNRNW0scSjxsPOUODdTo=.c578c7b1-2f75-4734-ae75-9c1a5c3214f4@github.com>
References: <4f-QfTpojcbsiww5G7DrU7daNRNW0scSjxsPOUODdTo=.c578c7b1-2f75-4734-ae75-9c1a5c3214f4@github.com>
Message-ID: <Lbkh72MTEv9ywiDHMpwLFAfJhdZ3TUikp0qztfJ2WFs=.dfc74aa8-a33e-401f-8c27-f1fb2106d8bd@github.com>

On Fri, 3 Dec 2021 20:55:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "missing-explicit-ctor" check was disabled by the [JDK-8071961](https://bugs.openjdk.java.net/browse/JDK-8071961) and later was fixed by the [JDK-8250853](https://bugs.openjdk.java.net/browse/JDK-8250853). So we can re-enable this check again.
> 
> The fix will remove the "Java.gmk" file and as a result the "jdk.unsupported.desktop" folder.
> 
> All "Pre-submit tests" builds are green.

Not a reviewer for this particular change, but I support its goals.

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

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


From bchristi at openjdk.java.net  Mon Dec  6 20:41:43 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Mon, 6 Dec 2021 20:41:43 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal [v4]
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <yjAb3SVdTAs6VQz9haonP9y-ZnXker4ZyskjKghmwH0=.c6841727-32de-4840-94d8-4ae568a157fe@github.com>

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Merge branch 'master' into 8276447
 - Merge branch 'master' into 8276447
 - Merge branch 'master' into 8276447
 - merge
 - @SuppressWarnings(removal) in Windows CKey.java
 - Add jls tag to runFinalization methods
 - Update wording of Object.finalize, new paragraph is now bold
 - update Object.finalize javadoc
 - update Object.finalize JavaDoc and @deprecated tag
 - Update Object.finalize deprecation message
 - ... and 24 more: https://git.openjdk.java.net/jdk/compare/ea8d3c92...0a983d51

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

Changes: https://git.openjdk.java.net/jdk/pull/6465/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=03
  Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465

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


From aivanov at openjdk.java.net  Mon Dec  6 21:52:16 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 6 Dec 2021 21:52:16 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits [v3]
In-Reply-To: <LW_FNYfYokGel6M-2ac2-5DELKlMxxFpsmrN4GR-xyk=.1231a46b-cfac-4644-a8bd-1b8dccebd0d3@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
 <lGOPpqu2uYGZHV_GkjysSB5dyq9Z9AOEIRZbr_vMahU=.398430c1-2050-4c19-a352-fe4738507ca2@github.com>
 <UnIxQhGmGoSevWYrHsHgaqG4X5FCT8ZEemLq2F3qQv4=.c439ac5a-7e1a-4e0b-ab1b-9181fd1ff19c@github.com>
 <8No3mHp1lnZqHb2ptNIhnqk0By-nvY_ziROsgwiw5vo=.8461c16a-f88d-40de-ae2f-c3af16aad281@github.com>
 <_p_UCYxPb7a8sImvlIBHWSywpCU4fh7Vht2KJniHhFo=.2d0a9c43-b8ca-44d6-b86e-1f4f45e123d2@github.com>
 <s7C3pSlSZ1Uug3nZVmOWXJnPToIGN8CC83uEL7wHi_s=.04db1301-87b9-4243-b650-1bdb64ca8c92@github.com>
 <LW_FNYfYokGel6M-2ac2-5DELKlMxxFpsmrN4GR-xyk=.1231a46b-cfac-4644-a8bd-1b8dccebd0d3@github.com>
Message-ID: <gWedu3gal3_JcAklbH_lFgXB2KdxpOX_7knn17swQp4=.5a2c8f94-deed-4758-8a75-4b63e6e2a06e@github.com>

On Sat, 4 Dec 2021 19:29:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Can't we call it explicitly in the case where colorBits == NULL?
>> 
>> I would use the default handlers for bad_alloc since they can be changed in feature and keeping code that is intended to be used in two places is usually not a good idea.
>> 
>>> Alternatively, since you don't use the macros for try and catch, you can re-arrange code and perform cleanup after the catch-block. Just an idea? It may not work.
>> 
>> That might require a lot of code reformatting and the benefits are unclear.
>
>> > Alternatively, since you don't use the macros for try and catch, you can re-arrange code and perform cleanup after the catch-block. Just an idea? It may not work.
>> 
>> That might require a lot of code reformatting and the benefits are unclear.
> 
> I tried it, it doesn't, [see this diff](https://github.com/aivanov-jdk/jdk/commit/ccf7500cf0e4614b12c0882204a81d928fce0a82). It's close to your latest code, however, there's only one `catch` that handles both allocations and there are no `if`'s inside the `try`-block.

What about this approach?
[Compared to master](https://github.com/openjdk/jdk/compare/master...aivanov-jdk:8277299-bad-alloc-w32)
[Compared to your latest code](https://github.com/azuev-java/jdk/compare/JDK-8277299...aivanov-jdk:8277299-bad-alloc-w32)

I think it's cleaner in the use of exceptions. Each try-block allocates memory that it uses and frees it before the catch-block. There's no need for if's: if exception is thrown, the memory wasn't allocated, therefore the memory is freed only if no exception is thrown.

What do you think?

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

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


From achung at openjdk.java.net  Mon Dec  6 21:54:13 2021
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 6 Dec 2021 21:54:13 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v4]
In-Reply-To: <KQs-SPRW1jQvyJKBUgN7X5Z2hddDa2HUlivHXatlFNk=.24644c1a-0442-428d-8924-34117e606f27@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <icSGKnOryPHI_yd-HKjSmURmjwpfb0joZm533GHrsEo=.231a05f3-31a7-4c31-8aa1-01aa0ea5fe8f@github.com>
 <zxNsIG35aBhe9D8ry7rs8s1vnYtqZXcVSj13IGwYPs4=.baeb4de9-3292-4a97-9cc0-f441aebd1b12@github.com>
 <lL2zcy61qbI4QXPWknffRqvgQfU3zS49BvrUQFgrSXE=.fe7927c5-e2fc-4ea5-a852-2773e841de21@github.com>
 <heJWxX2cWSgjLWJPo2p-AJEoLSONuHy3xsiU1z6gEPA=.da4827c5-ee15-43ab-a3fd-3847ea5b6ed5@github.com>
 <mmmup2BcJqqo5hEL_kZQox0XclYD8JcNhNy44C-ufTc=.7b8b7759-2920-48eb-9e57-193ea37d97e5@github.com>
 <JpTi6eQxwsNVbuVusQepyScPFN2BVaQYuzWxLIyiDnY=.3877aa41-6743-4f05-b3a8-f1eaa93b57e0@github.com>
 <KQs-SPRW1jQvyJKBUgN7X5Z2hddDa2HUlivHXatlFNk=.24644c1a-0442-428d-8924-34117e606f27@github.com>
Message-ID: <UEMNZQYQW7ILI4S-pLC3d3kD2zQz2zxeHT5AhZ_1HYc=.25478ce9-e252-4f44-8d11-837dce801670@github.com>

On Fri, 3 Dec 2021 19:13:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> You can render directly to the BufferedImage instead of the JFrame, so in this case, it will not be necessary to use a robot, you will be able to check the pixel directly.
>
> For example, you can take a look at the JButtonPaintNPE or TestBadBreak tests.

In the TestBadBreak example, how do you know it's properly painting onto the final BufferedImage? When I try the same it doesn't seem to be painting anything on the BufferedImage, so there's no colors to compare.

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

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


From aivanov at openjdk.java.net  Mon Dec  6 22:27:23 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 6 Dec 2021 22:27:23 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v7]
In-Reply-To: <29otHmFYbrgY0zuOeXw2NFz5V2Q0YZIKu18THN1yGPQ=.3ca8bf18-8c44-402c-a971-eece3da26c4c@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <29otHmFYbrgY0zuOeXw2NFz5V2Q0YZIKu18THN1yGPQ=.3ca8bf18-8c44-402c-a971-eece3da26c4c@github.com>
Message-ID: <gYS_O_hJM-3rGj_b6BGKSm0KUornq0dJ7n1yVb00m3c=.1e2cc126-e2d7-4dfa-ac4f-b32511682209@github.com>

On Thu, 2 Dec 2021 19:57:54 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed robot mouse moves, use pixel colors to check

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 89:

> 87:     public static void main(String[] args) {
> 88:         ScrollBarBorderTest borderTest = new ScrollBarBorderTest();
> 89:         borderTest.createAndShowGUI();

You're using Swing which is not thread-safe. You should create and access Swing components from the Event Dispatch Thread only.

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

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


From aivanov at openjdk.java.net  Mon Dec  6 22:27:23 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 6 Dec 2021 22:27:23 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v4]
In-Reply-To: <UEMNZQYQW7ILI4S-pLC3d3kD2zQz2zxeHT5AhZ_1HYc=.25478ce9-e252-4f44-8d11-837dce801670@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <icSGKnOryPHI_yd-HKjSmURmjwpfb0joZm533GHrsEo=.231a05f3-31a7-4c31-8aa1-01aa0ea5fe8f@github.com>
 <zxNsIG35aBhe9D8ry7rs8s1vnYtqZXcVSj13IGwYPs4=.baeb4de9-3292-4a97-9cc0-f441aebd1b12@github.com>
 <lL2zcy61qbI4QXPWknffRqvgQfU3zS49BvrUQFgrSXE=.fe7927c5-e2fc-4ea5-a852-2773e841de21@github.com>
 <heJWxX2cWSgjLWJPo2p-AJEoLSONuHy3xsiU1z6gEPA=.da4827c5-ee15-43ab-a3fd-3847ea5b6ed5@github.com>
 <mmmup2BcJqqo5hEL_kZQox0XclYD8JcNhNy44C-ufTc=.7b8b7759-2920-48eb-9e57-193ea37d97e5@github.com>
 <JpTi6eQxwsNVbuVusQepyScPFN2BVaQYuzWxLIyiDnY=.3877aa41-6743-4f05-b3a8-f1eaa93b57e0@github.com>
 <KQs-SPRW1jQvyJKBUgN7X5Z2hddDa2HUlivHXatlFNk=.24644c1a-0442-428d-8924-34117e606f27@github.com>
 <UEMNZQYQW7ILI4S-pLC3d3kD2zQz2zxeHT5AhZ_1HYc=.25478ce9-e252-4f44-8d11-837dce801670@github.com>
Message-ID: <4Z1J_H2sXmOYQE6yEUjZA0Odux8IZ6a63dWciigvUpo=.81fe0e5e-ea85-4a11-b6f2-0605265f5e00@github.com>

On Mon, 6 Dec 2021 21:51:11 GMT, Alisen Chung <achung at openjdk.org> wrote:

> In the TestBadBreak example, how do you know it's properly painting onto the final BufferedImage? When I try the same it doesn't seem to be painting anything on the BufferedImage, so there's no colors to compare.

How do you paint the frame into BufferedImage?
You may need to set the size of the frame explicitly.

There are many tests which paint components to the image. You can also take a look at test/jdk/javax/swing/text/FlowView/6318524/bug6318524.java and test/jdk/javax/swing/text/ParagraphView/6364882/bug6364882.java. Each of these two provides an option to save the BufferedImage to a file.

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

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


From achung at openjdk.java.net  Mon Dec  6 22:45:37 2021
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 6 Dec 2021 22:45:37 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v8]
In-Reply-To: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
Message-ID: <d8JPL79WVhhKfRSXltnze4Wo-Z8rD-lW9dl8PLySl_Q=.cf35ab98-19d3-4817-8fd5-fb09e95a9a3e@github.com>

> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.

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

  need to fix comparison of BufferedImages

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6374/files
  - new: https://git.openjdk.java.net/jdk/pull/6374/files/52edbf4e..24575e58

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

  Stats: 105 lines in 1 file changed: 46 ins; 41 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6374.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6374/head:pull/6374

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


From achung at openjdk.java.net  Mon Dec  6 23:04:13 2021
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 6 Dec 2021 23:04:13 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v4]
In-Reply-To: <4Z1J_H2sXmOYQE6yEUjZA0Odux8IZ6a63dWciigvUpo=.81fe0e5e-ea85-4a11-b6f2-0605265f5e00@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <icSGKnOryPHI_yd-HKjSmURmjwpfb0joZm533GHrsEo=.231a05f3-31a7-4c31-8aa1-01aa0ea5fe8f@github.com>
 <zxNsIG35aBhe9D8ry7rs8s1vnYtqZXcVSj13IGwYPs4=.baeb4de9-3292-4a97-9cc0-f441aebd1b12@github.com>
 <lL2zcy61qbI4QXPWknffRqvgQfU3zS49BvrUQFgrSXE=.fe7927c5-e2fc-4ea5-a852-2773e841de21@github.com>
 <heJWxX2cWSgjLWJPo2p-AJEoLSONuHy3xsiU1z6gEPA=.da4827c5-ee15-43ab-a3fd-3847ea5b6ed5@github.com>
 <mmmup2BcJqqo5hEL_kZQox0XclYD8JcNhNy44C-ufTc=.7b8b7759-2920-48eb-9e57-193ea37d97e5@github.com>
 <JpTi6eQxwsNVbuVusQepyScPFN2BVaQYuzWxLIyiDnY=.3877aa41-6743-4f05-b3a8-f1eaa93b57e0@github.com>
 <KQs-SPRW1jQvyJKBUgN7X5Z2hddDa2HUlivHXatlFNk=.24644c1a-0442-428d-8924-34117e606f27@github.com>
 <UEMNZQYQW7ILI4S-pLC3d3kD2zQz2zxeHT5AhZ_1HYc=.25478ce9-e252-4f44-8d11-837dce801670@github.com>
 <4Z1J_H2sXmOYQE6yEUjZA0Odux8IZ6a63dWciigvUpo=.81fe0e5e-ea85-4a11-b6f2-0605265f5e00@github.com>
Message-ID: <kaR0HvVJRmDQ3szg40zxPMMJ7s7dHE8zOgNpqW0m-ks=.77af7944-4c63-4039-8dde-3dfdc289b3c6@github.com>

On Mon, 6 Dec 2021 22:21:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> How do you paint the frame into BufferedImage?
You may need to set the size of the frame explicitly.

I'm overriding the paintComponent method of JPanel to instead directly paint onto a BufferedImage that I passed in, similar to the TestBadBreak example.

I pushed what I have so far, but it seems like the BufferedImage is blank

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

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


From aivanov at openjdk.java.net  Mon Dec  6 23:26:14 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 6 Dec 2021 23:26:14 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v4]
In-Reply-To: <kaR0HvVJRmDQ3szg40zxPMMJ7s7dHE8zOgNpqW0m-ks=.77af7944-4c63-4039-8dde-3dfdc289b3c6@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <icSGKnOryPHI_yd-HKjSmURmjwpfb0joZm533GHrsEo=.231a05f3-31a7-4c31-8aa1-01aa0ea5fe8f@github.com>
 <zxNsIG35aBhe9D8ry7rs8s1vnYtqZXcVSj13IGwYPs4=.baeb4de9-3292-4a97-9cc0-f441aebd1b12@github.com>
 <lL2zcy61qbI4QXPWknffRqvgQfU3zS49BvrUQFgrSXE=.fe7927c5-e2fc-4ea5-a852-2773e841de21@github.com>
 <heJWxX2cWSgjLWJPo2p-AJEoLSONuHy3xsiU1z6gEPA=.da4827c5-ee15-43ab-a3fd-3847ea5b6ed5@github.com>
 <mmmup2BcJqqo5hEL_kZQox0XclYD8JcNhNy44C-ufTc=.7b8b7759-2920-48eb-9e57-193ea37d97e5@github.com>
 <JpTi6eQxwsNVbuVusQepyScPFN2BVaQYuzWxLIyiDnY=.3877aa41-6743-4f05-b3a8-f1eaa93b57e0@github.com>
 <KQs-SPRW1jQvyJKBUgN7X5Z2hddDa2HUlivHXatlFNk=.24644c1a-0442-428d-8924-34117e606f27@github.com>
 <UEMNZQYQW7ILI4S-pLC3d3kD2zQz2zxeHT5AhZ_1HYc=.25478ce9-e252-4f44-8d11-837dce801670@github.com>
 <4Z1J_H2sXmOYQE6yEUjZA0Odux8IZ6a63dWciigvUpo=.81fe0e5e-ea85-4a11-b6f2-0605265f5e00@github.com>
 <kaR0HvVJRmDQ3szg40zxPMMJ7s7dHE8zOgN
 pqW0m-ks=.77af7944-4c63-4039-8dde-3dfdc289b3c6@github.com>
Message-ID: <zO8LePhopVA9hixloBU7i9q6qOdWNfJ-QSMw2er7AyY=.a1c90218-3e24-4e22-bb68-8107cb7047ca@github.com>

On Mon, 6 Dec 2021 23:01:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

>>> In the TestBadBreak example, how do you know it's properly painting onto the final BufferedImage? When I try the same it doesn't seem to be painting anything on the BufferedImage, so there's no colors to compare.
>> 
>> How do you paint the frame into BufferedImage?
>> You may need to set the size of the frame explicitly.
>> 
>> There are many tests which paint components to the image. You can also take a look at test/jdk/javax/swing/text/FlowView/6318524/bug6318524.java and test/jdk/javax/swing/text/ParagraphView/6364882/bug6364882.java. Each of these two provides an option to save the BufferedImage to a file.
>
>> How do you paint the frame into BufferedImage?
> You may need to set the size of the frame explicitly.
> 
> I'm overriding the paintComponent method of JPanel to instead directly paint onto a BufferedImage that I passed in, similar to the TestBadBreak example.
> 
> I pushed what I have so far, but it seems like the BufferedImage is blank

The image is blank because this method is never called. `TestBadBreak` relies on the frame being shown, it adds the component into the frame and shows the frame to capture what's painted. You don't add the `panel` into the frame, therefore it's never painted.

Try to paint into the image directly, after you configured the panel, that is after `panel.add(scrollBar);`, call:


Graphics2D graphics2D = image.createGraphics();
panel.paint(graphics2D);
graphics2D.dispose();


Then you can analyse the colour of pixels on the image just like you do now with robot.

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

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


From serb at openjdk.java.net  Tue Dec  7 00:22:23 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 7 Dec 2021 00:22:23 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v5]
In-Reply-To: <lsnERzsABwhOgn2Itr7MazN_fUZBEH_nB9e_j7g_7BY=.6b45f8fc-9537-40dc-979c-1d5f8e1aec26@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <lsnERzsABwhOgn2Itr7MazN_fUZBEH_nB9e_j7g_7BY=.6b45f8fc-9537-40dc-979c-1d5f8e1aec26@github.com>
Message-ID: <d4pIyzaPq0VOkf9ax4T8QhfLbWboz9FQG8kWIJeO_D0=.7791ddc9-bc18-4a16-9bc6-582ef3e6af1a@github.com>

On Thu, 2 Dec 2021 06:27:01 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add uninstallColorsAndFont

I think it is fine, need to run the tests for the change since it can uncover some hidden issues.

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

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


From cushon at openjdk.java.net  Tue Dec  7 05:03:27 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 7 Dec 2021 05:03:27 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v6]
In-Reply-To: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
Message-ID: <KakmTnnPwFyrOnjH7Dzh-dxokgMP8zpgWHN4nJ9az-c=.e74d8f2d-0ce0-42fd-87ae-55e08366aead@github.com>

> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).

Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Add uninstallColorsAndFont
 - 8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy

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

Changes: https://git.openjdk.java.net/jdk/pull/6603/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6603&range=05
  Stats: 64 lines in 28 files changed: 58 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6603.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6603/head:pull/6603

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


From duke at openjdk.java.net  Tue Dec  7 05:24:17 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Tue, 7 Dec 2021 05:24:17 GMT
Subject: RFR: 6462028: MaskFormatter API documentation refers to
 getDisplayValue
In-Reply-To: <U2zUT6bIQ0DmXmFwLW-uVwpIxTTAIBroOstyjhqgNRI=.ed46dc9c-207f-46a1-982c-c45baac39f1f@github.com>
References: <-SOfUt64IAtAG0_rLAwkmMCCd81ZaPuTuF5ORNYuIOs=.fd151cd5-71c7-4e21-bd62-aeec7d296e76@github.com>
 <62NcR6AEhkTmMH9YnM_KnoK_quyX1RlSC6nFc-dyg4U=.c078dcec-9805-4004-9d34-6eb4ae1635c7@github.com>
 <U2zUT6bIQ0DmXmFwLW-uVwpIxTTAIBroOstyjhqgNRI=.ed46dc9c-207f-46a1-982c-c45baac39f1f@github.com>
Message-ID: <8PTMn3OTqBW5GdNwAT-Um1CGccVLdJZ9Gu1suQDKqxE=.8ae0f73d-7015-44e9-befa-2473833d5be3@github.com>

On Mon, 6 Dec 2021 17:16:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/MaskFormatter.java line 103:
>> 
>>> 101:  *   MaskFormatter formatter = new MaskFormatter("###-####");
>>> 102:  *   formatter.setPlaceholderCharacter('_');
>>> 103:  *   formatter.getDisplayValue(tf, "123");
>> 
>> This code is part of an example, without this line, the following lines of documentation do not make sense. Probably, `getDisplayValue` should be replaced with `valueToString`. You should check that and ensure the sample and the expected output, as discussed in the following sentences, is correct.
>
> I agree. Simply deleting this line solves nothing. The example needs to be reviewed and the text needs to say something correct and useful.

Yeah, I've checked with `valueToString` method, its working fine. I'll replace `getDisplayValue` with `valueToString`? ValueToString takes one parameter which is of Object type. It return the formated value.
Sample Code:
        MaskFormatter formatter = new MaskFormatter("###-##");
        formatter.setPlaceholderCharacter('*');
        System.out.println(formatter.valueToString("87"));

Output:
87*-**

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

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


From duke at openjdk.java.net  Tue Dec  7 08:19:22 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Dec 2021 08:19:22 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v2]
In-Reply-To: <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
 <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>
Message-ID: <M-z5np-jBcXgwf7reKgKDLkhCH5wQVIfpumzo3Vclj4=.ff1778e3-6e95-44fe-8ab8-5ed947765bdf@github.com>

On Mon, 6 Dec 2021 17:46:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277868: Use Integer.signum() in BasicTableUI
>
> src/java.desktop/share/classes/java/awt/geom/Line2D.java line 115:
> 
>> 113:          */
>> 114:         public double getX1() {
>> 115:             return x1;
> 
> What do these changes have to do with the subject of the PR ?

Just a tiny clean-up in on of affected files. Do you want this to be reverted?

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

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


From duke at openjdk.java.net  Tue Dec  7 08:28:47 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Dec 2021 08:28:47 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v3]
In-Reply-To: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
Message-ID: <HTd3akuVxFHjNnOqUf1gEFBr67raD8-XU8KZWXlicIo=.6836f96c-3fee-40fd-8c3d-8ee92fa69654@github.com>

> Instead of something like
> 
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
> 
> we can use `return Long.compare(x, y);`
> 
> All replacements are done with IDE.

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

  8277868: Inline local var

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6575/files
  - new: https://git.openjdk.java.net/jdk/pull/6575/files/6744a562..1b3a5d4b

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

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

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


From duke at openjdk.java.net  Tue Dec  7 08:54:13 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Dec 2021 08:54:13 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v2]
In-Reply-To: <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
 <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>
Message-ID: <xdI5FAZqZeQHMoHxBRdogY8q6Q3K20lfn9baQ4RHpkc=.23bdf93d-a1e4-46f0-8002-ef66029ffe1e@github.com>

On Mon, 6 Dec 2021 17:48:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277868: Use Integer.signum() in BasicTableUI
>
> src/java.desktop/share/classes/sun/java2d/Spans.java line 322:
> 
>> 320:             float otherStart = otherSpan.getStart();
>> 321: 
>> 322:             return Float.compare(mStart, otherStart);
> 
> We don't need the variable any more, do we ?

inlined

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

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


From jdv at openjdk.java.net  Tue Dec  7 09:48:13 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 7 Dec 2021 09:48:13 GMT
Subject: RFR: 8272392 Lanai: SwingSet2. Black background on expanding tree
 node [v2]
In-Reply-To: <B61IptEwXdJP-IbySF2OroCk3lYR_Bs8n_aC9euZGYQ=.39cfca56-1f8d-444c-85e9-948e520051b2@github.com>
References: <j43XsVmt-JoPBbf2zmSprcycbHlkZF2GSBXas3T7BRk=.fcee72ac-9edf-423d-b71d-89612e6d2e52@github.com>
 <ZhxCWZQrZE57-8hUr_JUz37dbf5OfxVvBJFBV7bYlTk=.0a1666e2-db3d-4cb4-8a73-dfc1a7fced02@github.com>
 <K7LmUFlnX3OT5aRI9mIvYtVrhwQLxvyjdQ87OZzaAWo=.195c33d3-c7dc-4f82-90e5-e71fc2aab953@github.com>
 <B61IptEwXdJP-IbySF2OroCk3lYR_Bs8n_aC9euZGYQ=.39cfca56-1f8d-444c-85e9-948e520051b2@github.com>
Message-ID: <UaZO994Om9sOia1Lpn-4-UVmaQozuSV2CV45S39hi2I=.81e12374-8131-4922-a619-64ed46a7c339@github.com>

On Fri, 3 Dec 2021 15:39:12 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> > I used test case present in https://bugs.openjdk.java.net/browse/JDK-8267963 to check how it behaves with this PR and noticed that it is causes regresssion related to how ruler text looks and also if we move Ruler between monitors it doesnt draw.
> > Thought this may be because of state's not getting reset since there is mismatch in EncoderManager.reset() arguments. Updated code to add isText argument over this PR, but i continue to see the regressions.
> 
> @jayathirthrao could you please provide some more info about your environment. I cannot reproduce the problems that you've reported with the test from JDK-8267963.

Strange that i am not seeing the issue i noticed last week in my system. SwingSet2, J2DDemo and Font2DTest are not showing any regressions. I am running some tests with Metal API validation. If tests are green i will approve. @aghaisas also wants to run some tests on discrete graphics, so lets wait for his approval also.

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

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


From myano at openjdk.java.net  Tue Dec  7 11:09:18 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Tue, 7 Dec 2021 11:09:18 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <XNGsAkbvY13zmHrSmo3LpPDQNQNb97ocf_501nLgCMY=.da8f1bf4-c305-4e32-9d39-b2ab01a3da26@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <-hj0v7RZ0HPpP9GND5csZsZ1Vz7oxaufOAC0-ZygtwM=.6a5ae7a8-52d6-4e3e-a166-2fae2c23dbe0@github.com>
 <cTqTWZsK6uJI_Kw9nUymKQnYxxzWBRrk52qJAKpAc9I=.18f7dffd-3ebe-4bd0-bc2f-d61b55437036@github.com>
 <aZX6pJkrGOTYLlAHRl9WlEGtoahiInx4QzelDWpV2b0=.c9a736f9-5dd5-4382-8513-94a0233105dc@github.com>
 <QPyLlBXqr80h-_OjGxuv6tGNl8_-IZ8IHF-_8QWy894=.b18fd0a2-4497-4aae-87b1-1570531f2862@github.com>
 <2rBhm1b2wZwnJFYIve6hdNLHFE0iAkGbj1GkDkSOUCs=.726e6e6a-76b6-4657-b44b-dd854769055c@github.com>
 <k1gQRfQhMEC2tFwq5ZyyEmfebNqR6Mws651ijtdhTc8=.57c33d5c-9b6e-4b6c-9f4b-0afae0d0615f@github.com>
 <XNGsAkbvY13zmHrSmo3LpPDQNQNb97ocf_501nLgCMY=.da8f1bf4-c305-4e32-9d39-b2ab01a3da26@github.com>
Message-ID: <OUr2MmcWb3DV5vwFz_MvaF7QcMzx5BRWQhyXCsAcBq4=.c445fb6a-dbfe-4eb1-a95b-5dd2fdaf8a26@github.com>

On Thu, 18 Nov 2021 00:02:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @mrserb Can I hope this fix will be integrated after JDK-8270874 is fixed?
>
> Yes.

@mrserb Could you please check this pull request?

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

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


From aivanov at openjdk.java.net  Tue Dec  7 12:01:16 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Dec 2021 12:01:16 GMT
Subject: RFR: 6462028: MaskFormatter API documentation refers to
 getDisplayValue
In-Reply-To: <8PTMn3OTqBW5GdNwAT-Um1CGccVLdJZ9Gu1suQDKqxE=.8ae0f73d-7015-44e9-befa-2473833d5be3@github.com>
References: <-SOfUt64IAtAG0_rLAwkmMCCd81ZaPuTuF5ORNYuIOs=.fd151cd5-71c7-4e21-bd62-aeec7d296e76@github.com>
 <62NcR6AEhkTmMH9YnM_KnoK_quyX1RlSC6nFc-dyg4U=.c078dcec-9805-4004-9d34-6eb4ae1635c7@github.com>
 <U2zUT6bIQ0DmXmFwLW-uVwpIxTTAIBroOstyjhqgNRI=.ed46dc9c-207f-46a1-982c-c45baac39f1f@github.com>
 <8PTMn3OTqBW5GdNwAT-Um1CGccVLdJZ9Gu1suQDKqxE=.8ae0f73d-7015-44e9-befa-2473833d5be3@github.com>
Message-ID: <UQaeaRPIy2108CVP1CXTlscFSRJaHg5cjOTrrfdqmxA=.64e66b82-063b-4072-84ff-094fbf5677f6@github.com>

On Tue, 7 Dec 2021 05:20:42 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> I agree. Simply deleting this line solves nothing. The example needs to be reviewed and the text needs to say something correct and useful.
>
> Yeah, I've checked with `valueToString` method, its working fine. I'll replace `getDisplayValue` with `valueToString`? ValueToString takes one parameter which is of Object type. It return the formated value.
> Sample Code:
>         MaskFormatter formatter = new MaskFormatter("###-##");
>         formatter.setPlaceholderCharacter('*');
>         System.out.println(formatter.valueToString("87"));
> 
> Output:
> 87*-**

Yes, this will make the example correct.

This sample code demonstrates what is discussed in the docs:

MaskFormatter formatter = new MaskFormatter("###-####");
formatter.setPlaceholderCharacter('_');
System.out.println(formatter.valueToString("123"));

formatter = new MaskFormatter("###-####");
formatter.setPlaceholderCharacter('*');
formatter.setPlaceholder("555-1212");
System.out.println(formatter.valueToString("123"));

and produces the output:

123-____
123-1212

which perfectly aligns with the documentation.

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

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


From aivanov at openjdk.java.net  Tue Dec  7 12:28:17 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Dec 2021 12:28:17 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v3]
In-Reply-To: <HTd3akuVxFHjNnOqUf1gEFBr67raD8-XU8KZWXlicIo=.6836f96c-3fee-40fd-8c3d-8ee92fa69654@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <HTd3akuVxFHjNnOqUf1gEFBr67raD8-XU8KZWXlicIo=.6836f96c-3fee-40fd-8c3d-8ee92fa69654@github.com>
Message-ID: <qzfCWMEJDBk5Yykg-AmLOT1lSOgq6zKYWDwj8cXBi8M=.a040086d-8e24-42fa-ad45-8bd917a22799@github.com>

On Tue, 7 Dec 2021 08:28:47 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> Instead of something like
>> 
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>> 
>> we can use `return Long.compare(x, y);`
>> 
>> All replacements are done with IDE.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277868: Inline local var

src/java.base/share/classes/java/util/Calendar.java line 3420:

> 3418:     private int compareTo(long t) {
> 3419:         long thisTime = getMillisOf(this);
> 3420:         return Long.compare(thisTime, t);

Probably, in this case `thisTime` variable can also be dropped.

src/java.base/share/classes/java/util/Date.java line 977:

> 975:         long thisTime = getMillisOf(this);
> 976:         long anotherTime = getMillisOf(anotherDate);
> 977:         return Long.compare(thisTime, anotherTime);

Looks like local variables can also be dropped here as each value is used once.

src/java.base/share/classes/java/util/UUID.java line 517:

> 515:         return (this.mostSigBits < val.mostSigBits ? -1 :
> 516:                 (this.mostSigBits > val.mostSigBits ? 1 :
> 517:                  Long.compare(this.leastSigBits, val.leastSigBits)));

In this case Javadoc specifies only -1, 0 or 1 can be returned. `Long.compare` does not specify this but returns these values. Couldn't it cause any problems in the future if implementation of `Long.compare` is changed?

Does it make sense to use `Long.compare` for `mostSigBits` too?

int mostSigBits = Long.compare(this.mostSigBits, val.mostSigBits);
return mostSigBits != 0 ? mostSigBits : Long.compare(this.leastSigBits, val.leastSigBits);

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

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


From aivanov at openjdk.java.net  Tue Dec  7 12:28:17 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Dec 2021 12:28:17 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v2]
In-Reply-To: <M-z5np-jBcXgwf7reKgKDLkhCH5wQVIfpumzo3Vclj4=.ff1778e3-6e95-44fe-8ab8-5ed947765bdf@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
 <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>
 <M-z5np-jBcXgwf7reKgKDLkhCH5wQVIfpumzo3Vclj4=.ff1778e3-6e95-44fe-8ab8-5ed947765bdf@github.com>
Message-ID: <9S_GeeZQl7DEU-sc0rPTWTs-rECNOmwEQRsj-zMotqU=.4f156b22-5909-4451-8652-9af749bb288f@github.com>

On Tue, 7 Dec 2021 08:16:08 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> src/java.desktop/share/classes/java/awt/geom/Line2D.java line 115:
>> 
>>> 113:          */
>>> 114:         public double getX1() {
>>> 115:             return x1;
>> 
>> What do these changes have to do with the subject of the PR ?
>
> Just a tiny clean-up in on of affected files. Do you want this to be reverted?

I believe it makes to preserve the cast: the fields are of type `float` and explicit cast hints there's a type conversion.

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

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


From duke at openjdk.java.net  Tue Dec  7 14:39:46 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Dec 2021 14:39:46 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v4]
In-Reply-To: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
Message-ID: <6H721EvqNvo4S4PAIRiqFgVtORHDFVjUW_nQ3LJIdvM=.685ca0ab-0ba9-4501-9e4e-6de9ca93be51@github.com>

> Instead of something like
> 
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
> 
> we can use `return Long.compare(x, y);`
> 
> All replacements are done with IDE.

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

 - 8277868: Revert irrelevant changes
 - 8277868: Inline local vars

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6575/files
  - new: https://git.openjdk.java.net/jdk/pull/6575/files/1b3a5d4b..bb06bf2f

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

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

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


From duke at openjdk.java.net  Tue Dec  7 14:39:51 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Dec 2021 14:39:51 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v3]
In-Reply-To: <qzfCWMEJDBk5Yykg-AmLOT1lSOgq6zKYWDwj8cXBi8M=.a040086d-8e24-42fa-ad45-8bd917a22799@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <HTd3akuVxFHjNnOqUf1gEFBr67raD8-XU8KZWXlicIo=.6836f96c-3fee-40fd-8c3d-8ee92fa69654@github.com>
 <qzfCWMEJDBk5Yykg-AmLOT1lSOgq6zKYWDwj8cXBi8M=.a040086d-8e24-42fa-ad45-8bd917a22799@github.com>
Message-ID: <RfAx0opkX4lKUfu0edbgotzC4KFnDpeipa3-1_109mI=.232d9ebe-15be-475f-a720-c6165dcb0b3c@github.com>

On Tue, 7 Dec 2021 12:01:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277868: Inline local var
>
> src/java.base/share/classes/java/util/Calendar.java line 3420:
> 
>> 3418:     private int compareTo(long t) {
>> 3419:         long thisTime = getMillisOf(this);
>> 3420:         return Long.compare(thisTime, t);
> 
> Probably, in this case `thisTime` variable can also be dropped.

Inlined

> src/java.base/share/classes/java/util/Date.java line 977:
> 
>> 975:         long thisTime = getMillisOf(this);
>> 976:         long anotherTime = getMillisOf(anotherDate);
>> 977:         return Long.compare(thisTime, anotherTime);
> 
> Looks like local variables can also be dropped here as each value is used once.

Inlined

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

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


From prr at openjdk.java.net  Thu Dec  9 17:57:48 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 9 Dec 2021 17:57:48 GMT
Subject: RFR: 8278456: Define jtreg jdk_desktop test group time-based sub-tasks
 for use by headful testing.
Message-ID: <eivjaULEqbaxeLC8CMUryaFWdJvvrIQZVPCfb8yNZ68=.b7c4ba7c-c165-41f9-93c4-4a0ee5e422f2@github.com>

Define part1/part2/part3 for client jtreg tests as done for some other areas
See the bug report for some numbers on the potential benefits of this for faster testing.

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

Commit messages:
 - 8278456: Define jtreg jdk_desktop test group time-based sub-tasks for use by headful testing.

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

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


From serb at openjdk.java.net  Thu Dec  9 18:49:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 9 Dec 2021 18:49:14 GMT
Subject: RFR: 8278456: Define jtreg jdk_desktop test group time-based
 sub-tasks for use by headful testing.
In-Reply-To: <eivjaULEqbaxeLC8CMUryaFWdJvvrIQZVPCfb8yNZ68=.b7c4ba7c-c165-41f9-93c4-4a0ee5e422f2@github.com>
References: <eivjaULEqbaxeLC8CMUryaFWdJvvrIQZVPCfb8yNZ68=.b7c4ba7c-c165-41f9-93c4-4a0ee5e422f2@github.com>
Message-ID: <mtpQaPf_nrpjtFZvGGmC6I6kFV9Nga6mTm3dH6N0Je4=.b5517894-3685-4a93-91c8-a015bc8eaa72@github.com>

On Thu, 9 Dec 2021 17:49:00 GMT, Phil Race <prr at openjdk.org> wrote:

> Define part1/part2/part3 for client jtreg tests as done for some other areas
> See the bug report for some numbers on the potential benefits of this for faster testing.

Marked as reviewed by serb (Reviewer).

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

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


From aivanov at openjdk.java.net  Thu Dec  9 20:06:15 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Dec 2021 20:06:15 GMT
Subject: RFR: 8278456: Define jtreg jdk_desktop test group time-based
 sub-tasks for use by headful testing.
In-Reply-To: <eivjaULEqbaxeLC8CMUryaFWdJvvrIQZVPCfb8yNZ68=.b7c4ba7c-c165-41f9-93c4-4a0ee5e422f2@github.com>
References: <eivjaULEqbaxeLC8CMUryaFWdJvvrIQZVPCfb8yNZ68=.b7c4ba7c-c165-41f9-93c4-4a0ee5e422f2@github.com>
Message-ID: <p0jc9PORDl1545sc0fl_s2GKmKObcY_z8uzrrc3yopo=.9cee458c-068a-4d49-87bf-7368e0a53619@github.com>

On Thu, 9 Dec 2021 17:49:00 GMT, Phil Race <prr at openjdk.org> wrote:

> Define part1/part2/part3 for client jtreg tests as done for some other areas
> See the bug report for some numbers on the potential benefits of this for faster testing.

Marked as reviewed by aivanov (Reviewer).

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

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


From serb at openjdk.java.net  Thu Dec  9 22:53:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 9 Dec 2021 22:53:41 GMT
Subject: RFR: 8276819:
 javax/print/PrintServiceLookup/FlushCustomClassLoader.java fails to free
Message-ID: <G_gJrbch54Wejf9prEORoM9vl5ytQ1Z2dHi3KcZqjjE=.caa70a04-4540-40fa-bf41-15086170cf4e@github.com>

This is an attempt to make the FlushCustomClassLoader more stable. I cannot reproduce this bug so added some improvement blindly, based on assumption that the test may fail on the slow/overloaded system.

 * The attempt limitation was removed, but the test execution time decreased to 1 minute
 * For each attempt the generation of OOM was added to make sure that the GC was triggered

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

Commit messages:
 - Update FlushCustomClassLoader.java

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

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


From serb at openjdk.java.net  Fri Dec 10 00:57:17 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 10 Dec 2021 00:57:17 GMT
Subject: RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v4]
In-Reply-To: <4-SKWxMIwTELnjjaNtCMiLopBp2n1-vpCPnEl4Gst6s=.e04c81b2-d0ed-4366-9b5b-f3eac4a660a5@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
 <4-SKWxMIwTELnjjaNtCMiLopBp2n1-vpCPnEl4Gst6s=.e04c81b2-d0ed-4366-9b5b-f3eac4a660a5@github.com>
Message-ID: <fXbwLrE2CuWWr93ompLDx5VakFv-l9emVh-7ISDZowU=.9f5cfd64-7f5e-45bf-886b-7f0a1a24a858@github.com>

On Tue, 23 Nov 2021 20:52:40 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> 8274893: Update java.desktop classes to use try-with-resources
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274893: Update java.desktop classes to use try-with-resources
>   close nested streams too to unify code

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Fri Dec 10 03:18:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 10 Dec 2021 03:18:37 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the
 java.util.logging [v2]
In-Reply-To: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
Message-ID: <oMxSMgfs2sbqnG2_YD9cgbzxAqLrq9qC0QFF6ZlYZBc=.88298f7c-52c3-40ed-8b35-51b5f60f10c1@github.com>

> At the time Java supported applets and webstart, a special mechanism for launching various applications in one JVM was used to reduce memory usage and each application was isolated from each other.
> 
> This isolation was implemented via ThreadGroups where each application created its own thread group and all data for the application was stored in the context of its own group.
> 
> Some parts of the JDK used ThreadGroups directly, others used special classes like sun.awt.AppContext.
> 
> Such sandboxing became useless since the plugin and webstart are no longer supported and were removed in jdk11.
> 
> Note that this is just a first step for the overall cleanup, here is my plan:
> 1. Cleanup the usage of AppContext in the ?java.util.logging.LogManager" class in the java.base module.
> 2. Cleanup the usage of TheadGroup in the JavaSound
> 3. Cleanup the usage of TheadGroup in the JavaBeans
> 4. Cleanup the usage of AppContext in the Swing
> 5. Cleanup the usage of AppContext in the AWT
> 6. Delete the AppContext class.
> 
> The current PR is for the first step. So this is the request to delete the usage of AppContext in the LogManager and related tests.
> 
> Tested by tier1/tier2/tier3 and jdk_desktop tests.

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

 - Merge branch 'master' into JDK-8273101
 - Some tests deleted
 - Update the RootLevelInConfigFile test
 - Initial version of JDK-8273101

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

Changes: https://git.openjdk.java.net/jdk/pull/5326/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5326&range=01
  Stats: 1423 lines in 10 files changed: 0 ins; 1418 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5326/head:pull/5326

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


From psadhukhan at openjdk.java.net  Fri Dec 10 04:24:14 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Dec 2021 04:24:14 GMT
Subject: RFR: 8278456: Define jtreg jdk_desktop test group time-based
 sub-tasks for use by headful testing.
In-Reply-To: <eivjaULEqbaxeLC8CMUryaFWdJvvrIQZVPCfb8yNZ68=.b7c4ba7c-c165-41f9-93c4-4a0ee5e422f2@github.com>
References: <eivjaULEqbaxeLC8CMUryaFWdJvvrIQZVPCfb8yNZ68=.b7c4ba7c-c165-41f9-93c4-4a0ee5e422f2@github.com>
Message-ID: <OOIMGifipVA9uMHIblF_6Zy4Bwd8aZUAMuFKobyoIUY=.320afa14-aa5a-42f6-9be0-d3f02a9a0df7@github.com>

On Thu, 9 Dec 2021 17:49:00 GMT, Phil Race <prr at openjdk.org> wrote:

> Define part1/part2/part3 for client jtreg tests as done for some other areas
> See the bug report for some numbers on the potential benefits of this for faster testing.

test/jdk/TEST.groups line 414:

> 412:     java/awt/Modal \
> 413:     java/awt/datatransfer \
> 414:     java/awt/Window

I am not sure I understand why we need to run java/awt/Component, java/awt/Modal, java/awt/datatransfer, java/awt/Window in part_2 and part_3...Will it not be duplication of run of tests (as jdk_desktop is supposed to run all part1,2,3)?

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

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


From prr at openjdk.java.net  Fri Dec 10 04:45:15 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 10 Dec 2021 04:45:15 GMT
Subject: RFR: 8278456: Define jtreg jdk_desktop test group time-based
 sub-tasks for use by headful testing.
In-Reply-To: <OOIMGifipVA9uMHIblF_6Zy4Bwd8aZUAMuFKobyoIUY=.320afa14-aa5a-42f6-9be0-d3f02a9a0df7@github.com>
References: <eivjaULEqbaxeLC8CMUryaFWdJvvrIQZVPCfb8yNZ68=.b7c4ba7c-c165-41f9-93c4-4a0ee5e422f2@github.com>
 <OOIMGifipVA9uMHIblF_6Zy4Bwd8aZUAMuFKobyoIUY=.320afa14-aa5a-42f6-9be0-d3f02a9a0df7@github.com>
Message-ID: <3thjwv495pxm1nAb_C4wVmN1BkT4AhYAdaBsV0nNHa4=.7ed9b0f2-4e55-4af8-a109-7d5d7a0a4e50@github.com>

On Fri, 10 Dec 2021 04:20:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Define part1/part2/part3 for client jtreg tests as done for some other areas
>> See the bug report for some numbers on the potential benefits of this for faster testing.
>
> test/jdk/TEST.groups line 414:
> 
>> 412:     java/awt/Modal \
>> 413:     java/awt/datatransfer \
>> 414:     java/awt/Window
> 
> I am not sure I understand why we need to run java/awt/Component, java/awt/Modal, java/awt/datatransfer, java/awt/Window in part_2 and part_3...Will it not be duplication of run of tests (as jdk_desktop is supposed to run all part1,2,3)?

We aren't. the "-" means it is excluded.

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

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


From psadhukhan at openjdk.java.net  Fri Dec 10 04:53:14 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Dec 2021 04:53:14 GMT
Subject: RFR: 8278456: Define jtreg jdk_desktop test group time-based
 sub-tasks for use by headful testing.
In-Reply-To: <eivjaULEqbaxeLC8CMUryaFWdJvvrIQZVPCfb8yNZ68=.b7c4ba7c-c165-41f9-93c4-4a0ee5e422f2@github.com>
References: <eivjaULEqbaxeLC8CMUryaFWdJvvrIQZVPCfb8yNZ68=.b7c4ba7c-c165-41f9-93c4-4a0ee5e422f2@github.com>
Message-ID: <w2fFg48dUPsLYMs9jPzlZJyVp4L5oo7E4Fbx1dMBiO8=.9fa3dc0b-4d35-4fe9-a734-4ec6db18bb68@github.com>

On Thu, 9 Dec 2021 17:49:00 GMT, Phil Race <prr at openjdk.org> wrote:

> Define part1/part2/part3 for client jtreg tests as done for some other areas
> See the bug report for some numbers on the potential benefits of this for faster testing.

Marked as reviewed by psadhukhan (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Fri Dec 10 04:53:16 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Dec 2021 04:53:16 GMT
Subject: RFR: 8278456: Define jtreg jdk_desktop test group time-based
 sub-tasks for use by headful testing.
In-Reply-To: <3thjwv495pxm1nAb_C4wVmN1BkT4AhYAdaBsV0nNHa4=.7ed9b0f2-4e55-4af8-a109-7d5d7a0a4e50@github.com>
References: <eivjaULEqbaxeLC8CMUryaFWdJvvrIQZVPCfb8yNZ68=.b7c4ba7c-c165-41f9-93c4-4a0ee5e422f2@github.com>
 <OOIMGifipVA9uMHIblF_6Zy4Bwd8aZUAMuFKobyoIUY=.320afa14-aa5a-42f6-9be0-d3f02a9a0df7@github.com>
 <3thjwv495pxm1nAb_C4wVmN1BkT4AhYAdaBsV0nNHa4=.7ed9b0f2-4e55-4af8-a109-7d5d7a0a4e50@github.com>
Message-ID: <LAQDxBjS3XxAf0NQFUpHxNIrbRCRjE-_wsT3gvm0BzU=.28ff986f-a851-4794-a72e-8d189eeea327@github.com>

On Fri, 10 Dec 2021 04:42:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/TEST.groups line 414:
>> 
>>> 412:     java/awt/Modal \
>>> 413:     java/awt/datatransfer \
>>> 414:     java/awt/Window
>> 
>> I am not sure I understand why we need to run java/awt/Component, java/awt/Modal, java/awt/datatransfer, java/awt/Window in part_2 and part_3...Will it not be duplication of run of tests (as jdk_desktop is supposed to run all part1,2,3)?
>
> We aren't. the "-" means it is excluded.

ok...Thanks for the clarification..
Probably we could do the same for javax/swing instead of running in its entirety..

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

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


From duke at openjdk.java.net  Fri Dec 10 07:55:15 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 10 Dec 2021 07:55:15 GMT
Subject: Withdrawn: 8275165 : ProblemList InterpolationQualityTest.java
In-Reply-To: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>
References: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>
Message-ID: <aWkf_cFk7108dZyD89wKoS3c0ZHXcDcZHdzx29U1TKc=.087576b1-fe89-479a-9710-6f02e0b74441@github.com>

On Wed, 13 Oct 2021 17:02:03 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> InterpolationQualityTest.java test fails consistently on windows 10 hence adding it in the problemList.
> 
> @shurymury

This pull request has been closed without being integrated.

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

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


From myano at openjdk.java.net  Fri Dec 10 09:08:43 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 10 Dec 2021 09:08:43 GMT
Subject: RFR: 8277463: JFileChooser with Metal L&F doesn't show non-canonical
 UNC path in - Look in
Message-ID: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>

I would like to fix the bug reported in JDK-8277463.

As reporter's investigation, ShellFolder.getNormalizedFile() returns incorrect value for non-canonical Windows UNC path. getNormalizedFile() is used for symbolic link path, but Windows environment does not handle symbolic link. And, getCanonicalFile() returns correct path for a directory link in Windows which is made with `mklink` command. So getNormalizedFile() should perform to return getCanonicalFile() like WindowsFileChooserUI.addItem() at Windows environment.

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

Commit messages:
 - 8277463: JFileChooser with Metal L&F doesn't show non-canonical UNC path in - Look in

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

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


From psadhukhan at openjdk.java.net  Fri Dec 10 10:11:12 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Dec 2021 10:11:12 GMT
Subject: RFR: 8277463: JFileChooser with Metal L&F doesn't show
 non-canonical UNC path in - Look in
In-Reply-To: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
References: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
Message-ID: <RfkEC5jFuLbyeNKautaXwezn5Pf6gwV7zeNaoSiS5m8=.59930757-612d-4f82-82c6-3b11551dc691@github.com>

On Fri, 10 Dec 2021 08:59:55 GMT, Masanori Yano <myano at openjdk.org> wrote:

> I would like to fix the bug reported in JDK-8277463.
> 
> As reporter's investigation, ShellFolder.getNormalizedFile() returns incorrect value for non-canonical Windows UNC path. getNormalizedFile() is used for symbolic link path, but Windows environment does not handle symbolic link. And, getCanonicalFile() returns correct path for a directory link in Windows which is made with `mklink` command. So getNormalizedFile() should perform to return getCanonicalFile() like WindowsFileChooserUI.addItem() at Windows environment.

I am not able to reproduce the issue even without the fix. How did you reproduce?
I tried "\\\< mypcname>\dir.." and I could see "Documents" folder in "Look In" combobox of filechooser..It supposed to be empty for bug to be reproduced..
If  I put in \\\< mypcname> in Windows Run prompt, I get no folder btw so no "dir" is present in my \\\< mypcname> folder actually and it does not allow me to create one in that \\\< mypcname> folder

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

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


From psadhukhan at openjdk.java.net  Fri Dec 10 10:11:15 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Dec 2021 10:11:15 GMT
Subject: RFR: 8276819:
 javax/print/PrintServiceLookup/FlushCustomClassLoader.java fails to free
In-Reply-To: <G_gJrbch54Wejf9prEORoM9vl5ytQ1Z2dHi3KcZqjjE=.caa70a04-4540-40fa-bf41-15086170cf4e@github.com>
References: <G_gJrbch54Wejf9prEORoM9vl5ytQ1Z2dHi3KcZqjjE=.caa70a04-4540-40fa-bf41-15086170cf4e@github.com>
Message-ID: <pLeYTpJ4ItkUS4i3Mi1pYxuthzRBYv5Z4TztMsGC_30=.e5fc5ee8-8f2b-4202-9ab2-87fdb75c7a4f@github.com>

On Thu, 9 Dec 2021 02:47:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is an attempt to make the FlushCustomClassLoader more stable. I cannot reproduce this bug so added some improvement blindly, based on assumption that the test may fail on the slow/overloaded system.
> 
>  * The attempt limitation was removed, but the test execution time decreased to 1 minute
>  * For each attempt the generation of OOM was added to make sure that the GC was triggered

Marked as reviewed by psadhukhan (Reviewer).

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

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


From aivanov at openjdk.java.net  Fri Dec 10 13:57:14 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Dec 2021 13:57:14 GMT
Subject: RFR: 8276819:
 javax/print/PrintServiceLookup/FlushCustomClassLoader.java fails to free
In-Reply-To: <G_gJrbch54Wejf9prEORoM9vl5ytQ1Z2dHi3KcZqjjE=.caa70a04-4540-40fa-bf41-15086170cf4e@github.com>
References: <G_gJrbch54Wejf9prEORoM9vl5ytQ1Z2dHi3KcZqjjE=.caa70a04-4540-40fa-bf41-15086170cf4e@github.com>
Message-ID: <DZnqD-TyTATtCsYjtgsQLCUJ34KMPeDQLIoCzMAF6IE=.6f056c36-5401-42c9-840b-06e0557464e5@github.com>

On Thu, 9 Dec 2021 02:47:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is an attempt to make the FlushCustomClassLoader more stable. I cannot reproduce this bug so added some improvement blindly, based on assumption that the test may fail on the slow/overloaded system.
> 
>  * The attempt limitation was removed, but the test execution time decreased to 1 minute
>  * For each attempt the generation of OOM was added to make sure that the GC was triggered

Marked as reviewed by aivanov (Reviewer).

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

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


From kcr at openjdk.java.net  Fri Dec 10 15:41:16 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 10 Dec 2021 15:41:16 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v6]
In-Reply-To: <KakmTnnPwFyrOnjH7Dzh-dxokgMP8zpgWHN4nJ9az-c=.e74d8f2d-0ce0-42fd-87ae-55e08366aead@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <KakmTnnPwFyrOnjH7Dzh-dxokgMP8zpgWHN4nJ9az-c=.e74d8f2d-0ce0-42fd-87ae-55e08366aead@github.com>
Message-ID: <fBdO0l1upKuvUSMb2BCLFECGUkzuoXFb0sgAZH5_H5w=.aec36a2c-d32e-4248-9316-b58dbf2d8f32@github.com>

On Tue, 7 Dec 2021 05:03:27 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Add uninstallColorsAndFont
>  - 8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy

This adds public methods, which will need discussion on the client-libs mailing list, and requires a CSR.

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

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


From kcr at openjdk.java.net  Fri Dec 10 15:44:17 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 10 Dec 2021 15:44:17 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v3]
In-Reply-To: <s2cyjzPB8N_dtZ_jE6kvH0FCqvKHV4HAy8cyISg67MU=.be97b3d2-d0b4-4aa4-bc3f-61a14f8bc8ea@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <y_5NNZh13M0aOunbDfLa4uwDfBR9DdTol_uTPtYYauM=.e2a4bb86-977c-46db-bc75-a3520239847f@github.com>
 <mCfIHr_52amMFWR8y6GRc3Fi4uoE7YU_xBUxYSgxgCo=.8c7029b9-5b24-4057-bbd0-36c15ee341aa@github.com>
 <_vz3JjOjXjatc2N63LFHgHSzMz2e8i26nbjEQ6FAVyo=.abef7fb9-34fa-49b7-86d1-b3f4a5fb21b2@github.com>
 <mrxWcG3UfSrqErLvbFO9Xc-Re5iG-YzQFqSX43l0DMc=.1aba1cef-c56a-489b-aa9f-164ece79a614@github.com>
 <q2Zn9vSy900JJ3BrNB9WwjHI47iIZtsikHniLIB25og=.28a6ae10-2367-4f94-878d-5ca9812a8c0d@github.com>
 <s2cyjzPB8N_dtZ_jE6kvH0FCqvKHV4HAy8cyISg67MU=.be97b3d2-d0b4-4aa4-bc3f-61a14f8bc8ea@github.com>
Message-ID: <gZFlzkMFIFtu6vsCFyEZp4CvxENS-BQUOfzXwEOSMjA=.32b58297-dff7-4791-9ced-729caa6ac8a2@github.com>

On Thu, 2 Dec 2021 06:23:28 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>>> I'm not sure I understand, aren't these being installed in `BasicPanelUI`?
>> 
>> If it is installs in the BasicListUI only then yes the fix belongs to this class. These properties changing also in some other classes as well, but some other classes cleanup it properly for example see BasicListUI.uninstallDefaults(), but I am not sure that all of them do this.
>
>> These properties changing also in some other classes as well, but some other classes cleanup it properly for example see BasicListUI.uninstallDefaults(), but I am not sure that all of them do this.
> 
> I looked through other uses of `installColorsAndFont`, and most of them don't seem to be uninstalling the properties. I updated the ones I found, and added a `uninstallColorsAndFont` method to avoid copying the logic around.

@cushon As a best practice, please do not force push to a branch for which there is an PR under review. Instead, you can merge the master branch into your branch if you need to update.

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

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


From cushon at openjdk.java.net  Fri Dec 10 16:33:15 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Fri, 10 Dec 2021 16:33:15 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v6]
In-Reply-To: <KakmTnnPwFyrOnjH7Dzh-dxokgMP8zpgWHN4nJ9az-c=.e74d8f2d-0ce0-42fd-87ae-55e08366aead@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <KakmTnnPwFyrOnjH7Dzh-dxokgMP8zpgWHN4nJ9az-c=.e74d8f2d-0ce0-42fd-87ae-55e08366aead@github.com>
Message-ID: <8UMnNv-iJ3Jmsd9wEAK-znj7AbBvtBk8fVe4Uof819Q=.b0e09cb7-1e05-44cb-9938-b988957dab69@github.com>

On Tue, 7 Dec 2021 05:03:27 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Add uninstallColorsAndFont
>  - 8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy

I started a thread on client-libs-dev and filed a CSR: https://bugs.openjdk.java.net/browse/JDK-8278555

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

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


From aivanov at openjdk.java.net  Fri Dec 10 16:33:18 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Dec 2021 16:33:18 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v6]
In-Reply-To: <KakmTnnPwFyrOnjH7Dzh-dxokgMP8zpgWHN4nJ9az-c=.e74d8f2d-0ce0-42fd-87ae-55e08366aead@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <KakmTnnPwFyrOnjH7Dzh-dxokgMP8zpgWHN4nJ9az-c=.e74d8f2d-0ce0-42fd-87ae-55e08366aead@github.com>
Message-ID: <dBY2Kivimssp42nEHfeMjguo5_1VC_Is63hzx9wkPrk=.ce9ecb6a-e1a3-4138-87fc-4472cd694eee@github.com>

On Tue, 7 Dec 2021 05:03:27 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Add uninstallColorsAndFont
>  - 8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy

src/java.desktop/share/classes/javax/swing/LookAndFeel.java line 199:

> 197:      * @throws NullPointerException if {@code c} is {@code null}
> 198:      */
> 199:     public static void uninstallColors(JComponent c) {

It's a new method, `@since 19` should be added.

src/java.desktop/share/classes/javax/swing/LookAndFeel.java line 247:

> 245:      * @throws NullPointerException if {@code c} is {@code null}
> 246:      */
> 247:     public static void uninstallColorsAndFont(JComponent c) {

Should also have `@since 19`.

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

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


From cushon at openjdk.java.net  Fri Dec 10 16:40:52 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Fri, 10 Dec 2021 16:40:52 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v7]
In-Reply-To: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
Message-ID: <opb6fLuJaSl_yVThwM9nuax1_Ta4GwgZR8LdU9tTfZQ=.21307c78-27c4-45cb-a564-21e67a94db3a@github.com>

> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Add @since 19 to new methods

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6603/files
  - new: https://git.openjdk.java.net/jdk/pull/6603/files/02ae7fba..10b53ea2

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

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

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


From cushon at openjdk.java.net  Fri Dec 10 16:40:57 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Fri, 10 Dec 2021 16:40:57 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v6]
In-Reply-To: <dBY2Kivimssp42nEHfeMjguo5_1VC_Is63hzx9wkPrk=.ce9ecb6a-e1a3-4138-87fc-4472cd694eee@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <KakmTnnPwFyrOnjH7Dzh-dxokgMP8zpgWHN4nJ9az-c=.e74d8f2d-0ce0-42fd-87ae-55e08366aead@github.com>
 <dBY2Kivimssp42nEHfeMjguo5_1VC_Is63hzx9wkPrk=.ce9ecb6a-e1a3-4138-87fc-4472cd694eee@github.com>
Message-ID: <TjCyq6r9JP-tsUhiMPB7hP49m97xY9bBHN06vcBu3qM=.d3bb97f3-2635-4219-b036-736e69fe3124@github.com>

On Fri, 10 Dec 2021 16:09:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Add uninstallColorsAndFont
>>  - 8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy
>
> src/java.desktop/share/classes/javax/swing/LookAndFeel.java line 199:
> 
>> 197:      * @throws NullPointerException if {@code c} is {@code null}
>> 198:      */
>> 199:     public static void uninstallColors(JComponent c) {
> 
> It's a new method, `@since 19` should be added.

Done, thanks

> src/java.desktop/share/classes/javax/swing/LookAndFeel.java line 247:
> 
>> 245:      * @throws NullPointerException if {@code c} is {@code null}
>> 246:      */
>> 247:     public static void uninstallColorsAndFont(JComponent c) {
> 
> Should also have `@since 19`.

Done

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

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


From aivanov at openjdk.java.net  Fri Dec 10 16:45:17 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Dec 2021 16:45:17 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v7]
In-Reply-To: <opb6fLuJaSl_yVThwM9nuax1_Ta4GwgZR8LdU9tTfZQ=.21307c78-27c4-45cb-a564-21e67a94db3a@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <opb6fLuJaSl_yVThwM9nuax1_Ta4GwgZR8LdU9tTfZQ=.21307c78-27c4-45cb-a564-21e67a94db3a@github.com>
Message-ID: <yoWg4dM4OxtWDTX07qXWOuo7X4HnRuR8S-r4lD3W0aI=.0faf7c56-3e25-41b9-b123-4745970ea047@github.com>

On Fri, 10 Dec 2021 16:40:52 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @since 19 to new methods

@mrserb mentioned `BasicListUI.uninstallDefaults` uninstalls the colors correctly. However, with the new methods added, it could use `LookAndFeel.uninstallColorsAndFont` to reset its font, foreground and background.

Probably other UI classes should be updated too.

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

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


From cushon at openjdk.java.net  Fri Dec 10 16:54:44 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Fri, 10 Dec 2021 16:54:44 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v8]
In-Reply-To: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
Message-ID: <dQgRu8kiuHaIRqiFxTRalE0O7bHKVrnKg2fbBAKtxws=.aef2ed5f-b4a5-467b-a1e9-94c15ca4edd0@github.com>

> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Use LookAndFeel.uninstallColorsAndFont in BasicListUI

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6603/files
  - new: https://git.openjdk.java.net/jdk/pull/6603/files/10b53ea2..48a02633

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

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

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


From cushon at openjdk.java.net  Fri Dec 10 17:03:49 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Fri, 10 Dec 2021 17:03:49 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v9]
In-Reply-To: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
Message-ID: <49gYRPX_QAzZcEsFovkzHbBn2I28lXo-3fYDHmYSUD0=.cf6525da-c24b-406f-ad90-2eabcbd840c3@github.com>

> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Add a few more missing calls to LookAndFeel.uninstallColors

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6603/files
  - new: https://git.openjdk.java.net/jdk/pull/6603/files/48a02633..7e3b3a19

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

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

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


From cushon at openjdk.java.net  Fri Dec 10 17:03:51 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Fri, 10 Dec 2021 17:03:51 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v7]
In-Reply-To: <yoWg4dM4OxtWDTX07qXWOuo7X4HnRuR8S-r4lD3W0aI=.0faf7c56-3e25-41b9-b123-4745970ea047@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <opb6fLuJaSl_yVThwM9nuax1_Ta4GwgZR8LdU9tTfZQ=.21307c78-27c4-45cb-a564-21e67a94db3a@github.com>
 <yoWg4dM4OxtWDTX07qXWOuo7X4HnRuR8S-r4lD3W0aI=.0faf7c56-3e25-41b9-b123-4745970ea047@github.com>
Message-ID: <YvN8PUorJCxFP2p7sNjugPejgvWnF9IYPjS_p0LiPqU=.f310c545-78bf-4cad-b171-a144181ac333@github.com>

On Fri, 10 Dec 2021 16:41:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @since 19 to new methods
>
> @mrserb mentioned `BasicListUI.uninstallDefaults` uninstalls the colors correctly. However, with the new methods added, it could use `LookAndFeel.uninstallColorsAndFont` to reset its font, foreground and background.
> 
> Probably other UI classes should be updated too.

@aivanov-jdk thanks, I updated `BasicListUI`.

I found a few other cases with  the following, which I have fixed:


$ find src/java.desktop/share/ -type f -name '*.java' | xargs grep -l LookAndFeel.installColors | xargs grep -L LookAndFeel.uninstallColors


The remaining files that call `LookAndFeel.installColors*` with a corresponding `uninstall*` call are below.

This reference in javadoc seems fine:
 https://github.com/openjdk/jdk/blob/8eb453baebe377697286f7eb32280ca9f1fd7775/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java#L116
 
This may be suspicious, but it isn't in an `install` method:

https://github.com/openjdk/jdk/blob/8eb453baebe377697286f7eb32280ca9f1fd7775/src/java.desktop/share/classes/sun/swing/FilePane.java#L1295

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

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


From vdyakov at openjdk.java.net  Fri Dec 10 17:28:16 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Fri, 10 Dec 2021 17:28:16 GMT
Subject: RFR: 8275843: Random crashes while the UI code is executed
In-Reply-To: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
References: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
Message-ID: <ufJ4TMVsSfnHXoZCkx9chcPWq5KQ6zk00bCDpR4bM24=.9a4f803e-a3d7-4059-8e86-682b3fc522c9@github.com>

On Mon, 1 Nov 2021 20:03:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please take a look to one more wagon in this train:
> [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795)->[JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931)->[JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579)->[JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392)->[Current issue](https://bugs.openjdk.java.net/browse/JDK-8275843). 
> 
> #### The short description:
> 
> We have an inconsistent between xrender java code and the x11 window. The java code thinks that all our windows support only two types of color models: IntRgbX11 and IntArgbPreX11, but the x11 window supports more types. If such inconsistency occurs we render some garbage, or just crash since our "blits" will assume the wrong data layout. This issue was reported and fixed [before](http://hg.openjdk.java.net/jdk/jdk/rev/c53905e7dc57) but it was not realized why the rendering was wrong and that it can cause a crash. The fix is similar to the old one.
> 
> #### The long description:
> 
>  * Once upon a time this bug was filed [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) it was about the rendering of colors to the volatile image, the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8176795?focusedCommentId=14138323&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14138323) In short: the volatile images in the xrender use intArgbPre color model, it means that the SunGraphics2D object [convert](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1753) the argb value to the argbPre before passing it to the pipeline, and the xrender pipeline [convert](http://hg.openjdk.java.net/jdk/jdk/rev/e4b03365ddbf) this value to the argbPre one more time -> double-conversion-> the bug is reproduced. The fix for that bug disabled the second conversion in the xrender. but it does not take into account that this code path is u
 sed for rendering to the ARGB X11 window where the shared code does not convert the color, so the next bug was filed.
>  * The second bug is [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931), the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8204931?focusedCommentId=14199800&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14199800). In short the bug was about rendering directly to the window and missing color conversion removed previously. The fix for that bug changed the surface type used by the window, so the shared code start to convert the color from ARGB to argbPre, but it does not take into account that we do not control the color model of the window, see how many of them we actually [support](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceData.java#L501) Also note in the link above that if we do not recognize the type we do not fallback to something but throw InvalidPipeException, this is because the blits(and other primitives) may use t
 his type to access the data directly. So the next bug was reported:
>  * This is the third issue [JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579). The fix for that issue tried to roll back the previous one but does not take into account that the conversion removed by the first issue should be rollback as well, so the last bug was filed.
>  * The "last" issue is [JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392) rollback the previous one. So the bug reported in the third report come back.
> 
> #### Fix description
> 
> The fix for the current issue contains a few parts:
>  * Rollback of the [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931) so we will use the proper surface data for the window.
>  * Return conversion in the xrender pipeline removed by the [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) So we will convert it when we render to the volatile image(argbPre) and to the window(argb). We need to convert in both cases since the xrender API which we use expects the argbPre colors.
>  * Start to use the [eargb](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1752) value( instead of pixel) stored in the SunGraphics2D so we did not get the double conversion.
> 
> Some tests are updated and one more is added.
> 
> ### Note
> I have checked the performance implication of this change and it looks like after this change the sequence window.setvisible(true)/window.dispose() will work 30% faster, this may affect the tests which does not wait enough time to make the window visible. Probably this is the reason why some of our tests became more stable at some point in jdk11.
> 
> 
> I have tested this by the jck and jdk_desktop tests. But any additional verification/testing is welcome.

@azvegint  please review

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

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


From aivanov at openjdk.java.net  Fri Dec 10 17:31:13 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Dec 2021 17:31:13 GMT
Subject: RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits [v5]
In-Reply-To: <Q8agIAsSvZX60WluLZzsAIdzM06a0rrc_xTNFyMLSNo=.e94823c2-f8d5-45c3-a689-1c2856495ffc@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
 <Q8agIAsSvZX60WluLZzsAIdzM06a0rrc_xTNFyMLSNo=.e94823c2-f8d5-45c3-a689-1c2856495ffc@github.com>
Message-ID: <N6rqLC2G8FpoHFyeri3QvGo0zP01bFMzOhB3yr-6Hrk=.dd893a7a-573a-4953-b6e4-2f659c61b176@github.com>

On Tue, 7 Dec 2021 19:52:50 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Made colorBits and maskBits arrays dynamic so they are allocated on heap instead of stack.
>> Added regression test.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat the code getting rid of the sectnd try block

I admit I prefer the 2nd version with two try-catch blocks better because it avoids using if's completely.

Anyway, this version looks good to me. Thanks.

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1083:

> 1081:                     maskBits = (long*)safe_Malloc(MAX_ICON_SIZE * MAX_ICON_SIZE * sizeof(long));
> 1082: 
> 1083:                     GetDIBits(dc, iconInfo.hbmMask, 0, iconSize, maskBits, &bmi, DIB_RGB_COLORS);

Probably the empty lines here aren't necessary.

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

Marked as reviewed by aivanov (Reviewer).

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


From kizune at openjdk.java.net  Fri Dec 10 19:49:47 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 10 Dec 2021 19:49:47 GMT
Subject: [jdk18] RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits
Message-ID: <isNgOZiBXcHdw3tH-HGxM5taFzBk8ysHYabEF8eqqvU=.882a3104-eb5d-4281-8c0b-24e1ca67031f@github.com>

Made colorBits and maskBits arraus dynamic so they allocated on heap instead of stack.
Added regression test.

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

Commit messages:
 - A8277299: STACK_OVERFLOW in Java_sun_awt_shell_Win32ShellFolder2_getIconBits

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

PR: https://git.openjdk.java.net/jdk18/pull/12


From kizune at openjdk.java.net  Fri Dec 10 19:49:47 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 10 Dec 2021 19:49:47 GMT
Subject: [jdk18] RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits
In-Reply-To: <isNgOZiBXcHdw3tH-HGxM5taFzBk8ysHYabEF8eqqvU=.882a3104-eb5d-4281-8c0b-24e1ca67031f@github.com>
References: <isNgOZiBXcHdw3tH-HGxM5taFzBk8ysHYabEF8eqqvU=.882a3104-eb5d-4281-8c0b-24e1ca67031f@github.com>
Message-ID: <KIY4n-yOssKF6AsPdgNl_33DaJU4fw0OVGcEa8cGcZM=.ad3476ab-632c-488f-89b2-b35e5e7ecf57@github.com>

On Fri, 10 Dec 2021 19:43:26 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Made colorBits and maskBits arraus dynamic so they allocated on heap instead of stack.
> Added regression test.

@aivanov-jdk please review, this is the same fix as was reviewed on the mainline but with extra spaces removed.

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

PR: https://git.openjdk.java.net/jdk18/pull/12


From aivanov at openjdk.java.net  Fri Dec 10 20:23:13 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Dec 2021 20:23:13 GMT
Subject: [jdk18] RFR: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits
In-Reply-To: <isNgOZiBXcHdw3tH-HGxM5taFzBk8ysHYabEF8eqqvU=.882a3104-eb5d-4281-8c0b-24e1ca67031f@github.com>
References: <isNgOZiBXcHdw3tH-HGxM5taFzBk8ysHYabEF8eqqvU=.882a3104-eb5d-4281-8c0b-24e1ca67031f@github.com>
Message-ID: <adKeqKQoB5AMUW6zlZQwBs0yesHQrh2wpAwAosWgzaY=.148c378c-1b45-4251-80cf-77350ae87e15@github.com>

On Fri, 10 Dec 2021 19:43:26 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Made colorBits and maskBits arraus dynamic so they allocated on heap instead of stack.
> Added regression test.

Marked as reviewed by aivanov (Reviewer).

This review continues from the [mainline one](https://github.com/openjdk/jdk/pull/6473).

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

PR: https://git.openjdk.java.net/jdk18/pull/12


From kizune at openjdk.java.net  Fri Dec 10 20:30:18 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 10 Dec 2021 20:30:18 GMT
Subject: [jdk18] Integrated: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits
In-Reply-To: <isNgOZiBXcHdw3tH-HGxM5taFzBk8ysHYabEF8eqqvU=.882a3104-eb5d-4281-8c0b-24e1ca67031f@github.com>
References: <isNgOZiBXcHdw3tH-HGxM5taFzBk8ysHYabEF8eqqvU=.882a3104-eb5d-4281-8c0b-24e1ca67031f@github.com>
Message-ID: <sk00F_sKrD-xlN2Aw18Hbe3suecfaRu_f3d0GAvWsE4=.c2244c34-adf5-4d2d-8f4d-5109743a035e@github.com>

On Fri, 10 Dec 2021 19:43:26 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Made colorBits and maskBits arraus dynamic so they allocated on heap instead of stack.
> Added regression test.

This pull request has now been integrated.

Changeset: 94127f43
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/94127f43a4a28a89094fa93cd1da49763134f9db
Stats:     83 lines in 2 files changed: 58 ins; 0 del; 25 mod

8277299: STACK_OVERFLOW in Java_sun_awt_shell_Win32ShellFolder2_getIconBits

Reviewed-by: aivanov

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

PR: https://git.openjdk.java.net/jdk18/pull/12


From prr at openjdk.java.net  Fri Dec 10 20:58:11 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 10 Dec 2021 20:58:11 GMT
Subject: RFR: 8278456: Define jtreg jdk_desktop test group time-based
 sub-tasks for use by headful testing.
In-Reply-To: <LAQDxBjS3XxAf0NQFUpHxNIrbRCRjE-_wsT3gvm0BzU=.28ff986f-a851-4794-a72e-8d189eeea327@github.com>
References: <eivjaULEqbaxeLC8CMUryaFWdJvvrIQZVPCfb8yNZ68=.b7c4ba7c-c165-41f9-93c4-4a0ee5e422f2@github.com>
 <OOIMGifipVA9uMHIblF_6Zy4Bwd8aZUAMuFKobyoIUY=.320afa14-aa5a-42f6-9be0-d3f02a9a0df7@github.com>
 <3thjwv495pxm1nAb_C4wVmN1BkT4AhYAdaBsV0nNHa4=.7ed9b0f2-4e55-4af8-a109-7d5d7a0a4e50@github.com>
 <LAQDxBjS3XxAf0NQFUpHxNIrbRCRjE-_wsT3gvm0BzU=.28ff986f-a851-4794-a72e-8d189eeea327@github.com>
Message-ID: <NOrYOHVvPYdUxyVCx4ENn825UI1_CZH-y1-A-COTIxA=.40605eca-f8f6-433b-a3d2-3b31c666990e@github.com>

On Fri, 10 Dec 2021 04:46:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> We aren't. the "-" means it is excluded.
>
> ok...Thanks for the clarification..
> Probably we could do the same for javax/swing instead of running in its entirety..

There is no point. The entire jdk_swing group runs in far less time than that.

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

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


From prr at openjdk.java.net  Fri Dec 10 21:07:17 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 10 Dec 2021 21:07:17 GMT
Subject: Integrated: 8278456: Define jtreg jdk_desktop test group time-based
 sub-tasks for use by headful testing.
In-Reply-To: <eivjaULEqbaxeLC8CMUryaFWdJvvrIQZVPCfb8yNZ68=.b7c4ba7c-c165-41f9-93c4-4a0ee5e422f2@github.com>
References: <eivjaULEqbaxeLC8CMUryaFWdJvvrIQZVPCfb8yNZ68=.b7c4ba7c-c165-41f9-93c4-4a0ee5e422f2@github.com>
Message-ID: <aVkaDhv1Aj8OEP017t8DhNmr5tdXQjlC9XnA96kL1GU=.d8a7819c-2e15-4be9-9444-d66244091d0c@github.com>

On Thu, 9 Dec 2021 17:49:00 GMT, Phil Race <prr at openjdk.org> wrote:

> Define part1/part2/part3 for client jtreg tests as done for some other areas
> See the bug report for some numbers on the potential benefits of this for faster testing.

This pull request has now been integrated.

Changeset: 81c56c70
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/81c56c700a47c7f1b7855052de17eb88fac84674
Stats:     23 lines in 1 file changed: 17 ins; 0 del; 6 mod

8278456: Define jtreg jdk_desktop test group time-based sub-tasks for use by headful testing.

Reviewed-by: serb, aivanov, psadhukhan

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

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


From aivanov at openjdk.java.net  Fri Dec 10 21:14:11 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Dec 2021 21:14:11 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v9]
In-Reply-To: <49gYRPX_QAzZcEsFovkzHbBn2I28lXo-3fYDHmYSUD0=.cf6525da-c24b-406f-ad90-2eabcbd840c3@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <49gYRPX_QAzZcEsFovkzHbBn2I28lXo-3fYDHmYSUD0=.cf6525da-c24b-406f-ad90-2eabcbd840c3@github.com>
Message-ID: <42DMSPIok6eoDpX7B8nQG_B60O-s-bOPFUYi1fIH44I=.8afa5359-4611-4ec2-a521-23640faffd3b@github.com>

On Fri, 10 Dec 2021 17:03:49 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a few more missing calls to LookAndFeel.uninstallColors

I've been contemplating about what is being done in this PR? It feels wrong.

> > As of the usefulness of the serializations tests in Swing - it is a good coverage of the cleaning code in the L&fs. Each L&F should clean all its data when the app switch one LF to another, but if old L&F forget to cleanup then the app will get a memory leak.

Swing explicitly warns, ?Serialized objects of this class will not be compatible with future Swing releases.?

Don't break this rule in this test? A component is serialized using one version of the JDK and is deserialized in another version of the JDK and even on another platform.

> This test doesn't switch L&Fs .. if it wasn't for mac defaulting to Aqua they'd all be using Metal.
> 
> So _this is an accidental by-product_, not the goal of the test.

It looks so.

If the L&Fs are expected to clean up when uninstalled, it should be tested thoroughly for all the components and Look-and-Feels. Only this way we can be sure the properties get reset.

While working on this code review, Liam has found and fixed quite a few places where clean-up wasn't done properly.

> And that goal be met by the test writing out the serialized objects and reading them back all at "test time", can't it ?
> 
> Seems to me right now we are stumbling over cases where what is serialized is inappropriate for persistent serialization.

Taking into account the above comments, this test could be simplified to write out the objects and then read them in. No persistent serialization which is _explicitly_ unsupported.


To be clear, I think the proposed change is good on its own: it adds convenience methods to clean up UI properties when a L&F is uninstalled, it adds the clean-up where it was missing. But it doesn't fit into the fix of this test failure. This work should be an enhancement performed under another bugid.

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

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


From prr at openjdk.java.net  Fri Dec 10 21:41:12 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 10 Dec 2021 21:41:12 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v9]
In-Reply-To: <49gYRPX_QAzZcEsFovkzHbBn2I28lXo-3fYDHmYSUD0=.cf6525da-c24b-406f-ad90-2eabcbd840c3@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <49gYRPX_QAzZcEsFovkzHbBn2I28lXo-3fYDHmYSUD0=.cf6525da-c24b-406f-ad90-2eabcbd840c3@github.com>
Message-ID: <WQWqcfxtt7PjuNZUQGhsJ2ngcZRvPIWCH9u-UwmeTi4=.3d217d26-2705-4e6a-b45a-3300b59fff88@github.com>

On Fri, 10 Dec 2021 17:03:49 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a few more missing calls to LookAndFeel.uninstallColors

Whilst there might well be some need to do something to make sure uninstallUI() is doing its job entirely/properly,
I am not sure that I'd want to push such a change as the resolution to this failing test.

Better to start afresh with a new bug with an appropriate synopsis and then write some new tests that verify the UI is uninstalled on all the Swing components as you cycle though available L&Fs per-platform.

And since the problem clearly exists in older versions of JDK (even if not exposed by the recent change in JDK 18),
then how would we resolve it there since clearly the new API can't be backported.

And perhaps new API isn't actually needed ? Are there other options ?

And as I wrote before, the failing test is not 100% valid since Swing's specification says :

"Warning: Serialized objects of this class will not be compatible with future Swing releases.
The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing."

"Same version" could be interpreted as "Swing in JDK N", or "Swing in JDK N on 'specific platform'"
But either way, it isn't valid to check in a serialized form from Swing version N and have *any* expectation that it will run on N+1, which is what this test does.
Yes, it can be argued that this test can/will fail even between platforms on the same version, but (1) I'm questioning whether
even that serialization was intended and (2) the test is not limiting itself to that scenario.

I did not understand the "special JDK" answer as to why this test needs to have a checked in serialized form on disk at all.
If we can't do that, I think we should scrap the test or find a different way to do whatever it intends to verify.
We should not be treating it as a test of uninstalling UI - it is a mere accident that this cropped up.

I see Alexey wrote much the same above ..

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

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


From kizune at openjdk.java.net  Sat Dec 11 08:24:13 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 11 Dec 2021 08:24:13 GMT
Subject: Withdrawn: 8277299: STACK_OVERFLOW in
 Java_sun_awt_shell_Win32ShellFolder2_getIconBits
In-Reply-To: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
References: <yp4rOfWkGlwlLiV-9EhW1zoq9P8-NKYrJQJN8WiHrZw=.96f1247d-3986-44b8-9aba-4823d6f6b44f@github.com>
Message-ID: <EWK1dxvIGkRRMRVH1YIhIvsWsB9l_OG6R1hP7lL3TzY=.c1ccf2ac-a1b1-4c57-8201-73e33a9c6a79@github.com>

On Fri, 19 Nov 2021 06:34:30 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Made colorBits and maskBits arrays dynamic so they are allocated on heap instead of stack.
> Added regression test.

This pull request has been closed without being integrated.

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

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


From dcubed at openjdk.java.net  Sat Dec 11 15:05:30 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:05:30 GMT
Subject: RFR: 8278580: ProblemList javax/swing/JTree/4908142/bug4908142.java on
 macosx-x64
Message-ID: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>

A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

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

Commit messages:
 - 8278580: ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64

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

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


From dfuchs at openjdk.java.net  Sat Dec 11 15:37:13 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Sat, 11 Dec 2021 15:37:13 GMT
Subject: RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
References: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
Message-ID: <wZv9ZXfrMiPtC4yj2-YC2wkNHxEEX0OVq0xDchsEz7k=.d3fa8529-fc06-4616-a847-9e3603644081@github.com>

On Sat, 11 Dec 2021 14:56:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

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


From jdv at openjdk.java.net  Sat Dec 11 15:37:13 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Sat, 11 Dec 2021 15:37:13 GMT
Subject: RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
References: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
Message-ID: <3qxLkgEYe9MNEjw4xPU-EDyHpyKPOZ1JPZIsdSOiuWc=.295c1304-aa07-486b-be25-6c31eaab9452@github.com>

On Sat, 11 Dec 2021 14:56:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

Marked as reviewed by jdv (Reviewer).

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

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


From dcubed at openjdk.java.net  Sat Dec 11 15:37:13 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:37:13 GMT
Subject: RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
References: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
Message-ID: <USCzx-O1Q8SUhN_tKx4lfL_PTrZk4LzYv9UIRB5ybws=.1c6f0b44-91e9-4c73-b607-ddf40b9423f9@github.com>

On Sat, 11 Dec 2021 14:56:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

I just realized that I did this ProblemListing in the wrong repo.

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

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


From dcubed at openjdk.java.net  Sat Dec 11 15:37:13 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:37:13 GMT
Subject: Withdrawn: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
References: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
Message-ID: <LUxeZYju2Q5uzFnvjgtzLsv2RvCJxyZDwRcwek3rLWM=.3deff2f5-94fa-4235-90a5-413e2f6c1a21@github.com>

On Sat, 11 Dec 2021 14:56:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

This pull request has been closed without being integrated.

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

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


From dcubed at openjdk.java.net  Sat Dec 11 15:43:14 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:43:14 GMT
Subject: RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <wZv9ZXfrMiPtC4yj2-YC2wkNHxEEX0OVq0xDchsEz7k=.d3fa8529-fc06-4616-a847-9e3603644081@github.com>
References: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
 <wZv9ZXfrMiPtC4yj2-YC2wkNHxEEX0OVq0xDchsEz7k=.d3fa8529-fc06-4616-a847-9e3603644081@github.com>
Message-ID: <nduDgmQjsXaPt-XMI5TDmq2OfN52MTXksT2WswkDz6M=.912ec782-5ffa-47c9-8606-63a82276bb6c@github.com>

On Sat, 11 Dec 2021 15:29:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.
>
> LGTM

@dfuch and @jayathirthrao - Can you please review this PR instead? Thanks!

https://github.com/openjdk/jdk18/pull/13

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

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


From dcubed at openjdk.java.net  Sat Dec 11 15:52:36 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:52:36 GMT
Subject: [jdk18] RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
Message-ID: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>

A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

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

Commit messages:
 - 8278580: ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64

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

PR: https://git.openjdk.java.net/jdk18/pull/13


From alanb at openjdk.java.net  Sat Dec 11 15:52:37 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 11 Dec 2021 15:52:37 GMT
Subject: [jdk18] RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>
References: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>
Message-ID: <DcQ9BkekVQlE_YR6HmOCrCg-BMtTfYqQECGnUK9HoPw=.3d4babe4-364f-487f-b8f8-2504e92cdd32@github.com>

On Sat, 11 Dec 2021 15:37:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

Approving to allow Dan exclude this test.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/13


From dcubed at openjdk.java.net  Sat Dec 11 15:52:38 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:52:38 GMT
Subject: [jdk18] RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>
References: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>
Message-ID: <AnI0yI8CwY3XA4zn65GGVtpcfjrywZBiMlCwGymj3ts=.3f056d8d-ed23-4754-a744-b8c098b31386@github.com>

On Sat, 11 Dec 2021 15:37:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

@dfuch and @jayathirthrao - Can you please review this PR instead? Thanks!

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

PR: https://git.openjdk.java.net/jdk18/pull/13


From dcubed at openjdk.java.net  Sat Dec 11 15:57:13 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:57:13 GMT
Subject: [jdk18] RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <DcQ9BkekVQlE_YR6HmOCrCg-BMtTfYqQECGnUK9HoPw=.3d4babe4-364f-487f-b8f8-2504e92cdd32@github.com>
References: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>
 <DcQ9BkekVQlE_YR6HmOCrCg-BMtTfYqQECGnUK9HoPw=.3d4babe4-364f-487f-b8f8-2504e92cdd32@github.com>
Message-ID: <yfnJwAykINj_jZsEAqtq0bukAbo3UBH413wZ9T1GXUQ=.56d53392-9e6b-4288-ace5-f499f2245b8d@github.com>

On Sat, 11 Dec 2021 15:47:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.
>
> Approving to allow Dan exclude this test.

@AlanBateman - Thanks for the review!

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

PR: https://git.openjdk.java.net/jdk18/pull/13


From dcubed at openjdk.java.net  Sat Dec 11 15:57:14 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:57:14 GMT
Subject: [jdk18] Integrated: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>
References: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>
Message-ID: <ErRfzzrfQOBT5cfqQHln-wQwBumwM6BvnNDdttL2Gag=.7ccb3c34-3254-423c-bf44-8b10819fe5b8@github.com>

On Sat, 11 Dec 2021 15:37:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

This pull request has now been integrated.

Changeset: 9b99cbe7
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/9b99cbe7abf56d3ad5231a68b6506e35b89133c9
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8278580: ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64

Reviewed-by: alanb

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

PR: https://git.openjdk.java.net/jdk18/pull/13


From duke at openjdk.java.net  Sun Dec 12 09:09:09 2021
From: duke at openjdk.java.net (Emmanuel Bourg)
Date: Sun, 12 Dec 2021 09:09:09 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes
In-Reply-To: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
Message-ID: <lloX_HBgQDnC3Mkml-4f1dLjqWTffJP9CARU_89uJ48=.31e324ec-029c-4201-9dbf-727598c02f63@github.com>

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

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

Any reviewer for this? @prrace maybe ?

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

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


From serb at openjdk.java.net  Sun Dec 12 21:51:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 12 Dec 2021 21:51:14 GMT
Subject: Integrated: 8276819:
 javax/print/PrintServiceLookup/FlushCustomClassLoader.java fails to free
In-Reply-To: <G_gJrbch54Wejf9prEORoM9vl5ytQ1Z2dHi3KcZqjjE=.caa70a04-4540-40fa-bf41-15086170cf4e@github.com>
References: <G_gJrbch54Wejf9prEORoM9vl5ytQ1Z2dHi3KcZqjjE=.caa70a04-4540-40fa-bf41-15086170cf4e@github.com>
Message-ID: <acXcnUQlcB6aqxMRzwbXIXBN2gCdJsdcsJjlhVlr_NE=.3eb9b28c-1fb1-4246-8383-f6de0b2bb785@github.com>

On Thu, 9 Dec 2021 02:47:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is an attempt to make the FlushCustomClassLoader more stable. I cannot reproduce this bug so added some improvement blindly, based on assumption that the test may fail on the slow/overloaded system.
> 
>  * The attempt limitation was removed, but the test execution time decreased to 1 minute
>  * For each attempt the generation of OOM was added to make sure that the GC was triggered

This pull request has now been integrated.

Changeset: 7c2c5858
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7c2c58587d4eda5523331eae45e7d897252dc097
Stats:     9 lines in 1 file changed: 3 ins; 4 del; 2 mod

8276819: javax/print/PrintServiceLookup/FlushCustomClassLoader.java fails to free

Reviewed-by: psadhukhan, aivanov

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

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


From dbatrak at openjdk.java.net  Mon Dec 13 08:19:14 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Mon, 13 Dec 2021 08:19:14 GMT
Subject: RFR: 8278050: Armenian text isn't rendered on macOS if text layout
 is performed
In-Reply-To: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
References: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
Message-ID: <xvImN_5JOmkB8CFNqm3c40VJU60lOVYXwHf1Cz7oOFI=.d3f0fbe7-061b-42cd-8086-0517bf3162dc@github.com>

On Wed, 1 Dec 2021 10:52:38 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The problem is related to the implementation of font fallback on macOS, specifically to the path used when text layout
> is performed, i.e. the one using `FontSubstitution` and cascade lists. `CTFontCopyDefaultCascadeListForLanguages`'s output contains an entry for the font, able to render Armenian text ('NotoSansArmenian-Regular'), but `CFont.createCompositeFont` cannot find this font amongst registered fonts, and the entry is skipped, resulting in broken rendering.
> System font loading (performed by `CFontManager.loadNativeFonts`) relies on `[NSFontManager availableFontFamilies]`, but its output doesn't contain 'Noto Sans Armenian' (which is a family for 'NotoSansArmenian-Regular' font). 'Noto Sans Armenian' is recognized by `[NSFontManager availableMembersOfFontFamily:]` though, 'NotoSansArmenian-Regular' is contained in `[NSFontManager availableFonts]` output, and the font can be created and used normally, just like any other system font. Not sure why its family is 'hidden', maybe macOS developers wanted to limit the number of options
> displayed in font selection drop-downs.
> For reference, another cascade list item, ignored in similar way is 'NotoSansZawgyi-Regular'.
> 
> Proposed fix is to create `CFont` objects for cascade list items explicitly, if corresponding fonts are not registered. These objects are re-used between different fonts as their fallback components (to enable caching of char-to-glyph mapping), but are not made available to public font APIs.
> I've considered an alternative solution - using `[NSFontManager availableFonts]` instead of
> `[NSFontManager availableFontFamilies]` to load system fonts. Two factors complicate it though - `loadNativeFonts` will
> take more time (on my machine about 170 additional fonts will be loaded) and the order of font loading will change (which
> impacts the selection of 'preferred' plain/bold/italic/bolditalic components in `FontFamily` class). Both factors can be
> dealt with, but they make the solution more complicated and prone to regressions. For now, it seems not worth it.
> 
> I've not created a test, as it would rely on macOS providing a fallback font for Armenian script, which is not guaranteed.
> Existing tests pass fine with the fix.

Any chance for a second review?

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

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


From ant at openjdk.java.net  Mon Dec 13 16:56:25 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Mon, 13 Dec 2021 16:56:25 GMT
Subject: RFR: 8278612: test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes
 =?UTF-8?B?d2l0aOKApg==?=
Message-ID: <XVBgpRNivpgbQ1wkWRKwyu3_dmyZIYAsVNemrF_pKMw=.58f6869b-d7a0-488d-9eb7-9f17516974c0@github.com>

? VoiceOver on macOS

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

Commit messages:
 - 8278612: test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on macOS

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

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


From azvegint at openjdk.java.net  Mon Dec 13 17:25:12 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 13 Dec 2021 17:25:12 GMT
Subject: RFR: 8275843: Random crashes while the UI code is executed
In-Reply-To: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
References: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
Message-ID: <bzcAvEjvG6TEMtNFvVA6LqC3Fx3YgVVP__8Iu0oeZIQ=.455f3f26-103b-4687-9761-5e824f12d1ab@github.com>

On Mon, 1 Nov 2021 20:03:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please take a look to one more wagon in this train:
> [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795)->[JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931)->[JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579)->[JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392)->[Current issue](https://bugs.openjdk.java.net/browse/JDK-8275843). 
> 
> #### The short description:
> 
> We have an inconsistent between xrender java code and the x11 window. The java code thinks that all our windows support only two types of color models: IntRgbX11 and IntArgbPreX11, but the x11 window supports more types. If such inconsistency occurs we render some garbage, or just crash since our "blits" will assume the wrong data layout. This issue was reported and fixed [before](http://hg.openjdk.java.net/jdk/jdk/rev/c53905e7dc57) but it was not realized why the rendering was wrong and that it can cause a crash. The fix is similar to the old one.
> 
> #### The long description:
> 
>  * Once upon a time this bug was filed [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) it was about the rendering of colors to the volatile image, the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8176795?focusedCommentId=14138323&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14138323) In short: the volatile images in the xrender use intArgbPre color model, it means that the SunGraphics2D object [convert](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1753) the argb value to the argbPre before passing it to the pipeline, and the xrender pipeline [convert](http://hg.openjdk.java.net/jdk/jdk/rev/e4b03365ddbf) this value to the argbPre one more time -> double-conversion-> the bug is reproduced. The fix for that bug disabled the second conversion in the xrender. but it does not take into account that this code path is u
 sed for rendering to the ARGB X11 window where the shared code does not convert the color, so the next bug was filed.
>  * The second bug is [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931), the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8204931?focusedCommentId=14199800&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14199800). In short the bug was about rendering directly to the window and missing color conversion removed previously. The fix for that bug changed the surface type used by the window, so the shared code start to convert the color from ARGB to argbPre, but it does not take into account that we do not control the color model of the window, see how many of them we actually [support](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceData.java#L501) Also note in the link above that if we do not recognize the type we do not fallback to something but throw InvalidPipeException, this is because the blits(and other primitives) may use t
 his type to access the data directly. So the next bug was reported:
>  * This is the third issue [JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579). The fix for that issue tried to roll back the previous one but does not take into account that the conversion removed by the first issue should be rollback as well, so the last bug was filed.
>  * The "last" issue is [JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392) rollback the previous one. So the bug reported in the third report come back.
> 
> #### Fix description
> 
> The fix for the current issue contains a few parts:
>  * Rollback of the [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931) so we will use the proper surface data for the window.
>  * Return conversion in the xrender pipeline removed by the [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) So we will convert it when we render to the volatile image(argbPre) and to the window(argb). We need to convert in both cases since the xrender API which we use expects the argbPre colors.
>  * Start to use the [eargb](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1752) value( instead of pixel) stored in the SunGraphics2D so we did not get the double conversion.
> 
> Some tests are updated and one more is added.
> 
> ### Note
> I have checked the performance implication of this change and it looks like after this change the sequence window.setvisible(true)/window.dispose() will work 30% faster, this may affect the tests which does not wait enough time to make the window visible. Probably this is the reason why some of our tests became more stable at some point in jdk11.
> 
> 
> I have tested this by the jck and jdk_desktop tests. But any additional verification/testing is welcome.

I can confirm that testing looks good, however I didn't manage to get is crashed even once before the fix even with updated tests. (on personal, VM or multiple CI runs)

How often it fails for you and on what config?

src/java.desktop/unix/classes/sun/java2d/xr/XRSurfaceData.java line 403:

> 401:         SurfaceType sType = null;
> 402: 
> 403:         switch (transparency) {

Since you are touching this, you might want to fix indent for cases in this switch.

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

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


From cushon at openjdk.java.net  Mon Dec 13 17:57:15 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Mon, 13 Dec 2021 17:57:15 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v9]
In-Reply-To: <49gYRPX_QAzZcEsFovkzHbBn2I28lXo-3fYDHmYSUD0=.cf6525da-c24b-406f-ad90-2eabcbd840c3@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <49gYRPX_QAzZcEsFovkzHbBn2I28lXo-3fYDHmYSUD0=.cf6525da-c24b-406f-ad90-2eabcbd840c3@github.com>
Message-ID: <fpiUcgPyUu2J1Syutsplkgwu4PUWtk3u1TR0iKyDspE=.88dd3e15-af6f-4821-91db-243ad1f2330f@github.com>

On Fri, 10 Dec 2021 17:03:49 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a few more missing calls to LookAndFeel.uninstallColors

> > To be clear, I think the proposed change is good on its own: it adds convenience methods to clean up UI properties when a L&F is uninstalled, it adds the clean-up where it was missing. But it doesn't fit into the fix of this test failure. This work should be an enhancement performed under another bugid.
>
> Better to start afresh with a new bug with an appropriate synopsis and then write some new tests that verify the UI is uninstalled on all the Swing components as you cycle though available L&Fs per-platform.

I have filed https://bugs.openjdk.java.net/browse/JDK-8278620 to track adding test coverage for the `uninstallUI` methods and deciding on the best fix for that issue.

> Taking into account the above comments, this test could be simplified to write out the objects and then read them in. No persistent serialization which is explicitly unsupported.
>
>  I think we should scrap the test or find a different way to do whatever it intends to verify.

Currently the test relies on making a manual change to `DragGestureEvent` and `DragGestureRecognize` before serializing the objects, so it's not clear to me how the test would be modified to do that at test-time: https://github.com/openjdk/jdk/blob/5a4a9bb9d55134deac0e02cf37f31d1dd2223024/test/jdk/java/awt/dnd/BadSerializationTest/BadSerializationTest.java#L95-L96

I'm happy to update this change to scrap the test if there's agreement that's the best resolution.

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

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


From serb at openjdk.java.net  Mon Dec 13 20:11:20 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 13 Dec 2021 20:11:20 GMT
Subject: RFR: 8278612: test/jdk/java/awt/dnd/RemoveDropTargetCrashTest
 crashes =?UTF-8?B?d2l0aOKApg==?=
In-Reply-To: <XVBgpRNivpgbQ1wkWRKwyu3_dmyZIYAsVNemrF_pKMw=.58f6869b-d7a0-488d-9eb7-9f17516974c0@github.com>
References: <XVBgpRNivpgbQ1wkWRKwyu3_dmyZIYAsVNemrF_pKMw=.58f6869b-d7a0-488d-9eb7-9f17516974c0@github.com>
Message-ID: <SAOHestUTAdUoy17Ww5gRg17BNWAKph-mHp3lxDstME=.433851d5-8ac7-429e-b29f-39e842baa9b4@github.com>

On Mon, 13 Dec 2021 16:50:00 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> ? VoiceOver on macOS

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.m line 62:

> 60: {
> 61:     if (fTabGroupAxContext == NULL) {
> 62:         id parent = [self parent];

Probably we can sanitize all casts to (CommonComponentAccessibility *) via some utility method which will check the type and then cast, so all calling code will get a CommonComponentAccessibility or nil?

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

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


From serb at openjdk.java.net  Mon Dec 13 20:27:19 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 13 Dec 2021 20:27:19 GMT
Subject: RFR: 8275843: Random crashes while the UI code is executed
In-Reply-To: <bzcAvEjvG6TEMtNFvVA6LqC3Fx3YgVVP__8Iu0oeZIQ=.455f3f26-103b-4687-9761-5e824f12d1ab@github.com>
References: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
 <bzcAvEjvG6TEMtNFvVA6LqC3Fx3YgVVP__8Iu0oeZIQ=.455f3f26-103b-4687-9761-5e824f12d1ab@github.com>
Message-ID: <DvDHYYNQku50tJJlN-pWrXuy1rrdRMEE0xXX1hN-yWc=.1d26bc76-d271-42ea-a5b7-7af910cd2d2f@github.com>

On Mon, 13 Dec 2021 15:42:43 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Please take a look to one more wagon in this train:
>> [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795)->[JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931)->[JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579)->[JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392)->[Current issue](https://bugs.openjdk.java.net/browse/JDK-8275843). 
>> 
>> #### The short description:
>> 
>> We have an inconsistent between xrender java code and the x11 window. The java code thinks that all our windows support only two types of color models: IntRgbX11 and IntArgbPreX11, but the x11 window supports more types. If such inconsistency occurs we render some garbage, or just crash since our "blits" will assume the wrong data layout. This issue was reported and fixed [before](http://hg.openjdk.java.net/jdk/jdk/rev/c53905e7dc57) but it was not realized why the rendering was wrong and that it can cause a crash. The fix is similar to the old one.
>> 
>> #### The long description:
>> 
>>  * Once upon a time this bug was filed [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) it was about the rendering of colors to the volatile image, the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8176795?focusedCommentId=14138323&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14138323) In short: the volatile images in the xrender use intArgbPre color model, it means that the SunGraphics2D object [convert](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1753) the argb value to the argbPre before passing it to the pipeline, and the xrender pipeline [convert](http://hg.openjdk.java.net/jdk/jdk/rev/e4b03365ddbf) this value to the argbPre one more time -> double-conversion-> the bug is reproduced. The fix for that bug disabled the second conversion in the xrender. but it does not take into account that this code path is 
 used for rendering to the ARGB X11 window where the shared code does not convert the color, so the next bug was filed.
>>  * The second bug is [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931), the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8204931?focusedCommentId=14199800&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14199800). In short the bug was about rendering directly to the window and missing color conversion removed previously. The fix for that bug changed the surface type used by the window, so the shared code start to convert the color from ARGB to argbPre, but it does not take into account that we do not control the color model of the window, see how many of them we actually [support](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceData.java#L501) Also note in the link above that if we do not recognize the type we do not fallback to something but throw InvalidPipeException, this is because the blits(and other primitives) may use 
 this type to access the data directly. So the next bug was reported:
>>  * This is the third issue [JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579). The fix for that issue tried to roll back the previous one but does not take into account that the conversion removed by the first issue should be rollback as well, so the last bug was filed.
>>  * The "last" issue is [JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392) rollback the previous one. So the bug reported in the third report come back.
>> 
>> #### Fix description
>> 
>> The fix for the current issue contains a few parts:
>>  * Rollback of the [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931) so we will use the proper surface data for the window.
>>  * Return conversion in the xrender pipeline removed by the [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) So we will convert it when we render to the volatile image(argbPre) and to the window(argb). We need to convert in both cases since the xrender API which we use expects the argbPre colors.
>>  * Start to use the [eargb](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1752) value( instead of pixel) stored in the SunGraphics2D so we did not get the double conversion.
>> 
>> Some tests are updated and one more is added.
>> 
>> ### Note
>> I have checked the performance implication of this change and it looks like after this change the sequence window.setvisible(true)/window.dispose() will work 30% faster, this may affect the tests which does not wait enough time to make the window visible. Probably this is the reason why some of our tests became more stable at some point in jdk11.
>> 
>> 
>> I have tested this by the jck and jdk_desktop tests. But any additional verification/testing is welcome.
>
> src/java.desktop/unix/classes/sun/java2d/xr/XRSurfaceData.java line 403:
> 
>> 401:         SurfaceType sType = null;
>> 402: 
>> 403:         switch (transparency) {
> 
> Since you are touching this, you might want to fix indent for cases in this switch.

I can change it, but looks like all switches in the "sun.java2d.xr" use this code style.

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

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


From serb at openjdk.java.net  Mon Dec 13 20:35:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 13 Dec 2021 20:35:15 GMT
Subject: RFR: 8275843: Random crashes while the UI code is executed
In-Reply-To: <bzcAvEjvG6TEMtNFvVA6LqC3Fx3YgVVP__8Iu0oeZIQ=.455f3f26-103b-4687-9761-5e824f12d1ab@github.com>
References: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
 <bzcAvEjvG6TEMtNFvVA6LqC3Fx3YgVVP__8Iu0oeZIQ=.455f3f26-103b-4687-9761-5e824f12d1ab@github.com>
Message-ID: <9Gso5jy9lm0RPqzYT0uJ-HlkZa0Ck7I8DlMR2jbqNo4=.35d6cf70-1781-4ae8-b595-8bcf474bbc0a@github.com>

On Mon, 13 Dec 2021 17:22:05 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> How often it fails for you and on what config?

I think the easiest way to reproduce the crash is to force the x11 to use some completely different format, like this:
Xvfb :1 -screen 0 1920x1080x16

Note the usage of 16 bits depth. The vnc servers could be used as well.

In such config the new DrawCustomColorModel.java will crash most of the time(depends on timings)

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

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


From serb at openjdk.java.net  Mon Dec 13 20:46:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 13 Dec 2021 20:46:06 GMT
Subject: RFR: 8275843: Random crashes while the UI code is executed [v2]
In-Reply-To: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
References: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
Message-ID: <XkVHryiot1WqCYvjRf8JJdkOJ6Zrh030SBO6N63uoJo=.d5d50b39-cdf9-4d09-9bf8-2fd3adb4209f@github.com>

> Please take a look to one more wagon in this train:
> [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795)->[JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931)->[JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579)->[JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392)->[Current issue](https://bugs.openjdk.java.net/browse/JDK-8275843). 
> 
> #### The short description:
> 
> We have an inconsistent between xrender java code and the x11 window. The java code thinks that all our windows support only two types of color models: IntRgbX11 and IntArgbPreX11, but the x11 window supports more types. If such inconsistency occurs we render some garbage, or just crash since our "blits" will assume the wrong data layout. This issue was reported and fixed [before](http://hg.openjdk.java.net/jdk/jdk/rev/c53905e7dc57) but it was not realized why the rendering was wrong and that it can cause a crash. The fix is similar to the old one.
> 
> #### The long description:
> 
>  * Once upon a time this bug was filed [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) it was about the rendering of colors to the volatile image, the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8176795?focusedCommentId=14138323&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14138323) In short: the volatile images in the xrender use intArgbPre color model, it means that the SunGraphics2D object [convert](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1753) the argb value to the argbPre before passing it to the pipeline, and the xrender pipeline [convert](http://hg.openjdk.java.net/jdk/jdk/rev/e4b03365ddbf) this value to the argbPre one more time -> double-conversion-> the bug is reproduced. The fix for that bug disabled the second conversion in the xrender. but it does not take into account that this code path is u
 sed for rendering to the ARGB X11 window where the shared code does not convert the color, so the next bug was filed.
>  * The second bug is [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931), the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8204931?focusedCommentId=14199800&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14199800). In short the bug was about rendering directly to the window and missing color conversion removed previously. The fix for that bug changed the surface type used by the window, so the shared code start to convert the color from ARGB to argbPre, but it does not take into account that we do not control the color model of the window, see how many of them we actually [support](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceData.java#L501) Also note in the link above that if we do not recognize the type we do not fallback to something but throw InvalidPipeException, this is because the blits(and other primitives) may use t
 his type to access the data directly. So the next bug was reported:
>  * This is the third issue [JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579). The fix for that issue tried to roll back the previous one but does not take into account that the conversion removed by the first issue should be rollback as well, so the last bug was filed.
>  * The "last" issue is [JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392) rollback the previous one. So the bug reported in the third report come back.
> 
> #### Fix description
> 
> The fix for the current issue contains a few parts:
>  * Rollback of the [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931) so we will use the proper surface data for the window.
>  * Return conversion in the xrender pipeline removed by the [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) So we will convert it when we render to the volatile image(argbPre) and to the window(argb). We need to convert in both cases since the xrender API which we use expects the argbPre colors.
>  * Start to use the [eargb](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1752) value( instead of pixel) stored in the SunGraphics2D so we did not get the double conversion.
> 
> Some tests are updated and one more is added.
> 
> ### Note
> I have checked the performance implication of this change and it looks like after this change the sequence window.setvisible(true)/window.dispose() will work 30% faster, this may affect the tests which does not wait enough time to make the window visible. Probably this is the reason why some of our tests became more stable at some point in jdk11.
> 
> 
> I have tested this by the jck and jdk_desktop tests. But any additional verification/testing is welcome.

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

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

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6199/files
  - new: https://git.openjdk.java.net/jdk/pull/6199/files/f20747a6..cac8aa81

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

  Stats: 940191 lines in 2561 files changed: 489903 ins; 433827 del; 16461 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6199.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6199/head:pull/6199

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


From azvegint at openjdk.java.net  Mon Dec 13 22:03:24 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 13 Dec 2021 22:03:24 GMT
Subject: RFR: 8275843: Random crashes while the UI code is executed [v2]
In-Reply-To: <XkVHryiot1WqCYvjRf8JJdkOJ6Zrh030SBO6N63uoJo=.d5d50b39-cdf9-4d09-9bf8-2fd3adb4209f@github.com>
References: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
 <XkVHryiot1WqCYvjRf8JJdkOJ6Zrh030SBO6N63uoJo=.d5d50b39-cdf9-4d09-9bf8-2fd3adb4209f@github.com>
Message-ID: <7Fi7vH96eXbTO_5c3B0g0_Q_gRuJ30baQCYfi9rW-dA=.7b1b9874-35d1-4f11-bfcd-cd951931d780@github.com>

On Mon, 13 Dec 2021 20:46:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Please take a look to one more wagon in this train:
>> [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795)->[JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931)->[JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579)->[JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392)->[Current issue](https://bugs.openjdk.java.net/browse/JDK-8275843). 
>> 
>> #### The short description:
>> 
>> We have an inconsistent between xrender java code and the x11 window. The java code thinks that all our windows support only two types of color models: IntRgbX11 and IntArgbPreX11, but the x11 window supports more types. If such inconsistency occurs we render some garbage, or just crash since our "blits" will assume the wrong data layout. This issue was reported and fixed [before](http://hg.openjdk.java.net/jdk/jdk/rev/c53905e7dc57) but it was not realized why the rendering was wrong and that it can cause a crash. The fix is similar to the old one.
>> 
>> #### The long description:
>> 
>>  * Once upon a time this bug was filed [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) it was about the rendering of colors to the volatile image, the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8176795?focusedCommentId=14138323&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14138323) In short: the volatile images in the xrender use intArgbPre color model, it means that the SunGraphics2D object [convert](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1753) the argb value to the argbPre before passing it to the pipeline, and the xrender pipeline [convert](http://hg.openjdk.java.net/jdk/jdk/rev/e4b03365ddbf) this value to the argbPre one more time -> double-conversion-> the bug is reproduced. The fix for that bug disabled the second conversion in the xrender. but it does not take into account that this code path is 
 used for rendering to the ARGB X11 window where the shared code does not convert the color, so the next bug was filed.
>>  * The second bug is [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931), the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8204931?focusedCommentId=14199800&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14199800). In short the bug was about rendering directly to the window and missing color conversion removed previously. The fix for that bug changed the surface type used by the window, so the shared code start to convert the color from ARGB to argbPre, but it does not take into account that we do not control the color model of the window, see how many of them we actually [support](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceData.java#L501) Also note in the link above that if we do not recognize the type we do not fallback to something but throw InvalidPipeException, this is because the blits(and other primitives) may use 
 this type to access the data directly. So the next bug was reported:
>>  * This is the third issue [JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579). The fix for that issue tried to roll back the previous one but does not take into account that the conversion removed by the first issue should be rollback as well, so the last bug was filed.
>>  * The "last" issue is [JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392) rollback the previous one. So the bug reported in the third report come back.
>> 
>> #### Fix description
>> 
>> The fix for the current issue contains a few parts:
>>  * Rollback of the [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931) so we will use the proper surface data for the window.
>>  * Return conversion in the xrender pipeline removed by the [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) So we will convert it when we render to the volatile image(argbPre) and to the window(argb). We need to convert in both cases since the xrender API which we use expects the argbPre colors.
>>  * Start to use the [eargb](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1752) value( instead of pixel) stored in the SunGraphics2D so we did not get the double conversion.
>> 
>> Some tests are updated and one more is added.
>> 
>> ### Note
>> I have checked the performance implication of this change and it looks like after this change the sequence window.setvisible(true)/window.dispose() will work 30% faster, this may affect the tests which does not wait enough time to make the window visible. Probably this is the reason why some of our tests became more stable at some point in jdk11.
>> 
>> 
>> I have tested this by the jck and jdk_desktop tests. But any additional verification/testing is welcome.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Update DrawCustomColorModel.java
>  - Merge branch 'master' into alpha
>  - Merge branch 'master' into alpha
>  - Merge branch 'master' into alpha
>  - Update DrawCustomColorModel.java
>  - fix space
>  - Validate color for the new eargb only
>  - Initial fix

Marked as reviewed by azvegint (Reviewer).

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

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


From azvegint at openjdk.java.net  Mon Dec 13 22:03:24 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 13 Dec 2021 22:03:24 GMT
Subject: RFR: 8275843: Random crashes while the UI code is executed
In-Reply-To: <9Gso5jy9lm0RPqzYT0uJ-HlkZa0Ck7I8DlMR2jbqNo4=.35d6cf70-1781-4ae8-b595-8bcf474bbc0a@github.com>
References: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
 <bzcAvEjvG6TEMtNFvVA6LqC3Fx3YgVVP__8Iu0oeZIQ=.455f3f26-103b-4687-9761-5e824f12d1ab@github.com>
 <9Gso5jy9lm0RPqzYT0uJ-HlkZa0Ck7I8DlMR2jbqNo4=.35d6cf70-1781-4ae8-b595-8bcf474bbc0a@github.com>
Message-ID: <bUqfoM-o3YJMomW5Ytej3fnqzrCfTaFtVnfYquY4jec=.79f8aece-15d8-4e6c-8903-302658915da6@github.com>

On Mon, 13 Dec 2021 20:31:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I think the easiest way to reproduce the crash is to force the x11 to use some completely different format, like this: Xvfb :1 -screen 0 1920x1080x16

Yes, this one crashes for me almost instantly.

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

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


From azvegint at openjdk.java.net  Mon Dec 13 22:03:24 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 13 Dec 2021 22:03:24 GMT
Subject: RFR: 8275843: Random crashes while the UI code is executed [v2]
In-Reply-To: <DvDHYYNQku50tJJlN-pWrXuy1rrdRMEE0xXX1hN-yWc=.1d26bc76-d271-42ea-a5b7-7af910cd2d2f@github.com>
References: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
 <bzcAvEjvG6TEMtNFvVA6LqC3Fx3YgVVP__8Iu0oeZIQ=.455f3f26-103b-4687-9761-5e824f12d1ab@github.com>
 <DvDHYYNQku50tJJlN-pWrXuy1rrdRMEE0xXX1hN-yWc=.1d26bc76-d271-42ea-a5b7-7af910cd2d2f@github.com>
Message-ID: <OfRWg7gfaK-SmYkT2pHk3zCEUZukDhAp4C9c2D-Jfao=.4813a0aa-a2c2-4122-92ce-65ec0fb33a42@github.com>

On Mon, 13 Dec 2021 20:24:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/unix/classes/sun/java2d/xr/XRSurfaceData.java line 403:
>> 
>>> 401:         SurfaceType sType = null;
>>> 402: 
>>> 403:         switch (transparency) {
>> 
>> Since you are touching this, you might want to fix indent for cases in this switch.
>
> I can change it, but looks like all switches in the "sun.java2d.xr" use this code style.

Then it is fine as it is.

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

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


From jwilhelm at openjdk.java.net  Tue Dec 14 01:49:19 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 14 Dec 2021 01:49:19 GMT
Subject: RFR: Merge jdk18
Message-ID: <G9smFLJnz840gwbfeIat9kynTHpPxVQtUN26NkbTmBY=.89fed81a-0251-4468-b20b-8cfd2ee8e3e1@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge
 - 8132785: java/lang/management/ThreadMXBean/ThreadLists.java fails intermittently
 - 8273108: RunThese24H crashes with SEGV in markWord::displaced_mark_helper() after JDK-8268276
 - 8278580: ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64
 - 8277299: STACK_OVERFLOW in Java_sun_awt_shell_Win32ShellFolder2_getIconBits

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

Changes: https://git.openjdk.java.net/jdk/pull/6824/files
  Stats: 119 lines in 6 files changed: 85 ins; 1 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6824.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6824/head:pull/6824

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


From jwilhelm at openjdk.java.net  Tue Dec 14 02:21:17 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 14 Dec 2021 02:21:17 GMT
Subject: RFR: Merge jdk18 [v2]
In-Reply-To: <G9smFLJnz840gwbfeIat9kynTHpPxVQtUN26NkbTmBY=.89fed81a-0251-4468-b20b-8cfd2ee8e3e1@github.com>
References: <G9smFLJnz840gwbfeIat9kynTHpPxVQtUN26NkbTmBY=.89fed81a-0251-4468-b20b-8cfd2ee8e3e1@github.com>
Message-ID: <BpGRPdTHQBjmHRAKHcLpbqGZLQhG_0FMx0w0MVnDCs0=.e6fd03f9-40a3-45c6-a5a4-15e573328eb6@github.com>

> Forwardport JDK 18 -> JDK 19

Jesper Wilhelmsson 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 29 additional commits since the last revision:

 - Merge
 - 8278275: Initial nroff manpage generation for JDK 19
   
   Reviewed-by: erikj, jjg, iris
 - 8278630: ProblemList compiler/vectorapi/reshape/TestVectorCastAVX512.java on X64
   
   Reviewed-by: psandoz
 - 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr
   
   Reviewed-by: kevinw, sspitsyn, amenkov
 - 8259610: VectorReshapeTests are not effective due to failing to intrinsify "VectorSupport.convert"
   
   Reviewed-by: psandoz, chagedorn
 - 8276241: JVM does not flag constant class entries ending in '/'
   
   Reviewed-by: dholmes, lfoltan
 - 8277481: Obsolete seldom used CDS flags
   
   Reviewed-by: iklam, ccheung, dholmes
 - 8271079: JavaFileObject#toUri and multi-release jars
   
   Reviewed-by: jjg, lancea, alanb
 - 8278482: G1: Improve HeapRegion::block_is_obj
   
   Reviewed-by: sjohanss, tschatzl, mli
 - 8278344: sun/security/pkcs12/KeytoolOpensslInteropTest.java test fails because of different openssl output
   
   Reviewed-by: mdoerr, goetz, stuefe
 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/9d2883a1...dc02f07e

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6824/files
  - new: https://git.openjdk.java.net/jdk/pull/6824/files/dc02f07e..dc02f07e

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

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

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


From jwilhelm at openjdk.java.net  Tue Dec 14 02:21:19 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 14 Dec 2021 02:21:19 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <G9smFLJnz840gwbfeIat9kynTHpPxVQtUN26NkbTmBY=.89fed81a-0251-4468-b20b-8cfd2ee8e3e1@github.com>
References: <G9smFLJnz840gwbfeIat9kynTHpPxVQtUN26NkbTmBY=.89fed81a-0251-4468-b20b-8cfd2ee8e3e1@github.com>
Message-ID: <mbtbn8MLitIqcoSif-cvbsgEYfLRe5zRyDvrwfvyGEc=.b6ad1d02-7b22-4f5e-8167-35c3633bea93@github.com>

On Tue, 14 Dec 2021 01:35:43 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 8401a059
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8401a059bd01b32e3532f806d3d8b60e851c468a
Stats:     119 lines in 6 files changed: 85 ins; 1 del; 33 mod

Merge

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

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


From psadhukhan at openjdk.java.net  Tue Dec 14 06:26:38 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 14 Dec 2021 06:26:38 GMT
Subject: RFR: 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java
 fails in macos12
Message-ID: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>

Test seem to be failing in macos12.0.1 (although it does not seem to affect 12.1) due to keypresses of "a", "a", "d" is not selecting "aad" but "ade" which seems to point to the fact that 2 exclusive "a" keypress are considered as 1 "a" keypress.
Although I am not able to reroduce this issue if test is ran standalone or in JTree group, but it fails when ran as toplevel "jdk_desktop" testgroup or even whole swing test group.

Looking at text navigational algorithm probably done in JDK-4908142 (although I am not sure if this is done for that bug or subsequently revised) 
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3804

it seems if a subsequent key press comes after a predefined timefactor after the previous keypress, it is considered as a fresh/new keypress and not part of ongoing string search ie, if 2nd "a" comes after the predefined timefactor from 1st "a', then seacrh algorithm will search for "ad" and not "aad" as can be seen here
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3815

I am not sure why macos12 will take so long  for 2nd "a" keypress  but the logs corraborates that it does take more than "timefactor" time what is set now, which is 1000.
1st "a" keypress, we have time 1639400688049 lastTime 0 typedString a
2nd "a" keypress, we have time 1639400691150 lastTime 1639400688049 typedString a [which is diff of 3101]

So, proposed fix is to configure "Tree.timeFactor" to 5000 to workaround this macos12 issue. It pass when full desktop tests is run in macos12 and also test passes in all platforms.

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

Commit messages:
 - Fix
 - Merge master
 - 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java fails in macos12

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

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


From duke at openjdk.java.net  Tue Dec 14 06:49:18 2021
From: duke at openjdk.java.net (Yanli Sang)
Date: Tue, 14 Dec 2021 06:49:18 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v5]
In-Reply-To: <SniwEMbSvc9v2COxfMhVB367rz5bbnUspnlF0IPuqFE=.3231ac5d-2613-4798-b39d-bdf9f29e06ba@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <U2NwWg-Qzc6gjAUIPs_v-B14fG4UPFPd0ELpAfw-xkU=.de144f74-eb1c-47b5-a198-245566b1d81e@github.com>
 <SniwEMbSvc9v2COxfMhVB367rz5bbnUspnlF0IPuqFE=.3231ac5d-2613-4798-b39d-bdf9f29e06ba@github.com>
Message-ID: <KtDRQsvZL82n68Nlqfs_ZZFiqsxwcoXQBnx8f3_6Cuw=.931c0fb7-9e2b-46af-a317-83d099489c3e@github.com>

On Wed, 1 Dec 2021 10:05:31 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8262297: ImageIO.write() method will throw IndexOutOfBoundsException
>
> This change has caused regression : https://bugs.openjdk.java.net/browse/JDK-8278047
> So this change will be reverted for further analysis.

@jayathirthrao  @masyano @prrace @AlanBateman We also meet the same issue in  PNGImageWriter.write,  Do you have any idea how to fix it ? Thanks in advance. 

at java.desktop/javax.imageio.ImageWriter.write(ImageWriter.java:613)
at java.desktop/com.sun.imageio.plugins.png.PNGImageWriter.write(PNGImageWriter.java:1283)
at java.desktop/com.sun.imageio.plugins.png.PNGImageWriter.write_IDAT(PNGImageWriter.java:1050)
at java.desktop/com.sun.imageio.plugins.png.IDATOutputStream.finish(PNGImageWriter.java:273)
at java.desktop/com.sun.imageio.plugins.png.IDATOutputStream.deflate(PNGImageWriter.java:248)
at java.desktop/com.sun.imageio.plugins.png.IDATOutputStream.finishChunk(PNGImageWriter.java:200)
at java.desktop/javax.imageio.stream.FileCacheImageOutputStream.seek(FileCacheImageOutputStream.java:170)
java.lang.IndexOutOfBoundsException

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

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


From myano at openjdk.java.net  Tue Dec 14 10:08:12 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Tue, 14 Dec 2021 10:08:12 GMT
Subject: RFR: 8277463: JFileChooser with Metal L&F doesn't show
 non-canonical UNC path in - Look in
In-Reply-To: <RfkEC5jFuLbyeNKautaXwezn5Pf6gwV7zeNaoSiS5m8=.59930757-612d-4f82-82c6-3b11551dc691@github.com>
References: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
 <RfkEC5jFuLbyeNKautaXwezn5Pf6gwV7zeNaoSiS5m8=.59930757-612d-4f82-82c6-3b11551dc691@github.com>
Message-ID: <aBT4Pjf38HPkStuqUuCduGNuW-t2D29FJeymryUS6d0=.aac236a0-53de-4bd3-8923-b3511599c478@github.com>

On Fri, 10 Dec 2021 10:05:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I would like to fix the bug reported in JDK-8277463.
>> 
>> As reporter's investigation, ShellFolder.getNormalizedFile() returns incorrect value for non-canonical Windows UNC path. getNormalizedFile() is used for symbolic link path, but Windows environment does not handle symbolic link. And, getCanonicalFile() returns correct path for a directory link in Windows which is made with `mklink` command. So getNormalizedFile() should perform to return getCanonicalFile() like WindowsFileChooserUI.addItem() at Windows environment.
>
> I am not able to reproduce the issue even without the fix. How did you reproduce?
> I tried "\\\< mypcname>\dir.." and I could see "Documents" folder in "Look In" combobox of filechooser..It supposed to be empty for bug to be reproduced..
> If  I put in \\\< mypcname> in Windows Run prompt, I get no folder btw so no "dir" is present in my \\\< mypcname> folder actually and it does not allow me to create one in that \\\< mypcname> folder

@prsadhuk The valid shared folder is required to reproduce this bug. If you don't have valid shared folders, "Look in" combobox shows "Documents" correctly. Please try to make a valid shared folder and sub directory. e.g. `\<yourpcname><shared dir><dir>..`

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

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


From myano at openjdk.java.net  Tue Dec 14 11:49:16 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Tue, 14 Dec 2021 11:49:16 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails [v2]
In-Reply-To: <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>
 <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
Message-ID: <c3mwhU9EhXqJBDtnxO7M5xzYMb26jjOggfcDvtAhUU4=.a6d4e62b-8f73-4b35-9a5a-303d484a1264@github.com>

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

>> Masanori Yano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - Merge branch 'master' of https://github.com/masyano/jdk into 7001973
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>
> I'll check it, let me some time.

@mrserb I have tested on MacOS. The drawing result has no problem, and passed with no Exception. Please review this PR again.

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

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


From myano at openjdk.java.net  Tue Dec 14 12:00:13 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Tue, 14 Dec 2021 12:00:13 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <XNGsAkbvY13zmHrSmo3LpPDQNQNb97ocf_501nLgCMY=.da8f1bf4-c305-4e32-9d39-b2ab01a3da26@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <-hj0v7RZ0HPpP9GND5csZsZ1Vz7oxaufOAC0-ZygtwM=.6a5ae7a8-52d6-4e3e-a166-2fae2c23dbe0@github.com>
 <cTqTWZsK6uJI_Kw9nUymKQnYxxzWBRrk52qJAKpAc9I=.18f7dffd-3ebe-4bd0-bc2f-d61b55437036@github.com>
 <aZX6pJkrGOTYLlAHRl9WlEGtoahiInx4QzelDWpV2b0=.c9a736f9-5dd5-4382-8513-94a0233105dc@github.com>
 <QPyLlBXqr80h-_OjGxuv6tGNl8_-IZ8IHF-_8QWy894=.b18fd0a2-4497-4aae-87b1-1570531f2862@github.com>
 <2rBhm1b2wZwnJFYIve6hdNLHFE0iAkGbj1GkDkSOUCs=.726e6e6a-76b6-4657-b44b-dd854769055c@github.com>
 <k1gQRfQhMEC2tFwq5ZyyEmfebNqR6Mws651ijtdhTc8=.57c33d5c-9b6e-4b6c-9f4b-0afae0d0615f@github.com>
 <XNGsAkbvY13zmHrSmo3LpPDQNQNb97ocf_501nLgCMY=.da8f1bf4-c305-4e32-9d39-b2ab01a3da26@github.com>
Message-ID: <tpY96Dg70B3FeoSTTat1xnV-gQPYxUJLbA5KMxsAq8c=.b3031417-9232-4b05-8438-c317c1de32da@github.com>

On Thu, 18 Nov 2021 00:02:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @mrserb Can I hope this fix will be integrated after JDK-8270874 is fixed?
>
> Yes.

@mrserb @prrace JDK 18 has been forked, so please resume the review of this fix.

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

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


From serb at openjdk.java.net  Tue Dec 14 17:02:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 14 Dec 2021 17:02:48 GMT
Subject: RFR: 8275843: Random crashes while the UI code is executed [v3]
In-Reply-To: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
References: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
Message-ID: <1k6XJo6V4z78CxcRXL9U5322B21KzszYjj7ek2mP5SE=.8c79c2e2-b79b-45f4-be61-86efcc0b5093@github.com>

> Please take a look to one more wagon in this train:
> [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795)->[JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931)->[JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579)->[JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392)->[Current issue](https://bugs.openjdk.java.net/browse/JDK-8275843). 
> 
> #### The short description:
> 
> We have an inconsistent between xrender java code and the x11 window. The java code thinks that all our windows support only two types of color models: IntRgbX11 and IntArgbPreX11, but the x11 window supports more types. If such inconsistency occurs we render some garbage, or just crash since our "blits" will assume the wrong data layout. This issue was reported and fixed [before](http://hg.openjdk.java.net/jdk/jdk/rev/c53905e7dc57) but it was not realized why the rendering was wrong and that it can cause a crash. The fix is similar to the old one.
> 
> #### The long description:
> 
>  * Once upon a time this bug was filed [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) it was about the rendering of colors to the volatile image, the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8176795?focusedCommentId=14138323&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14138323) In short: the volatile images in the xrender use intArgbPre color model, it means that the SunGraphics2D object [convert](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1753) the argb value to the argbPre before passing it to the pipeline, and the xrender pipeline [convert](http://hg.openjdk.java.net/jdk/jdk/rev/e4b03365ddbf) this value to the argbPre one more time -> double-conversion-> the bug is reproduced. The fix for that bug disabled the second conversion in the xrender. but it does not take into account that this code path is u
 sed for rendering to the ARGB X11 window where the shared code does not convert the color, so the next bug was filed.
>  * The second bug is [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931), the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8204931?focusedCommentId=14199800&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14199800). In short the bug was about rendering directly to the window and missing color conversion removed previously. The fix for that bug changed the surface type used by the window, so the shared code start to convert the color from ARGB to argbPre, but it does not take into account that we do not control the color model of the window, see how many of them we actually [support](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceData.java#L501) Also note in the link above that if we do not recognize the type we do not fallback to something but throw InvalidPipeException, this is because the blits(and other primitives) may use t
 his type to access the data directly. So the next bug was reported:
>  * This is the third issue [JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579). The fix for that issue tried to roll back the previous one but does not take into account that the conversion removed by the first issue should be rollback as well, so the last bug was filed.
>  * The "last" issue is [JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392) rollback the previous one. So the bug reported in the third report come back.
> 
> #### Fix description
> 
> The fix for the current issue contains a few parts:
>  * Rollback of the [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931) so we will use the proper surface data for the window.
>  * Return conversion in the xrender pipeline removed by the [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) So we will convert it when we render to the volatile image(argbPre) and to the window(argb). We need to convert in both cases since the xrender API which we use expects the argbPre colors.
>  * Start to use the [eargb](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1752) value( instead of pixel) stored in the SunGraphics2D so we did not get the double conversion.
> 
> Some tests are updated and one more is added.
> 
> ### Note
> I have checked the performance implication of this change and it looks like after this change the sequence window.setvisible(true)/window.dispose() will work 30% faster, this may affect the tests which does not wait enough time to make the window visible. Probably this is the reason why some of our tests became more stable at some point in jdk11.
> 
> 
> I have tested this by the jck and jdk_desktop tests. But any additional verification/testing is welcome.

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

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

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6199/files
  - new: https://git.openjdk.java.net/jdk/pull/6199/files/cac8aa81..c2d3db39

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

  Stats: 207 lines in 47 files changed: 87 ins; 45 del; 75 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6199.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6199/head:pull/6199

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


From psadhukhan at openjdk.java.net  Tue Dec 14 17:10:08 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 14 Dec 2021 17:10:08 GMT
Subject: RFR: 8277463: JFileChooser with Metal L&F doesn't show
 non-canonical UNC path in - Look in
In-Reply-To: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
References: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
Message-ID: <Ce_-gZ04jc7WLeHIZoRkLcFTikEipJLV3gc5lqnyRBw=.2406ab11-a3a3-4ca4-b6d7-e5e3b069cd8d@github.com>

On Fri, 10 Dec 2021 08:59:55 GMT, Masanori Yano <myano at openjdk.org> wrote:

> I would like to fix the bug reported in JDK-8277463.
> 
> As reporter's investigation, ShellFolder.getNormalizedFile() returns incorrect value for non-canonical Windows UNC path. getNormalizedFile() is used for symbolic link path, but Windows environment does not handle symbolic link. And, getCanonicalFile() returns correct path for a directory link in Windows which is made with `mklink` command. So getNormalizedFile() should perform to return getCanonicalFile() like WindowsFileChooserUI.addItem() at Windows environment.

looks ok

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

Marked as reviewed by psadhukhan (Reviewer).

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


From serb at openjdk.java.net  Tue Dec 14 18:06:58 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 14 Dec 2021 18:06:58 GMT
Subject: Integrated: 8275843: Random crashes while the UI code is executed
In-Reply-To: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
References: <yze385AVOXaNJ6wm_K0KrNQz6exzTzLJ1PCcgDI106M=.30dfc804-5c84-4202-88ca-e933f1b536a5@github.com>
Message-ID: <J3--1VkhqWO6N9EyotYgcJ8gbgxpECceEGDY61nNvzM=.234c4bab-45e9-4a0a-a316-42bda996aaa3@github.com>

On Mon, 1 Nov 2021 20:03:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please take a look to one more wagon in this train:
> [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795)->[JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931)->[JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579)->[JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392)->[Current issue](https://bugs.openjdk.java.net/browse/JDK-8275843). 
> 
> #### The short description:
> 
> We have an inconsistent between xrender java code and the x11 window. The java code thinks that all our windows support only two types of color models: IntRgbX11 and IntArgbPreX11, but the x11 window supports more types. If such inconsistency occurs we render some garbage, or just crash since our "blits" will assume the wrong data layout. This issue was reported and fixed [before](http://hg.openjdk.java.net/jdk/jdk/rev/c53905e7dc57) but it was not realized why the rendering was wrong and that it can cause a crash. The fix is similar to the old one.
> 
> #### The long description:
> 
>  * Once upon a time this bug was filed [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) it was about the rendering of colors to the volatile image, the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8176795?focusedCommentId=14138323&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14138323) In short: the volatile images in the xrender use intArgbPre color model, it means that the SunGraphics2D object [convert](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1753) the argb value to the argbPre before passing it to the pipeline, and the xrender pipeline [convert](http://hg.openjdk.java.net/jdk/jdk/rev/e4b03365ddbf) this value to the argbPre one more time -> double-conversion-> the bug is reproduced. The fix for that bug disabled the second conversion in the xrender. but it does not take into account that this code path is u
 sed for rendering to the ARGB X11 window where the shared code does not convert the color, so the next bug was filed.
>  * The second bug is [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931), the description can be found [here](https://bugs.openjdk.java.net/browse/JDK-8204931?focusedCommentId=14199800&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14199800). In short the bug was about rendering directly to the window and missing color conversion removed previously. The fix for that bug changed the surface type used by the window, so the shared code start to convert the color from ARGB to argbPre, but it does not take into account that we do not control the color model of the window, see how many of them we actually [support](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceData.java#L501) Also note in the link above that if we do not recognize the type we do not fallback to something but throw InvalidPipeException, this is because the blits(and other primitives) may use t
 his type to access the data directly. So the next bug was reported:
>  * This is the third issue [JDK-8214579](https://bugs.openjdk.java.net/browse/JDK-8214579). The fix for that issue tried to roll back the previous one but does not take into account that the conversion removed by the first issue should be rollback as well, so the last bug was filed.
>  * The "last" issue is [JDK-8227392](https://bugs.openjdk.java.net/browse/JDK-8227392) rollback the previous one. So the bug reported in the third report come back.
> 
> #### Fix description
> 
> The fix for the current issue contains a few parts:
>  * Rollback of the [JDK-8204931](https://bugs.openjdk.java.net/browse/JDK-8204931) so we will use the proper surface data for the window.
>  * Return conversion in the xrender pipeline removed by the [JDK-8176795](https://bugs.openjdk.java.net/browse/JDK-8176795) So we will convert it when we render to the volatile image(argbPre) and to the window(argb). We need to convert in both cases since the xrender API which we use expects the argbPre colors.
>  * Start to use the [eargb](https://github.com/openjdk/jdk/blob/603bba282a089928fd23f8da23a7c1b2d52944ef/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1752) value( instead of pixel) stored in the SunGraphics2D so we did not get the double conversion.
> 
> Some tests are updated and one more is added.
> 
> ### Note
> I have checked the performance implication of this change and it looks like after this change the sequence window.setvisible(true)/window.dispose() will work 30% faster, this may affect the tests which does not wait enough time to make the window visible. Probably this is the reason why some of our tests became more stable at some point in jdk11.
> 
> 
> I have tested this by the jck and jdk_desktop tests. But any additional verification/testing is welcome.

This pull request has now been integrated.

Changeset: a9c1acbb
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a9c1acbb8aec46e4a488b7c77bb6318af87747f6
Stats:     141 lines in 6 files changed: 91 ins; 19 del; 31 mod

8275843: Random crashes while the UI code is executed

Reviewed-by: azvegint

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

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


From serb at openjdk.java.net  Wed Dec 15 00:46:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Dec 2021 00:46:57 GMT
Subject: RFR: 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java
 fails in macos12
In-Reply-To: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
References: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
Message-ID: <D8g4MJYcvR1SaaeEZvo9nrvRD1kd-cymtyFeLv3S9mA=.e429c30b-a98c-4a2a-8ed7-2b6cdcf3b86a@github.com>

On Tue, 14 Dec 2021 05:44:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seem to be failing in macos12.0.1 (although it does not seem to affect 12.1) due to keypresses of "a", "a", "d" is not selecting "aad" but "ade" which seems to point to the fact that 2 exclusive "a" keypress are considered as 1 "a" keypress.
> Although I am not able to reroduce this issue if test is ran standalone or in JTree group, but it fails when ran as toplevel "jdk_desktop" testgroup or even whole swing test group.
> 
> Looking at text navigational algorithm probably done in JDK-4908142 (although I am not sure if this is done for that bug or subsequently revised) 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3804
> 
> it seems if a subsequent key press comes after a predefined timefactor after the previous keypress, it is considered as a fresh/new keypress and not part of ongoing string search ie, if 2nd "a" comes after the predefined timefactor from 1st "a', then seacrh algorithm will search for "ad" and not "aad" as can be seen here
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3815
> 
> I am not sure why macos12 will take so long  for 2nd "a" keypress  but the logs corraborates that it does take more than "timefactor" time what is set now, which is 1000.
> 1st "a" keypress, we have time 1639400688049 lastTime 0 typedString a
> 2nd "a" keypress, we have time 1639400691150 lastTime 1639400688049 typedString a [which is diff of 3101]
> 
> So, proposed fix is to configure "Tree.timeFactor" to 5000 to workaround this macos12 issue. It pass when full desktop tests is run in macos12 and also test passes in all platforms.

Can you please check that the slowness was caused by the receiving events from the cocoa, and not by the posting delayed(for some reason) events by the robot.

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

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


From serb at openjdk.java.net  Wed Dec 15 01:15:59 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Dec 2021 01:15:59 GMT
Subject: RFR: 8278050: Armenian text isn't rendered on macOS if text layout
 is performed
In-Reply-To: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
References: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
Message-ID: <FwIjsE0K2xcvCUHoLg2P-lCcZzumYhYK3q7DIwR4oXM=.21785b5d-2ee8-4d7f-8047-7e4bfc7feac9@github.com>

On Wed, 1 Dec 2021 10:52:38 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The problem is related to the implementation of font fallback on macOS, specifically to the path used when text layout
> is performed, i.e. the one using `FontSubstitution` and cascade lists. `CTFontCopyDefaultCascadeListForLanguages`'s output contains an entry for the font, able to render Armenian text ('NotoSansArmenian-Regular'), but `CFont.createCompositeFont` cannot find this font amongst registered fonts, and the entry is skipped, resulting in broken rendering.
> System font loading (performed by `CFontManager.loadNativeFonts`) relies on `[NSFontManager availableFontFamilies]`, but its output doesn't contain 'Noto Sans Armenian' (which is a family for 'NotoSansArmenian-Regular' font). 'Noto Sans Armenian' is recognized by `[NSFontManager availableMembersOfFontFamily:]` though, 'NotoSansArmenian-Regular' is contained in `[NSFontManager availableFonts]` output, and the font can be created and used normally, just like any other system font. Not sure why its family is 'hidden', maybe macOS developers wanted to limit the number of options
> displayed in font selection drop-downs.
> For reference, another cascade list item, ignored in similar way is 'NotoSansZawgyi-Regular'.
> 
> Proposed fix is to create `CFont` objects for cascade list items explicitly, if corresponding fonts are not registered. These objects are re-used between different fonts as their fallback components (to enable caching of char-to-glyph mapping), but are not made available to public font APIs.
> I've considered an alternative solution - using `[NSFontManager availableFonts]` instead of
> `[NSFontManager availableFontFamilies]` to load system fonts. Two factors complicate it though - `loadNativeFonts` will
> take more time (on my machine about 170 additional fonts will be loaded) and the order of font loading will change (which
> impacts the selection of 'preferred' plain/bold/italic/bolditalic components in `FontFamily` class). Both factors can be
> dealt with, but they make the solution more complicated and prone to regressions. For now, it seems not worth it.
> 
> I've not created a test, as it would rely on macOS providing a fallback font for Armenian script, which is not guaranteed.
> Existing tests pass fine with the fix.

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

> 335:             // These fonts are present in [NSFontManager availableFonts] output though,
> 336:             // and can be accessed in the same way as other system fonts.
> 337:             return fallbackFonts.computeIfAbsent(fontName, name -> new CFont(name, null));

I would like to clarify why we cannot merge the results of the availableFontFamilies and availableFonts?

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

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


From serb at openjdk.java.net  Wed Dec 15 01:23:59 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Dec 2021 01:23:59 GMT
Subject: RFR: 6496103: isFileHidingEnabled return false by default
In-Reply-To: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
Message-ID: <DlQfnWg4qy-uqBlxHv3D6ekLCNYGc8Ua13vRCvA5LJk=.5ad1984d-979b-46f0-bd90-e2c387c79844@github.com>

On Thu, 9 Dec 2021 09:40:38 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> The default value of this property is derived from native platform. The same is updated in the documentation.

src/java.desktop/share/classes/javax/swing/JFileChooser.java line 1416:

> 1414:      * Returns true if hidden files are not shown in the file chooser;
> 1415:      * otherwise, returns false. The default value of this property is derived from native platform,
> 1416:      * unless set explicitly by the developer.

Looks like the rest of the file uses the terms "by the programmer" and "This default depends on the operating system.",
also please split the long line up to 80 chars.

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

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


From serb at openjdk.java.net  Wed Dec 15 01:40:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Dec 2021 01:40:01 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <uHq1u2ACe0f76QG6LmzL46aajn0wo2ox2EsogAW5LYI=.4c5fd99f-46ba-4e47-8609-50a34cf3f2b1@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>
 <_yyT1DE1iec1ea6SsjCE-wT6fBrkBrws9Co61mbukNs=.572220ae-c3a4-4363-864a-bcfcc51c0e73@github.com>
 <uHq1u2ACe0f76QG6LmzL46aajn0wo2ox2EsogAW5LYI=.4c5fd99f-46ba-4e47-8609-50a34cf3f2b1@github.com>
Message-ID: <P-6pif9tfiiMosYNFbAc28c4CbsvbJfqnjenCFyP2Zw=.3d79147e-5f4b-49f9-9008-bdb3e8635156@github.com>

On Wed, 8 Dec 2021 13:09:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I'm not sure this fix is going in the right direction. Isn't the doc saying that if you want to use one of these components as the cell of a JTable it should implement this interface ?
>> And the problem with JListBox is that it is actually just called JList ?
>
> @prrace Shall we update `TableCellEditor` Javadoc to _?Adds to CellEditor the extensions necessary to configure an editor in a table.?_ to make it similar to `TreeCellEditor`?

Isn't this is another way around? The doc says that the object implementing this interface can be used "as an editor of values for components such as XXX", and it does not say that the XXX class should support the CellTableEditor? 
For example, the DefaultCellEditor class can be used as an editor for JComboBox/JCheckBox/JTextField.

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

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


From serb at openjdk.java.net  Wed Dec 15 01:49:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Dec 2021 01:49:09 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v10]
In-Reply-To: <x0aZE_h6CChWCUKMakeMx5V-sVyI42MOSw2tqJu6gKo=.759b3ef4-be37-43e2-a04b-00bfd16f6bec@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <x0aZE_h6CChWCUKMakeMx5V-sVyI42MOSw2tqJu6gKo=.759b3ef4-be37-43e2-a04b-00bfd16f6bec@github.com>
Message-ID: <nwcfFzj8_CEynsnUEb-KHxAMn-NYAWz6DL1d_pUTEqQ=.9ae5a7e6-9474-4185-9f83-48c3773abfad@github.com>

On Wed, 8 Dec 2021 20:52:42 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed todo comment

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 40:

> 38:  * @run main ScrollBarBorderTest
> 39:  */
> 40: public class ScrollBarBorderTest {

The test does not have a platform limitation, does it mean it works fine and can catch similar bugs for other L&Fs? If yes it would be useful to iterate all installed L&F. You can take a look an example in the ButtonGroupLayoutTraversalTest test.

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 140:

> 138:         }
> 139:     }
> 140: }

A newline at the end of the file should be added.

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

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


From duke at openjdk.java.net  Wed Dec 15 02:29:15 2021
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 15 Dec 2021 02:29:15 GMT
Subject: RFR: 8278828 : java/awt/a11y/AccessibleTextTest.java's
 createTextArea() just shows instructions on the UI
Message-ID: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>

1) Test scenario was just showing test instruction with JTextArea. So added the JTextArea as the instruction and method says. 
2) JTextArea is filled with contents so that and an Emoji character making sure that screen reader can read Emoji also.
3) Now user can user arrow keys to navigate the JTextArea and screen reader can read it.

@shurymury 

Attached the screen shot of the test UI which contains JTextArea along with the instruction.
<img width="623" alt="Screen Shot 2021-12-14 at 7 09 14 PM" src="https://user-images.githubusercontent.com/87324768/146111187-29f81aab-a138-442d-90bd-df24d512fe01.png">

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

Commit messages:
 - Added JTextArea createTextArea() in AccessibleTextTest.java

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

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


From duke at openjdk.java.net  Wed Dec 15 05:36:01 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 15 Dec 2021 05:36:01 GMT
Subject: RFR: 6462028: MaskFormatter API documentation refers to
 getDisplayValue [v5]
In-Reply-To: <U2zUT6bIQ0DmXmFwLW-uVwpIxTTAIBroOstyjhqgNRI=.ed46dc9c-207f-46a1-982c-c45baac39f1f@github.com>
References: <-SOfUt64IAtAG0_rLAwkmMCCd81ZaPuTuF5ORNYuIOs=.fd151cd5-71c7-4e21-bd62-aeec7d296e76@github.com>
 <62NcR6AEhkTmMH9YnM_KnoK_quyX1RlSC6nFc-dyg4U=.c078dcec-9805-4004-9d34-6eb4ae1635c7@github.com>
 <U2zUT6bIQ0DmXmFwLW-uVwpIxTTAIBroOstyjhqgNRI=.ed46dc9c-207f-46a1-982c-c45baac39f1f@github.com>
Message-ID: <tymCLSXOIANmEQ03BEqhM0KQVeGVyVHP0NHush-IqE4=.e758f020-89b0-4820-ae78-cc4e07add7a2@github.com>

On Mon, 6 Dec 2021 17:16:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/MaskFormatter.java line 103:
>> 
>>> 101:  *   MaskFormatter formatter = new MaskFormatter("###-####");
>>> 102:  *   formatter.setPlaceholderCharacter('_');
>>> 103:  *   formatter.getDisplayValue(tf, "123");
>> 
>> This code is part of an example, without this line, the following lines of documentation do not make sense. Probably, `getDisplayValue` should be replaced with `valueToString`. You should check that and ensure the sample and the expected output, as discussed in the following sentences, is correct.
>
> I agree. Simply deleting this line solves nothing. The example needs to be reviewed and the text needs to say something correct and useful.

@prrace The PR has been reviewed and approved by @prsadhuk and @aivanov-jdk...... Can I go ahead and integrate it?

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

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


From duke at openjdk.java.net  Wed Dec 15 06:29:43 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 15 Dec 2021 06:29:43 GMT
Subject: RFR: 6496103: isFileHidingEnabled return false by default [v2]
In-Reply-To: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
Message-ID: <6ZrzvASjvTYEe1dazchVcggakWgIN_6-SFxCyHJdl58=.fc97f95f-6ba2-476c-835b-0850b533d5bb@github.com>

> The default value of this property is derived from native platform. The same is updated in the documentation.

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

  6496103: isFileHidingEnabled return false by default

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6780/files
  - new: https://git.openjdk.java.net/jdk/pull/6780/files/d05f425b..f173600e

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

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

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


From duke at openjdk.java.net  Wed Dec 15 06:29:46 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 15 Dec 2021 06:29:46 GMT
Subject: RFR: 6496103: isFileHidingEnabled return false by default [v2]
In-Reply-To: <DlQfnWg4qy-uqBlxHv3D6ekLCNYGc8Ua13vRCvA5LJk=.5ad1984d-979b-46f0-bd90-e2c387c79844@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
 <DlQfnWg4qy-uqBlxHv3D6ekLCNYGc8Ua13vRCvA5LJk=.5ad1984d-979b-46f0-bd90-e2c387c79844@github.com>
Message-ID: <_1B7etqqNdNJ3-ko8rVwgxn8q8X6aGdY_d3rSTJSDOI=.76a14d6c-db9d-487d-98c0-869ced810842@github.com>

On Wed, 15 Dec 2021 01:20:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6496103: isFileHidingEnabled return false by default
>
> src/java.desktop/share/classes/javax/swing/JFileChooser.java line 1416:
> 
>> 1414:      * Returns true if hidden files are not shown in the file chooser;
>> 1415:      * otherwise, returns false. The default value of this property is derived from native platform,
>> 1416:      * unless set explicitly by the developer.
> 
> Looks like the rest of the file uses the terms "by the programmer" and "This default depends on the operating system.",
> also please split the long line up to 80 chars.

Sure @mrserb , updated the PR.

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

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


From dbatrak at openjdk.java.net  Wed Dec 15 08:52:00 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Wed, 15 Dec 2021 08:52:00 GMT
Subject: RFR: 8278050: Armenian text isn't rendered on macOS if text layout
 is performed
In-Reply-To: <FwIjsE0K2xcvCUHoLg2P-lCcZzumYhYK3q7DIwR4oXM=.21785b5d-2ee8-4d7f-8047-7e4bfc7feac9@github.com>
References: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
 <FwIjsE0K2xcvCUHoLg2P-lCcZzumYhYK3q7DIwR4oXM=.21785b5d-2ee8-4d7f-8047-7e4bfc7feac9@github.com>
Message-ID: <mog38DarYTIQF7-X8Ou4MUCYefOYT8xkiGnBP-qA2zA=.24e2c771-c2f6-45bf-a631-1fdf6dfe77d6@github.com>

On Wed, 15 Dec 2021 01:13:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I would like to clarify why we cannot merge the results of the availableFontFamilies and availableFonts?

We can do it, if everyone is OK with increasing the scope of the change, due to the following factors:
* The number of fonts advertised via `GraphicsEnvironment.getAllFonts` and `GraphicsEnvironment.getAvailableFontFamilyNames` will increase, so a potential Java application showing a font chooser combo-box will display more fonts there, than a native macOS application. Not sure whether that's a good or a bad thing, but that's a change in behaviour that will occur.
* As the number of loaded fonts will increase, the execution time of `CFontManager.loadNativeFonts` will also increase, introducing a certain regression in Java UI application startup time. Ideally, this should be fixed simultaneously, e.g. by adjusting `sun.font.FontFamily` logic to perform style resolution lazily (when the particular family is accessed), not at the time `loadNativeFonts` is executed.
* `[NSFontManager availableFonts]` returns the fonts in alphabetical order, while `NSFontManager availableMembersOfFontFamily:]` (used currently) uses font weight to sort the results. The order in which fonts are processed during `loadNativeFonts` impacts the resulting resolution of fonts into styles in `FontFamily`. So, to keep the currently used approach, an additional fonts sorting would need to be introduced - that can be done, e.g. as part of lazy resolution in `FontFamily` mentioned above.

Even though it can make sense to implement all of the above (which JetBrains Runtime already does), I'd rather not do everything in one go. For now, what I'd like to achieve is to switch to `CTFontCopyDefaultCascadeListForLanguages`-based font fallback, as mentioned above. And current change, while having a value of its own, is a necessary step towards that.
If OpenJDK will ever switch to using `[NSFontManager availableFonts]`, as a sole source of system fonts or in addition to `[NSFontManager availableFontFamilies]`, this change can just be reverted.

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

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


From asemenov at openjdk.java.net  Wed Dec 15 12:57:22 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Wed, 15 Dec 2021 12:57:22 GMT
Subject: [jdk18] RFR: 8278604 SwingSet2 table demo does not have accessible
 description set for images
Message-ID: <MpzD5J0C_EuymSeZVLorPymbQH3QJe9LWmXVykE7_Bs=.8b1fdb8e-c3ab-4ed4-936e-0ae660742cf7@github.com>

SwingSet2 demo is often used to check accessibility for different Swing components and has some shortcomings. The major one is that images within the table demo do not have accessible description set which makes accessibility perform differently on different platforms when navigating the table with screen narrator enabled.

This is the next step after the solution [JDK-8277497](https://bugs.openjdk.java.net/browse/JDK-8277497), in which we forwarded the description from the icon into the label description so that this fix was possible.

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

Commit messages:
 - 8278604 SwingSet2 table demo does not have accessible description set for images

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

PR: https://git.openjdk.java.net/jdk18/pull/31


From ant at openjdk.java.net  Wed Dec 15 13:28:00 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Wed, 15 Dec 2021 13:28:00 GMT
Subject: [jdk18] RFR: 8278604 SwingSet2 table demo does not have accessible
 description set for images
In-Reply-To: <MpzD5J0C_EuymSeZVLorPymbQH3QJe9LWmXVykE7_Bs=.8b1fdb8e-c3ab-4ed4-936e-0ae660742cf7@github.com>
References: <MpzD5J0C_EuymSeZVLorPymbQH3QJe9LWmXVykE7_Bs=.8b1fdb8e-c3ab-4ed4-936e-0ae660742cf7@github.com>
Message-ID: <Lyzvep8gxUVfXgtv9eMFTjSRAxr-px2sD47R59Yqmtg=.a1b1c4d2-8c40-4ec9-90e4-27b506d52852@github.com>

On Wed, 15 Dec 2021 12:43:40 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> SwingSet2 demo is often used to check accessibility for different Swing components and has some shortcomings. The major one is that images within the table demo do not have accessible description set which makes accessibility perform differently on different platforms when navigating the table with screen narrator enabled.
> 
> This is the next step after the solution [JDK-8277497](https://bugs.openjdk.java.net/browse/JDK-8277497), in which we forwarded the description from the icon into the label description so that this fix was possible.

Marked as reviewed by ant (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/31


From vdyakov at openjdk.java.net  Wed Dec 15 16:37:59 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Wed, 15 Dec 2021 16:37:59 GMT
Subject: RFR: 8278612: test/jdk/java/awt/dnd/RemoveDropTargetCrashTest
 crashes with VoiceOver on macOS
In-Reply-To: <XVBgpRNivpgbQ1wkWRKwyu3_dmyZIYAsVNemrF_pKMw=.58f6869b-d7a0-488d-9eb7-9f17516974c0@github.com>
References: <XVBgpRNivpgbQ1wkWRKwyu3_dmyZIYAsVNemrF_pKMw=.58f6869b-d7a0-488d-9eb7-9f17516974c0@github.com>
Message-ID: <pG6h75uiWR8sSm5RSbixTlenaGfGfe9qmeNVV6kyK9Y=.3253e52f-dad8-4367-8d7a-07c7de435904@github.com>

On Mon, 13 Dec 2021 16:50:00 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> ? VoiceOver on macOS

@forantar  please re-submit at 18 forked

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

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


From aivanov at openjdk.java.net  Wed Dec 15 16:49:01 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 15 Dec 2021 16:49:01 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <P-6pif9tfiiMosYNFbAc28c4CbsvbJfqnjenCFyP2Zw=.3d79147e-5f4b-49f9-9008-bdb3e8635156@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>
 <_yyT1DE1iec1ea6SsjCE-wT6fBrkBrws9Co61mbukNs=.572220ae-c3a4-4363-864a-bcfcc51c0e73@github.com>
 <uHq1u2ACe0f76QG6LmzL46aajn0wo2ox2EsogAW5LYI=.4c5fd99f-46ba-4e47-8609-50a34cf3f2b1@github.com>
 <P-6pif9tfiiMosYNFbAc28c4CbsvbJfqnjenCFyP2Zw=.3d79147e-5f4b-49f9-9008-bdb3e8635156@github.com>
Message-ID: <tos3Ywq_UcdsQhS7zEfbfYDNRm6XHCZcMow8zofnay4=.ef0f5ef8-1326-4c50-9dd9-7c606ee75977@github.com>

On Wed, 15 Dec 2021 01:36:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @prrace Shall we update `TableCellEditor` Javadoc to _?Adds to CellEditor the extensions necessary to configure an editor in a table.?_ to make it similar to `TreeCellEditor`?
>
> Isn't this is another way around? The doc says that the object implementing this interface can be used "as an editor of values for components such as XXX", and it does not say that the XXX class should support the CellTableEditor? 
> For example, the DefaultCellEditor class can be used as an editor for JComboBox/JCheckBox/JTextField.

Hm? It's not the other way around. `DefaultCellEditor` implements `TableCellEditor`; the interface defines the `getTableCellEditorComponent` method that returns the _real component_ which will be used as the value editor.

So yeah, you're absolutely right: the current statement in the doc seems wrong.

I'm for changing the Javadoc for `TableCellEditor` to be similar to `TreeCellEditor`: _?Adds to CellEditor the extensions necessary to configure an editor in a table.?_

The object that implements the interface is not necessarily the editor for values. `DefaultCellEditor`  is the perfect example: it's not an editor itself, it's not even a component, all it does is configures a delegate, a `JComponent`, which serves as the editor.

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

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


From psadhukhan at openjdk.java.net  Wed Dec 15 17:38:58 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 15 Dec 2021 17:38:58 GMT
Subject: RFR: 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java
 fails in macos12
In-Reply-To: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
References: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
Message-ID: <tU9vLViOZ4MVEmy6lnVgCTjQ6_dFQdpZ0lclzOa8ih8=.a9046cb4-312f-4fcf-9773-29d7dae551c7@github.com>

On Tue, 14 Dec 2021 05:44:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seem to be failing in macos12.0.1 (although it does not seem to affect 12.1) due to keypresses of "a", "a", "d" is not selecting "aad" but "ade" which seems to point to the fact that 2 exclusive "a" keypress are considered as 1 "a" keypress.
> Although I am not able to reroduce this issue if test is ran standalone or in JTree group, but it fails when ran as toplevel "jdk_desktop" testgroup or even whole swing test group.
> 
> Looking at text navigational algorithm probably done in JDK-4908142 (although I am not sure if this is done for that bug or subsequently revised) 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3804
> 
> it seems if a subsequent key press comes after a predefined timefactor after the previous keypress, it is considered as a fresh/new keypress and not part of ongoing string search ie, if 2nd "a" comes after the predefined timefactor from 1st "a', then seacrh algorithm will search for "ad" and not "aad" as can be seen here
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3815
> 
> I am not sure why macos12 will take so long  for 2nd "a" keypress  but the logs corraborates that it does take more than "timefactor" time what is set now, which is 1000.
> 1st "a" keypress, we have time 1639400688049 lastTime 0 typedString a
> 2nd "a" keypress, we have time 1639400691150 lastTime 1639400688049 typedString a [which is diff of 3101]
> 
> So, proposed fix is to configure "Tree.timeFactor" to 5000 to workaround this macos12 issue. It pass when full desktop tests is run in macos12 and also test passes in all platforms.

As per the logs I have put in CRobot.m#Java_sun_lwawt_macosx_CRobot_keyEvent
we get
1st "a" keypress, 
2021-12-15 17:27:30.721 java[3040:167835] java keyCode 41
2021-12-15 17:27:30.721 java[3040:167835]  Before autoDelay CFAbsoluteTimeGetCurrent 661282050.721198

2nd "a" keypress
2021-12-15 17:27:33.865 java[3040:167835] java keyCode 41
2021-12-15 17:27:33.865 java[3040:167835]  Before autoDelay CFAbsoluteTimeGetCurrent 661282053.865368 ==> difference of 3.144

"d" keypress
2021-12-15 17:27:33.994 java[3040:167835] java keyCode 44
2021-12-15 17:27:33.994 java[3040:167835]  Before autoDelay CFAbsoluteTimeGetCurrent 661282053.994263 ==> difference of 0.128

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

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


From duke at openjdk.java.net  Wed Dec 15 18:03:02 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 15 Dec 2021 18:03:02 GMT
Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules
In-Reply-To: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>
References: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>
Message-ID: <K6LyifyATyq3y-tdw1S7KoyDBTmSz8t9nwNmOQb4qSU=.7b03a9d0-940c-4c2a-b24a-2d272a41227f@github.com>

On Thu, 9 Sep 2021 06:53:13 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance

> @turbanoff Only [Committers](https://openjdk.java.net/bylaws#committer) are allowed to sponsor changes.

But I am a Committer ?

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

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


From duke at openjdk.java.net  Wed Dec 15 19:32:04 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 15 Dec 2021 19:32:04 GMT
Subject: Integrated: 8274898: Cleanup usages of StringBuffer in jdk tools
 modules
In-Reply-To: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>
References: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>
Message-ID: <RBc_1YCOIXdTz9hQo1mggxUItgrO5zMw4y9cxYUZrQ8=.09adb717-3c57-4c6d-bef5-d22c6fb28ae4@github.com>

On Thu, 9 Sep 2021 06:53:13 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance

This pull request has now been integrated.

Changeset: 04dbdd36
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/04dbdd36dd04bf40737cb8c2f13d5b75303d2b1a
Stats:     8 lines in 3 files changed: 0 ins; 0 del; 8 mod

8274898: Cleanup usages of StringBuffer in jdk tools modules

Reviewed-by: sspitsyn, lmesnik

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

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


From dholmes at openjdk.java.net  Wed Dec 15 21:41:02 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Dec 2021 21:41:02 GMT
Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules
In-Reply-To: <K6LyifyATyq3y-tdw1S7KoyDBTmSz8t9nwNmOQb4qSU=.7b03a9d0-940c-4c2a-b24a-2d272a41227f@github.com>
References: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>
 <K6LyifyATyq3y-tdw1S7KoyDBTmSz8t9nwNmOQb4qSU=.7b03a9d0-940c-4c2a-b24a-2d272a41227f@github.com>
Message-ID: <Z_oYNVyeeXWF38fOwVr4vxbES3KMaFk53RpQT6P6tSo=.4ec42852-810f-4ff0-bfb8-1bfbcaf106be@github.com>

On Wed, 15 Dec 2021 17:59:54 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> > @turbanoff Only [Committers](https://openjdk.java.net/bylaws#committer) are allowed to sponsor changes.
> 
> But I am a Committer ?

You can't "sponsor" your own change. I suspect your Committer status changed after the bot initially checked your status way back in September. Not sure how often the bot will recheck that.

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

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


From serb at openjdk.java.net  Wed Dec 15 23:02:02 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Dec 2021 23:02:02 GMT
Subject: RFR: 8277463: JFileChooser with Metal L&F doesn't show
 non-canonical UNC path in - Look in
In-Reply-To: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
References: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
Message-ID: <1APEWt6EfSMXZSLa9JNxgLwQpdtfpOBE1VBgXCUntxM=.83285e41-fd61-452d-b3bf-7da6ce4f432b@github.com>

On Fri, 10 Dec 2021 08:59:55 GMT, Masanori Yano <myano at openjdk.org> wrote:

> I would like to fix the bug reported in JDK-8277463.
> 
> As reporter's investigation, ShellFolder.getNormalizedFile() returns incorrect value for non-canonical Windows UNC path. getNormalizedFile() is used for symbolic link path, but Windows environment does not handle symbolic link. And, getCanonicalFile() returns correct path for a directory link in Windows which is made with `mklink` command. So getNormalizedFile() should perform to return getCanonicalFile() like WindowsFileChooserUI.addItem() at Windows environment.

src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java line 301:

> 299:         if (f.equals(canonical) || OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
> 300:             // path of f doesn't contain symbolic links
> 301:             return canonical;

Is it possible that the code below was used when the "Libraries"  or some "virtual folders" were navigated?

test/jdk/javax/swing/JFileChooser/8277463/UNCFileChooserTest.java line 105:

> 103:             throw new RuntimeException("Enter the directory path to test.");
> 104:         }
> 105:         UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");

The test might be executed under some non-default L&F and switching it here might cause some issues for the instruction dialog which will not be updated to use the metal. So it is better to set metal at the start of the test.

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

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


From serb at openjdk.java.net  Wed Dec 15 23:06:58 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Dec 2021 23:06:58 GMT
Subject: RFR: 8278828 : java/awt/a11y/AccessibleTextTest.java's
 createTextArea() just shows instructions on the UI
In-Reply-To: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
References: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
Message-ID: <T6iTk8IErVEarUbvEDHT38BIjnntGVv7vJGrwhD79Fg=.1971a058-a79f-45bf-bc8c-43c19c7fa83e@github.com>

On Wed, 15 Dec 2021 02:21:35 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> 1) Test scenario was just showing test instruction with JTextArea. So added the JTextArea as the instruction and method says. 
> 2) JTextArea is filled with contents so that and an Emoji character making sure that screen reader can read Emoji also.
> 3) Now user can user arrow keys to navigate the JTextArea and screen reader can read it.
> 
> @shurymury 
> 
> Attached the screen shot of the test UI which contains JTextArea along with the instruction.
> <img width="623" alt="Screen Shot 2021-12-14 at 7 09 14 PM" src="https://user-images.githubusercontent.com/87324768/146111187-29f81aab-a138-442d-90bd-df24d512fe01.png">

@savoptik please take a look.

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

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


From serb at openjdk.java.net  Wed Dec 15 23:10:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Dec 2021 23:10:07 GMT
Subject: RFR: 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java
 fails in macos12
In-Reply-To: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
References: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
Message-ID: <o7kRL5lyYT3K55fm3Mvu6QjCTrldELjBkoWvzwIypsA=.e5f6dd15-6023-448e-8895-587667b2d4cd@github.com>

On Tue, 14 Dec 2021 05:44:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seem to be failing in macos12.0.1 (although it does not seem to affect 12.1) due to keypresses of "a", "a", "d" is not selecting "aad" but "ade" which seems to point to the fact that 2 exclusive "a" keypress are considered as 1 "a" keypress.
> Although I am not able to reroduce this issue if test is ran standalone or in JTree group, but it fails when ran as toplevel "jdk_desktop" testgroup or even whole swing test group.
> 
> Looking at text navigational algorithm probably done in JDK-4908142 (although I am not sure if this is done for that bug or subsequently revised) 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3804
> 
> it seems if a subsequent key press comes after a predefined timefactor after the previous keypress, it is considered as a fresh/new keypress and not part of ongoing string search ie, if 2nd "a" comes after the predefined timefactor from 1st "a', then seacrh algorithm will search for "ad" and not "aad" as can be seen here
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3815
> 
> I am not sure why macos12 will take so long  for 2nd "a" keypress  but the logs corraborates that it does take more than "timefactor" time what is set now, which is 1000.
> 1st "a" keypress, we have time 1639400688049 lastTime 0 typedString a
> 2nd "a" keypress, we have time 1639400691150 lastTime 1639400688049 typedString a [which is diff of 3101]
> 
> So, proposed fix is to configure "Tree.timeFactor" to 5000 to workaround this macos12 issue. It pass when full desktop tests is run in macos12 and also test passes in all platforms.

Does it mean that 3.144 after the first press is a delay caused by some code in the robot?

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

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


From serb at openjdk.java.net  Wed Dec 15 23:14:59 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Dec 2021 23:14:59 GMT
Subject: RFR: 6496103: isFileHidingEnabled return false by default [v2]
In-Reply-To: <_1B7etqqNdNJ3-ko8rVwgxn8q8X6aGdY_d3rSTJSDOI=.76a14d6c-db9d-487d-98c0-869ced810842@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
 <DlQfnWg4qy-uqBlxHv3D6ekLCNYGc8Ua13vRCvA5LJk=.5ad1984d-979b-46f0-bd90-e2c387c79844@github.com>
 <_1B7etqqNdNJ3-ko8rVwgxn8q8X6aGdY_d3rSTJSDOI=.76a14d6c-db9d-487d-98c0-869ced810842@github.com>
Message-ID: <F3JgWlpvU-tvgZGJ8nvEG0-zXktyRErEhDtVAstWepQ=.4230edfa-c2bc-436d-a86f-57a0b389db86@github.com>

On Wed, 15 Dec 2021 06:25:54 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> src/java.desktop/share/classes/javax/swing/JFileChooser.java line 1416:
>> 
>>> 1414:      * Returns true if hidden files are not shown in the file chooser;
>>> 1415:      * otherwise, returns false. The default value of this property is derived from native platform,
>>> 1416:      * unless set explicitly by the developer.
>> 
>> Looks like the rest of the file uses the terms "by the programmer" and "This default depends on the operating system.",
>> also please split the long line up to 80 chars.
>
> Sure @mrserb , updated the PR.

Not sure the "native" is needed in the new version, any other thoughts from anyone?

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

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


From prr at openjdk.java.net  Wed Dec 15 23:53:06 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 15 Dec 2021 23:53:06 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v10]
In-Reply-To: <W1sc79kkjjEU2gMwVffM-tW9nvdr4hIkRNvWJrkPzXY=.0d9881e6-2761-4fe2-81e3-86abb50fd5ca@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <W1sc79kkjjEU2gMwVffM-tW9nvdr4hIkRNvWJrkPzXY=.0d9881e6-2761-4fe2-81e3-86abb50fd5ca@github.com>
Message-ID: <zpv7BNMCYGS46-g71oPhITHOJkvAOmOe9fOZZD3LGM4=.bb761f9a-e2a8-47d4-b377-56a5c0db45a5@github.com>

On Fri, 19 Nov 2021 19:09:54 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   Addressing code review feedback: "Use BigDecomal.setScale(40) to ascertain precision."
>   
>   The geom.* unit tests passed before & after this change.
>   
>   https://github.com/openjdk/jdk/pull/6227#discussion_r752908494

There seems to be a number of things to discuss aside from the maths

- You are changing the signature of public API
  src/java.desktop/share/classes/java/awt/geom/Path2D.java
public final synchronized Rectangle2D getBounds2D() => public Rectangle2D getBounds2D() {

So no longer final, and no longer synchronized.
This means a CSR is required and we need to think about it .. the intention was that the subclass not over-ride.
And why remove synchronized ? I am fairly sure it was there to make sure no one was mutating the Path whilst
bounds are being calculated.
And you are using getPathIterator(AffineTransform) and the docs for that say it isn't thread safe.
So I think this implementation needs to be thought about very carefully.

- You are adding a new public static method

public static Rectangle2D getBounds2D(final PathIterator pi);

Is this really necessary ? It is just for the benefit of the public API caller so can be package private.

- For me it doesn't build because of a doclint error

src/java.desktop/share/classes/java/awt/geom/Path2D.java:2102: warning: no @param for pi
    public static Rectangle2D getBounds2D(final PathIterator pi) {
                              ^
error: warnings found and -Werror specified

Fixing that I find that the updated UnitTest.java fail with a build with these changes :-

% java UnitTest
Exception in thread "main" java.lang.RuntimeException: the shape must not intersect anything above its bounds
    at UnitTest.testGetBounds2D(UnitTest.java:1396)
    at UnitTest.testBounds(UnitTest.java:1302)
    at UnitTest.test(UnitTest.java:1175)
    at UnitTest.main(UnitTest.java:1435)

Then we have some even more difficult questions.
The control points may not be within the bounds of the curve which is of course the premise of the bug report.
The specification (javadoc) isn't very forthcoming on whether it is allowed to not include them .. ie is it expected they should be ?
And it appears we have JCK tests which expect they ARE included. So as it is this change would not pass the existing TCK/JCK. 
Which means we'd have to be 100% sure about this change in behaviour and be able to justify it.
FWIW unless the spec explicitly says they are, in some place I've overlooked,
then I'd say its a quality-of-implementation thing as to how tight the bounds are, and the new behaviour is allowed by spec.
Applications however might still find this a behaviourally incompatible change .. and could potentially see undesirable consequences -
even as other applications see better consequences.
So perhaps new API that defines tighter bounds  might be  the way to address this .. but I am far from being sure about that.

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

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


From serb at openjdk.java.net  Thu Dec 16 01:27:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 16 Dec 2021 01:27:56 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v9]
In-Reply-To: <fpiUcgPyUu2J1Syutsplkgwu4PUWtk3u1TR0iKyDspE=.88dd3e15-af6f-4821-91db-243ad1f2330f@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <49gYRPX_QAzZcEsFovkzHbBn2I28lXo-3fYDHmYSUD0=.cf6525da-c24b-406f-ad90-2eabcbd840c3@github.com>
 <fpiUcgPyUu2J1Syutsplkgwu4PUWtk3u1TR0iKyDspE=.88dd3e15-af6f-4821-91db-243ad1f2330f@github.com>
Message-ID: <6JyL0M3JjEdq2EBPO49TYQUhLx2wj1yjQE4iO_JeCfI=.45c694ba-8556-4b03-b6a7-d9ff93e14cf0@github.com>

On Mon, 13 Dec 2021 17:54:19 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> I'm happy to update this change to scrap the test if there's agreement that's the best resolution.

I disagree to do that. First, the test is quite important to check the broken serialization form, see the initial bug report. Second, the test proved to be useful since it found two additional bugs.

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

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


From cushon at openjdk.java.net  Thu Dec 16 01:36:59 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Thu, 16 Dec 2021 01:36:59 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v9]
In-Reply-To: <49gYRPX_QAzZcEsFovkzHbBn2I28lXo-3fYDHmYSUD0=.cf6525da-c24b-406f-ad90-2eabcbd840c3@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <49gYRPX_QAzZcEsFovkzHbBn2I28lXo-3fYDHmYSUD0=.cf6525da-c24b-406f-ad90-2eabcbd840c3@github.com>
Message-ID: <WYs3v6SrKIC4CZLJ-GklTDXVdLfN6XBYdamvBDPUNRc=.9e2181c2-b16d-46d9-b39d-4720535274bb@github.com>

On Fri, 10 Dec 2021 17:03:49 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a few more missing calls to LookAndFeel.uninstallColors

Ok!

So is the idea to wait for a separate fix for [JDK-8278620](https://bugs.openjdk.java.net/browse/JDK-8278620), and then update the checked-in serialized objects and re-enable the test?

What do you think of the suggestion to simplify the test to write out the objects and then read them in, without persistent serialization, since there was some discussion about that being explicitly unsupported? I'm still not sure how that would be achieved with the current test, since it relies on modifications to `DragGestureEvent` and `DragGestureRecognize` to serialize the objects?

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

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


From serb at openjdk.java.net  Thu Dec 16 05:20:53 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 16 Dec 2021 05:20:53 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <tos3Ywq_UcdsQhS7zEfbfYDNRm6XHCZcMow8zofnay4=.ef0f5ef8-1326-4c50-9dd9-7c606ee75977@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>
 <_yyT1DE1iec1ea6SsjCE-wT6fBrkBrws9Co61mbukNs=.572220ae-c3a4-4363-864a-bcfcc51c0e73@github.com>
 <uHq1u2ACe0f76QG6LmzL46aajn0wo2ox2EsogAW5LYI=.4c5fd99f-46ba-4e47-8609-50a34cf3f2b1@github.com>
 <P-6pif9tfiiMosYNFbAc28c4CbsvbJfqnjenCFyP2Zw=.3d79147e-5f4b-49f9-9008-bdb3e8635156@github.com>
 <tos3Ywq_UcdsQhS7zEfbfYDNRm6XHCZcMow8zofnay4=.ef0f5ef8-1326-4c50-9dd9-7c606ee75977@github.com>
Message-ID: <tg7Sv5jpg6jWaFIxwJyvw3_NgW361GA0UlQRf1ahB7U=.1e21b0d6-194a-4fb4-b3ff-2a483e2a51fb@github.com>

On Wed, 15 Dec 2021 16:46:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The object that implements the interface is not necessarily the editor for values. DefaultCellEditor is the perfect example: it's not an editor itself, it's not even a component, all it does is configures a delegate, a JComponent, which serves as the editor.

My thoughts about this. The object which implements the interface is always the "editor", even if it is not a component. I guess you are mixing it with the other classes like "JEditorPane/JTextField/etc". 

The current spec:

>This interface defines the method any object that would like to be
an editor of values for components such as <code>JListBox</code>,
<code>JComboBox</code>, <code>JTree</code>, or <code>JTable</code>
needs to implement.

This means that the application may have some values/data stored in the JComboBox/JTree/JTable and the application may create a cell editor by implementing the TableCellEditor. That editor then could be used as a cell editor in the "main" JTable.

So the next statement in the description of this PR is not completely right:
> "CellTableEditor Interface doesn't support JComboBox and JTree components"

The JComboBox and other classes do not have to implement/support that interface.

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

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


From serb at openjdk.java.net  Thu Dec 16 05:38:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 16 Dec 2021 05:38:56 GMT
Subject: RFR: 8278050: Armenian text isn't rendered on macOS if text layout
 is performed
In-Reply-To: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
References: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
Message-ID: <EzlNOU80l8Ng3jyYlJW9LrEtCyLyAD-QVJTxYMaWCPw=.d0ef623a-937d-4159-a433-494a53e7c1fc@github.com>

On Wed, 1 Dec 2021 10:52:38 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The problem is related to the implementation of font fallback on macOS, specifically to the path used when text layout
> is performed, i.e. the one using `FontSubstitution` and cascade lists. `CTFontCopyDefaultCascadeListForLanguages`'s output contains an entry for the font, able to render Armenian text ('NotoSansArmenian-Regular'), but `CFont.createCompositeFont` cannot find this font amongst registered fonts, and the entry is skipped, resulting in broken rendering.
> System font loading (performed by `CFontManager.loadNativeFonts`) relies on `[NSFontManager availableFontFamilies]`, but its output doesn't contain 'Noto Sans Armenian' (which is a family for 'NotoSansArmenian-Regular' font). 'Noto Sans Armenian' is recognized by `[NSFontManager availableMembersOfFontFamily:]` though, 'NotoSansArmenian-Regular' is contained in `[NSFontManager availableFonts]` output, and the font can be created and used normally, just like any other system font. Not sure why its family is 'hidden', maybe macOS developers wanted to limit the number of options
> displayed in font selection drop-downs.
> For reference, another cascade list item, ignored in similar way is 'NotoSansZawgyi-Regular'.
> 
> Proposed fix is to create `CFont` objects for cascade list items explicitly, if corresponding fonts are not registered. These objects are re-used between different fonts as their fallback components (to enable caching of char-to-glyph mapping), but are not made available to public font APIs.
> I've considered an alternative solution - using `[NSFontManager availableFonts]` instead of
> `[NSFontManager availableFontFamilies]` to load system fonts. Two factors complicate it though - `loadNativeFonts` will
> take more time (on my machine about 170 additional fonts will be loaded) and the order of font loading will change (which
> impacts the selection of 'preferred' plain/bold/italic/bolditalic components in `FontFamily` class). Both factors can be
> dealt with, but they make the solution more complicated and prone to regressions. For now, it seems not worth it.
> 
> I've not created a test, as it would rely on macOS providing a fallback font for Armenian script, which is not guaranteed.
> Existing tests pass fine with the fix.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Thu Dec 16 05:38:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 16 Dec 2021 05:38:57 GMT
Subject: RFR: 8278050: Armenian text isn't rendered on macOS if text layout
 is performed
In-Reply-To: <mog38DarYTIQF7-X8Ou4MUCYefOYT8xkiGnBP-qA2zA=.24e2c771-c2f6-45bf-a631-1fdf6dfe77d6@github.com>
References: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
 <FwIjsE0K2xcvCUHoLg2P-lCcZzumYhYK3q7DIwR4oXM=.21785b5d-2ee8-4d7f-8047-7e4bfc7feac9@github.com>
 <mog38DarYTIQF7-X8Ou4MUCYefOYT8xkiGnBP-qA2zA=.24e2c771-c2f6-45bf-a631-1fdf6dfe77d6@github.com>
Message-ID: <AVc7kmSSNLQ4e7z9IVVhgrQ4D_XLvHZmhVAkbvU7Brs=.0d78378d-44c1-430c-be54-1dd13c552e38@github.com>

On Wed, 15 Dec 2021 08:49:04 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/font/CFontManager.java line 337:
>> 
>>> 335:             // These fonts are present in [NSFontManager availableFonts] output though,
>>> 336:             // and can be accessed in the same way as other system fonts.
>>> 337:             return fallbackFonts.computeIfAbsent(fontName, name -> new CFont(name, null));
>> 
>> I would like to clarify why we cannot merge the results of the availableFontFamilies and availableFonts?
>
>> I would like to clarify why we cannot merge the results of the availableFontFamilies and availableFonts?
> 
> We can do it, if everyone is OK with increasing the scope of the change, due to the following factors:
> * The number of fonts advertised via `GraphicsEnvironment.getAllFonts` and `GraphicsEnvironment.getAvailableFontFamilyNames` will increase, so a potential Java application showing a font chooser combo-box will display more fonts there, than a native macOS application. Not sure whether that's a good or a bad thing, but that's a change in behaviour that will occur.
> * As the number of loaded fonts will increase, the execution time of `CFontManager.loadNativeFonts` will also increase, introducing a certain regression in Java UI application startup time. Ideally, this should be fixed simultaneously, e.g. by adjusting `sun.font.FontFamily` logic to perform style resolution lazily (when the particular family is accessed), not at the time `loadNativeFonts` is executed.
> * `[NSFontManager availableFonts]` returns the fonts in alphabetical order, while `NSFontManager availableMembersOfFontFamily:]` (used currently) uses font weight to sort the results. The order in which fonts are processed during `loadNativeFonts` impacts the resulting resolution of fonts into styles in `FontFamily`. So, to keep the currently used approach, an additional fonts sorting would need to be introduced - that can be done, e.g. as part of lazy resolution in `FontFamily` mentioned above.
> 
> Even though it can make sense to implement all of the above (which JetBrains Runtime already does), I'd rather not do everything in one go. For now, what I'd like to achieve is to switch to `CTFontCopyDefaultCascadeListForLanguages`-based font fallback, as mentioned above. And current change, while having a value of its own, is a necessary step towards that.
> If OpenJDK will ever switch to using `[NSFontManager availableFonts]`, as a sole source of system fonts or in addition to `[NSFontManager availableFontFamilies]`, this change can just be reverted.

Ok, let's investigate that possibility separately.

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

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


From duke at openjdk.java.net  Thu Dec 16 06:51:57 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Thu, 16 Dec 2021 06:51:57 GMT
Subject: RFR: 6496103: isFileHidingEnabled return false by default [v2]
In-Reply-To: <F3JgWlpvU-tvgZGJ8nvEG0-zXktyRErEhDtVAstWepQ=.4230edfa-c2bc-436d-a86f-57a0b389db86@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
 <DlQfnWg4qy-uqBlxHv3D6ekLCNYGc8Ua13vRCvA5LJk=.5ad1984d-979b-46f0-bd90-e2c387c79844@github.com>
 <_1B7etqqNdNJ3-ko8rVwgxn8q8X6aGdY_d3rSTJSDOI=.76a14d6c-db9d-487d-98c0-869ced810842@github.com>
 <F3JgWlpvU-tvgZGJ8nvEG0-zXktyRErEhDtVAstWepQ=.4230edfa-c2bc-436d-a86f-57a0b389db86@github.com>
Message-ID: <noAZ_jAFRe1BMBI7bLrBypriNOJFU-aXQ5Tfkg5_G2Y=.842bd618-f257-47e4-94ff-cafeb5284ae7@github.com>

On Wed, 15 Dec 2021 23:11:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Sure @mrserb , updated the PR.
>
> Not sure the "native" is needed in the new version, any other thoughts from anyone?

Yeah, "native OS" and "OS" gives same meaning I guess..

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

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


From dbatrak at openjdk.java.net  Thu Dec 16 07:18:00 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Thu, 16 Dec 2021 07:18:00 GMT
Subject: Integrated: 8278050: Armenian text isn't rendered on macOS if text
 layout is performed
In-Reply-To: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
References: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
Message-ID: <tCuPtxZRytH2mAy-0dIfIkYo4v1_jMWiZ1duNg8jbNc=.b47fe213-5326-450b-b96e-380c9547fd92@github.com>

On Wed, 1 Dec 2021 10:52:38 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The problem is related to the implementation of font fallback on macOS, specifically to the path used when text layout
> is performed, i.e. the one using `FontSubstitution` and cascade lists. `CTFontCopyDefaultCascadeListForLanguages`'s output contains an entry for the font, able to render Armenian text ('NotoSansArmenian-Regular'), but `CFont.createCompositeFont` cannot find this font amongst registered fonts, and the entry is skipped, resulting in broken rendering.
> System font loading (performed by `CFontManager.loadNativeFonts`) relies on `[NSFontManager availableFontFamilies]`, but its output doesn't contain 'Noto Sans Armenian' (which is a family for 'NotoSansArmenian-Regular' font). 'Noto Sans Armenian' is recognized by `[NSFontManager availableMembersOfFontFamily:]` though, 'NotoSansArmenian-Regular' is contained in `[NSFontManager availableFonts]` output, and the font can be created and used normally, just like any other system font. Not sure why its family is 'hidden', maybe macOS developers wanted to limit the number of options
> displayed in font selection drop-downs.
> For reference, another cascade list item, ignored in similar way is 'NotoSansZawgyi-Regular'.
> 
> Proposed fix is to create `CFont` objects for cascade list items explicitly, if corresponding fonts are not registered. These objects are re-used between different fonts as their fallback components (to enable caching of char-to-glyph mapping), but are not made available to public font APIs.
> I've considered an alternative solution - using `[NSFontManager availableFonts]` instead of
> `[NSFontManager availableFontFamilies]` to load system fonts. Two factors complicate it though - `loadNativeFonts` will
> take more time (on my machine about 170 additional fonts will be loaded) and the order of font loading will change (which
> impacts the selection of 'preferred' plain/bold/italic/bolditalic components in `FontFamily` class). Both factors can be
> dealt with, but they make the solution more complicated and prone to regressions. For now, it seems not worth it.
> 
> I've not created a test, as it would rely on macOS providing a fallback font for Armenian script, which is not guaranteed.
> Existing tests pass fine with the fix.

This pull request has now been integrated.

Changeset: 0bddd8af
Author:    Dmitry Batrak <dbatrak at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0bddd8af61b6c731f16b857c09de57ceefd72d06
Stats:     18 lines in 2 files changed: 16 ins; 0 del; 2 mod

8278050: Armenian text isn't rendered on macOS if text layout is performed

Reviewed-by: prr, serb

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

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


From kizune at openjdk.java.net  Thu Dec 16 08:22:05 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 16 Dec 2021 08:22:05 GMT
Subject: [jdk18] RFR: 8278604 SwingSet2 table demo does not have accessible
 description set for images
In-Reply-To: <MpzD5J0C_EuymSeZVLorPymbQH3QJe9LWmXVykE7_Bs=.8b1fdb8e-c3ab-4ed4-936e-0ae660742cf7@github.com>
References: <MpzD5J0C_EuymSeZVLorPymbQH3QJe9LWmXVykE7_Bs=.8b1fdb8e-c3ab-4ed4-936e-0ae660742cf7@github.com>
Message-ID: <3nbz5jwFvbr6sbDJZIc0f6euga6ZXXOFKH5JySBczkU=.041f0b47-b24d-426f-84d2-4f3167631f1d@github.com>

On Wed, 15 Dec 2021 12:43:40 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> SwingSet2 demo is often used to check accessibility for different Swing components and has some shortcomings. The major one is that images within the table demo do not have accessible description set which makes accessibility perform differently on different platforms when navigating the table with screen narrator enabled.
> 
> This is the next step after the solution [JDK-8277497](https://bugs.openjdk.java.net/browse/JDK-8277497), in which we forwarded the description from the icon into the label description so that this fix was possible.

Marked as reviewed by kizune (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/31


From asemenov at openjdk.java.net  Thu Dec 16 08:38:00 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Thu, 16 Dec 2021 08:38:00 GMT
Subject: RFR: 8278828 : java/awt/a11y/AccessibleTextTest.java's
 createTextArea() just shows instructions on the UI
In-Reply-To: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
References: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
Message-ID: <x00FxnlfbrZgvR0Qp0qPulsBoR7EJWqIXs8J6hCLu_I=.738661ef-82a4-426e-a19f-7e27a08e2353@github.com>

On Wed, 15 Dec 2021 02:21:35 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> 1) Test scenario was just showing test instruction with JTextArea. So added the JTextArea as the instruction and method says. 
> 2) JTextArea is filled with contents so that and an Emoji character making sure that screen reader can read Emoji also.
> 3) Now user can user arrow keys to navigate the JTextArea and screen reader can read it.
> 
> @shurymury 
> 
> Attached the screen shot of the test UI which contains JTextArea along with the instruction.
> <img width="623" alt="Screen Shot 2021-12-14 at 7 09 14 PM" src="https://user-images.githubusercontent.com/87324768/146111187-29f81aab-a138-442d-90bd-df24d512fe01.png">

test/jdk/java/awt/a11y/AccessibleTextTest.java line 142:

> 140:         panel.setLayout(new FlowLayout());
> 141:         JTextArea textArea = new JTextArea(value);
> 142:         panel.add(textArea);

Hello. @mrserb Thanks for the invitation.
This addition seems redundant to me. This is a test for a non-editable JTextArea. In it, the instruction is the same as the test.
If you press "Pass", the next test will appear, which has a multi-line text editor. This will also be a JTextArea, but already editable.

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

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


From duke at openjdk.java.net  Thu Dec 16 10:08:02 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Thu, 16 Dec 2021 10:08:02 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <tg7Sv5jpg6jWaFIxwJyvw3_NgW361GA0UlQRf1ahB7U=.1e21b0d6-194a-4fb4-b3ff-2a483e2a51fb@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>
 <_yyT1DE1iec1ea6SsjCE-wT6fBrkBrws9Co61mbukNs=.572220ae-c3a4-4363-864a-bcfcc51c0e73@github.com>
 <uHq1u2ACe0f76QG6LmzL46aajn0wo2ox2EsogAW5LYI=.4c5fd99f-46ba-4e47-8609-50a34cf3f2b1@github.com>
 <P-6pif9tfiiMosYNFbAc28c4CbsvbJfqnjenCFyP2Zw=.3d79147e-5f4b-49f9-9008-bdb3e8635156@github.com>
 <tos3Ywq_UcdsQhS7zEfbfYDNRm6XHCZcMow8zofnay4=.ef0f5ef8-1326-4c50-9dd9-7c606ee75977@github.com>
 <tg7Sv5jpg6jWaFIxwJyvw3_NgW361GA0UlQRf1ahB7U=.1e21b0d6-194a-4fb4-b3ff-2a483e2a51fb@github.com>
Message-ID: <Y0G41VwQTVY516OakI6mFv3KNZ0CciWWKSU47WA7ScI=.15a26e6e-051d-4ef2-9efd-262b21441bc4@github.com>

On Thu, 16 Dec 2021 05:18:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Hm? It's not the other way around. `DefaultCellEditor` implements `TableCellEditor`; the interface defines the `getTableCellEditorComponent` method that returns the _real component_ which will be used as the value editor.
>> 
>> So yeah, you're absolutely right: the current statement in the doc seems wrong.
>> 
>> I'm for changing the Javadoc for `TableCellEditor` to be similar to `TreeCellEditor`: _?Adds to CellEditor the extensions necessary to configure an editor in a table.?_
>> 
>> The object that implements the interface is not necessarily the editor for values. `DefaultCellEditor`  is the perfect example: it's not an editor itself, it's not even a component, all it does is configures a delegate, a `JComponent`, which serves as the editor.
>
>> The object that implements the interface is not necessarily the editor for values. DefaultCellEditor is the perfect example: it's not an editor itself, it's not even a component, all it does is configures a delegate, a JComponent, which serves as the editor.
> 
> My thoughts about this. The object which implements the interface is always the "editor", even if it is not a component. I guess you are mixing it with the other classes like "JEditorPane/JTextField/etc". 
> 
> The current spec:
> 
>>This interface defines the method any object that would like to be
> an editor of values for components such as <code>JListBox</code>,
> <code>JComboBox</code>, <code>JTree</code>, or <code>JTable</code>
> needs to implement.
> 
> This means that the application may have some values/data stored in the JComboBox/JTree/JTable and the application may create a cell editor by implementing the TableCellEditor. That editor then could be used as a cell editor in the "main" JTable.
> 
> So the next statement in the description of this PR is not completely right:
>> "CellTableEditor Interface doesn't support JComboBox and JTree components"
> 
> The JComboBox and other classes do not have to implement/support that interface.

Yeah, if u refer this example page [https://bip.weizmann.ac.il/course/prog2/tutorial/uiswing/components/example-1dot4/ColorEditor.java], the interface is used for a cell in a table which has a button in turn invokes "JColorChooser" class. Which means the interface is used to store a particular value while the cell in is editor mode......?

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

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


From duke at openjdk.java.net  Thu Dec 16 10:32:00 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Thu, 16 Dec 2021 10:32:00 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <Y0G41VwQTVY516OakI6mFv3KNZ0CciWWKSU47WA7ScI=.15a26e6e-051d-4ef2-9efd-262b21441bc4@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>
 <_yyT1DE1iec1ea6SsjCE-wT6fBrkBrws9Co61mbukNs=.572220ae-c3a4-4363-864a-bcfcc51c0e73@github.com>
 <uHq1u2ACe0f76QG6LmzL46aajn0wo2ox2EsogAW5LYI=.4c5fd99f-46ba-4e47-8609-50a34cf3f2b1@github.com>
 <P-6pif9tfiiMosYNFbAc28c4CbsvbJfqnjenCFyP2Zw=.3d79147e-5f4b-49f9-9008-bdb3e8635156@github.com>
 <tos3Ywq_UcdsQhS7zEfbfYDNRm6XHCZcMow8zofnay4=.ef0f5ef8-1326-4c50-9dd9-7c606ee75977@github.com>
 <tg7Sv5jpg6jWaFIxwJyvw3_NgW361GA0UlQRf1ahB7U=.1e21b0d6-194a-4fb4-b3ff-2a483e2a51fb@github.com>
 <Y0G41VwQTVY516OakI6mFv3KNZ0CciWWKSU47WA7ScI=.15a26e6e-051d-4ef2-9efd-262b21441bc4@github.com>
Message-ID: <hDtJcE8Z_iYWU4JiLcJg2FsuC1PTUZE2B34VeJAoNtc=.075bca12-4ded-4f70-927c-c101b251f4a8@github.com>

On Thu, 16 Dec 2021 10:04:49 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>>> The object that implements the interface is not necessarily the editor for values. DefaultCellEditor is the perfect example: it's not an editor itself, it's not even a component, all it does is configures a delegate, a JComponent, which serves as the editor.
>> 
>> My thoughts about this. The object which implements the interface is always the "editor", even if it is not a component. I guess you are mixing it with the other classes like "JEditorPane/JTextField/etc". 
>> 
>> The current spec:
>> 
>>>This interface defines the method any object that would like to be
>> an editor of values for components such as <code>JListBox</code>,
>> <code>JComboBox</code>, <code>JTree</code>, or <code>JTable</code>
>> needs to implement.
>> 
>> This means that the application may have some values/data stored in the JComboBox/JTree/JTable and the application may create a cell editor by implementing the TableCellEditor. That editor then could be used as a cell editor in the "main" JTable.
>> 
>> So the next statement in the description of this PR is not completely right:
>>> "CellTableEditor Interface doesn't support JComboBox and JTree components"
>> 
>> The JComboBox and other classes do not have to implement/support that interface.
>
> Yeah, if u refer this example page [https://bip.weizmann.ac.il/course/prog2/tutorial/uiswing/components/example-1dot4/ColorEditor.java], the interface is used for a cell in a table which has a button in turn invokes "JColorChooser" class. Which means the interface is used to store a particular value while the cell in is editor mode......?

After going on through the example, what I felt is "Adds to CellEditor the extensions necessary to configure an editor in a tree" is little generic description than the updated PR Definition.

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

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


From duke at openjdk.java.net  Thu Dec 16 11:25:44 2021
From: duke at openjdk.java.net (Jeremy)
Date: Thu, 16 Dec 2021 11:25:44 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v11]
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <kqSfiOSnIitZfO9-X-I9r_uSkGzqsnnofoJamUn5IB8=.c56badad-a2c1-4b21-8721-651e99051243@github.com>

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

Jeremy has updated the pull request incrementally with five additional commits since the last revision:

 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
   
   Fixing compilation error now that Path2D#getBounds is not public
 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
   
   Fixing unit test failures introduced with b3e84a5e4281c2bb9be1c7e1d751ef3593cc387c .
   
   (The likely explanation for why this went unaddressed previously is: I probably didn't correctly execute unit tests after this change. A less likely explanation might be: the Path2D/UnitTest class uses random numbers each session, so it's possible results passed in that session and failed in others.)
 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
   
   Adding missing @param tag.
   
   This is in response to prrace's code review feedback:
   
   > For me it doesn't build because of a doclint error
   
   > src/java.desktop/share/classes/java/awt/geom/Path2D.java:2102:
   > warning: no @param for pi
   > public static Rectangle2D getBounds2D(final PathIterator pi) {
   > ^
   > error: warnings found and -Werror specified
   
   https://github.com/openjdk/jdk/pull/6227#issuecomment-995305817
 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
   
   Make the new getBounds2D(PathIterator) method package private.
   
   This is in response to prrace's code review feedback:
   
   > public static Rectangle2D getBounds2D(final PathIterator pi);
   >
   > Is this really necessary ? It is just for the benefit of the
   > public API caller so can be package private.
   
   https://github.com/openjdk/jdk/pull/6227#issuecomment-995305817
   
   Personally (having written custom java.awt.Shape classes) I think this method would be of general use (so it could be public), but if that's the minority opinion: I'm happy to convert it to package private for now. If we ever want to discuss making it public then that could be a separate PR/conversation.
 - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
   
   Restore the "final" and "synchronized" modifiers for this method. I don't think these were removed on purpose; the intent behind this PR is not related to the modifiers of the method.
   
   This is in response to prrace's code review comment:
   
   > So no longer final, and no longer synchronized.
   > This means a CSR is required and we need to think about it .. the
   > intention was that the subclass not over-ride.
   > And why remove synchronized ? I am fairly sure it was there to make
   > sure no one was mutating the Path whilst bounds are being calculated.
   > And you are using getPathIterator(AffineTransform) and the docs for
   > that say it isn't thread safe.
   > So I think this implementation needs to be thought about very carefully.
   
   https://github.com/openjdk/jdk/pull/6227#issuecomment-995305817

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

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

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

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

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


From lbourges at openjdk.java.net  Thu Dec 16 11:28:55 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 16 Dec 2021 11:28:55 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v10]
In-Reply-To: <W1sc79kkjjEU2gMwVffM-tW9nvdr4hIkRNvWJrkPzXY=.0d9881e6-2761-4fe2-81e3-86abb50fd5ca@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <W1sc79kkjjEU2gMwVffM-tW9nvdr4hIkRNvWJrkPzXY=.0d9881e6-2761-4fe2-81e3-86abb50fd5ca@github.com>
Message-ID: <CzuSmothlV_ct_tCd0jgkatQOxjdxAf6eRvWWe4OOG0=.0693b81e-7e18-4d1d-8fdb-b5ccd86af175@github.com>

On Fri, 19 Nov 2021 19:09:54 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   Addressing code review feedback: "Use BigDecomal.setScale(40) to ascertain precision."
>   
>   The geom.* unit tests passed before & after this change.
>   
>   https://github.com/openjdk/jdk/pull/6227#discussion_r752908494

Last changes look good and I agree the synchronization is mandatory.
Good job

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

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


From dmitry.batrak at jetbrains.com  Thu Dec 16 14:13:30 2021
From: dmitry.batrak at jetbrains.com (Dmitry Batrak)
Date: Thu, 16 Dec 2021 17:13:30 +0300
Subject: macOS font fallback implementation discussion
Message-ID: <CAET5FPu-WnCP1As7Pf4sA9Ezvmp=n+cdKShZf3uYSjN3HpSS_Q@mail.gmail.com>

Hello,

I'm working on modifications to JDK's font fallback implementation on macOS
- first to be tested in JetBrains Runtime,
and then planned for submission into OpenJDK - and I'd like to discuss the
overall approach now, way before the
pull-request stage.

Currently, OpenJDK uses two macOS system functions to implement font
fallback: `JRSFontCreateFallbackFontForCharacters`
and `CTFontCopyDefaultCascadeListForLanguages`. Using two different
functions in different code paths is a source of
inconsistencies, and, I believe, it's generally agreed that some unified
approach should be used instead.

For the past 5 years, JetBrains Runtime solved this problem by using
`JRSFontCreateFallbackFontForCharacters`
exclusively for all code paths. But, as discussed previously [1], it's not
a preferred solution
(e.g. due to JDK-8024281).

The obvious remaining alternative is to use
`CTFontCopyDefaultCascadeListForLanguages` exclusively. It seems to work
quite fine (see e.g. [2] for implementation details), a runtime build using
such an approach is already used
internally in the company. The only shortcoming I see is the smaller
Unicode repertoire coverage.

Taking, for example, 'Menlo' as a base font, with
`JRSFontCreateFallbackFontForCharacters` used for fallback, we get
about 72k Unicode code points covered, while with
`CTFontCopyDefaultCascadeListForLanguages` - only about 60k. This is
apparently due to a larger set of fonts used by
`JRSFontCreateFallbackFontForCharacters` - investigation shows it can
even use fonts installed by the user.

Code points 'omitted' by the new approach belong to quite exotic scripts,
e.g. the largest missing 'blocks' are for
cuneiform and Egyptian hieroglyphs (each of them accounting for about 1k
code points). So, I believe, it shouldn't be a
significant problem, at least for our use cases, but this waits to be
confirmed or denied in a public testing.

What are your thoughts on this? Is such a regression in behaviour
acceptable, or is it a no-go for OpenJDK, and the
approach should be improved? To be more precise, switching to
`CTFontCopyDefaultCascadeListForLanguages` for font
fallback in a straightforward manner will make certain characters not
renderable with plain `Graphics.drawString`
call, while currently they are not renderable only in cases font has layout
attributes (ligatures or kerning), or
text layout is requested explicitly (via `Font.layoutGlyphVector` or using
`TextLayout` class). Of course, we are
talking about font fallback situation only - by selecting a font supporting
those characters specifically, it is always
possible to render the characters.

Speaking of options to improve the coverage, the simplest one is, of
course, extending the cascade list with
additional fonts. Either some hardcoded list of them can be used, or a
subset of the fonts available on the system
selected by some criteria. E.g. using all 'Noto Sans *' fonts (there are
about 100 of them on my macOS system) reduces
the coverage gap to about 1k code points. This option is quite easy to
implement, but it will require revisiting if
future macOS versions will switch to some other fonts for fallback.

Another possible option is to use `CTFontCreateForString` function, which
is basically the same as
`JRSFontCreateFallbackFontForCharacters`, but is a part of the public Core
Text API. It can be used in addition to cascade
list or as a sole source of font fallback information (as, I believe, it
does use the same cascade list internally).
This will require using a 'dynamic' variant of `CompositeFont`, which is
populated during its usage, but that worked OK
in JetBrains Runtime with  `JRSFontCreateFallbackFontForCharacters`.

A more extreme option would be to scan all available fonts, if the cascade
list doesn't contain a suitable one, but
I guess it might cause problems with performance.

What do you think about it? Did I miss some viable options? Does it make
sense to go beyond the default cascade list
at all, at least in the initial version?

[1] https://mail.openjdk.java.net/pipermail/2d-dev/2017-February/008205.html
[2] https://github.com/JB-Dmitry/jdk/commits/macFontFallback


Best regards,
Dmitry Batrak


From duke at openjdk.java.net  Thu Dec 16 14:21:58 2021
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 16 Dec 2021 14:21:58 GMT
Subject: RFR: 8278828 : java/awt/a11y/AccessibleTextTest.java's
 createTextArea() just shows instructions on the UI
In-Reply-To: <x00FxnlfbrZgvR0Qp0qPulsBoR7EJWqIXs8J6hCLu_I=.738661ef-82a4-426e-a19f-7e27a08e2353@github.com>
References: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
 <x00FxnlfbrZgvR0Qp0qPulsBoR7EJWqIXs8J6hCLu_I=.738661ef-82a4-426e-a19f-7e27a08e2353@github.com>
Message-ID: <ZOYIQn0OAodE7KQ4BUcoSbc5ajwEAFsZ9W-Aq_d2CtM=.441ae440-4f0a-429f-815b-bc997f129a72@github.com>

On Thu, 16 Dec 2021 08:32:40 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> 1) Test scenario was just showing test instruction with JTextArea. So added the JTextArea as the instruction and method says. 
>> 2) JTextArea is filled with contents so that and an Emoji character making sure that screen reader can read Emoji also.
>> 3) Now user can user arrow keys to navigate the JTextArea and screen reader can read it.
>> 
>> @shurymury 
>> 
>> Attached the screen shot of the test UI which contains JTextArea along with the instruction.
>> <img width="623" alt="Screen Shot 2021-12-14 at 7 09 14 PM" src="https://user-images.githubusercontent.com/87324768/146111187-29f81aab-a138-442d-90bd-df24d512fe01.png">
>
> test/jdk/java/awt/a11y/AccessibleTextTest.java line 142:
> 
>> 140:         panel.setLayout(new FlowLayout());
>> 141:         JTextArea textArea = new JTextArea(value);
>> 142:         panel.add(textArea);
> 
> Hello. @mrserb Thanks for the invitation.
> This addition seems redundant to me. This is a test for a non-editable JTextArea. In it, the instruction is the same as the test.
> If you press "Pass", the next test will appear, which has a multi-line text editor. This will also be a JTextArea, but already editable.

Hi @savoptik, 
a) The test createTextArea() does not have JTextArea . I have attached the screen shot of the test https://bugs.openjdk.java.net/browse/JDK-8278828
b) The test does not say its a non-editable JTextArea. Even the exception String also say as follows
exceptionString = "Simple text area test failed!";  . 
c) If user press "Pass" to see the next test then there is no need of  createTextArea() . Correct me if I am wrong?

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

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


From dbatrak at openjdk.java.net  Thu Dec 16 15:59:19 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Thu, 16 Dec 2021 15:59:19 GMT
Subject: RFR: 8278908: [macOS] Unexpected text normalization on pasting from
 clipboard
Message-ID: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>

The fix just removes the explicit normalization of text obtained from system clipboard in JDK code, as I've found no
good justification for such a normalization, at least for the latest macOS version.
The same fix was performed in JetBrains Runtime by a user's request more than 4 years ago, and we didn't receive any
related complaints from our users ever since.

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

Commit messages:
 - fix

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

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


From duke at openjdk.java.net  Thu Dec 16 18:33:37 2021
From: duke at openjdk.java.net (Jeremy)
Date: Thu, 16 Dec 2021 18:33:37 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v12]
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>

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

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

  8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
  
  This is a second follow-up response to prrace's code review feedback about method modifiers.
  
  This commit more carefully preserves the getBounds2D() method modifiers for all 3 classes: the Path2D.Double, the Path2D.Float, and the Path2D itself.
  
  It is possible (if unlikely) that someone previously extended the Path2D class and overrode getBounds2D(), because the Path2D#getBounds2D() method was *not* final. So with this commit: any such existing code will not break. Meanwhile the subclasses (Double and Float) preserve their previous modifiers (final, synchronized).
  
  This is in response to prrace's code review:
  
  >    You are changing the signature of public API
  >    src/java.desktop/share/classes/java/awt/geom/Path2D.java
  >    public final synchronized Rectangle2D getBounds2D() => public Rectangle2D getBounds2D() {
  >
  > So no longer final, and no longer synchronized.
  > This means a CSR is required and we need to think about it ..
  > the intention was that the subclass not over-ride.
  > And why remove synchronized ? I am fairly sure it was there to
  > make sure no one was mutating the Path whilst
  > bounds are being calculated.
  > And you are using getPathIterator(AffineTransform) and the docs
  > for that say it isn't thread safe.
  > So I think this implementation needs to be thought about very carefully.

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

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

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

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

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


From duke at openjdk.java.net  Thu Dec 16 18:37:05 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 16 Dec 2021 18:37:05 GMT
Subject: Withdrawn: 8225777: java/awt/Mixing/MixingOnDialog.java fails on
 Ubuntu
In-Reply-To: <qg109bdSP2hEfYj2OX60PzZpasVQ7gYUf9YpXC1UbXg=.cf7eac5e-623a-426d-adff-8328a9a5c63f@github.com>
References: <qg109bdSP2hEfYj2OX60PzZpasVQ7gYUf9YpXC1UbXg=.cf7eac5e-623a-426d-adff-8328a9a5c63f@github.com>
Message-ID: <HIA4QBcSV27z8sGBPiCk932nAAGJhsQYFS2CEhffEFI=.dff0130f-42eb-488e-a1a8-c685136bbecf@github.com>

On Wed, 20 Oct 2021 12:05:57 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Looks like the test started failing after increasing of window's title height in Ubuntu theme:
> 
> ![image](https://user-images.githubusercontent.com/77687766/138088503-f380bcb2-1ffc-4d58-b6b2-2efc56b7975c.png)
> So the click happens on windows title instead of the button.
> 
> For example, macOS has smaller window title height, which allows test to pass.
> <img src="https://user-images.githubusercontent.com/77687766/138088659-bd636518-c23c-4c5e-bf97-61035753c71a.png" width="50%" height="50%">
> 
> Fix moves buttons away from window title.
> ![image](https://user-images.githubusercontent.com/77687766/138088880-a9d1ec38-cde2-437e-80b9-5b7bdf73fd6b.png)
> 
> Testing is green.

This pull request has been closed without being integrated.

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

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


From asemenov at openjdk.java.net  Thu Dec 16 19:26:00 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Thu, 16 Dec 2021 19:26:00 GMT
Subject: RFR: 8278828 : java/awt/a11y/AccessibleTextTest.java's
 createTextArea() just shows instructions on the UI
In-Reply-To: <ZOYIQn0OAodE7KQ4BUcoSbc5ajwEAFsZ9W-Aq_d2CtM=.441ae440-4f0a-429f-815b-bc997f129a72@github.com>
References: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
 <x00FxnlfbrZgvR0Qp0qPulsBoR7EJWqIXs8J6hCLu_I=.738661ef-82a4-426e-a19f-7e27a08e2353@github.com>
 <ZOYIQn0OAodE7KQ4BUcoSbc5ajwEAFsZ9W-Aq_d2CtM=.441ae440-4f0a-429f-815b-bc997f129a72@github.com>
Message-ID: <HJPkwHFV7VoHACxsVK8kWa-3RcEXMoHNCDNR9mjAlsA=.3dc42967-c43f-454a-9ea3-376a82b49483@github.com>

On Thu, 16 Dec 2021 14:18:37 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> test/jdk/java/awt/a11y/AccessibleTextTest.java line 142:
>> 
>>> 140:         panel.setLayout(new FlowLayout());
>>> 141:         JTextArea textArea = new JTextArea(value);
>>> 142:         panel.add(textArea);
>> 
>> Hello. @mrserb Thanks for the invitation.
>> This addition seems redundant to me. This is a test for a non-editable JTextArea. In it, the instruction is the same as the test.
>> If you press "Pass", the next test will appear, which has a multi-line text editor. This will also be a JTextArea, but already editable.
>
> Hi @savoptik, 
> a) The test createTextArea() does not have JTextArea . I have attached the screen shot of the test https://bugs.openjdk.java.net/browse/JDK-8278828
> b) The test does not say its a non-editable JTextArea. Even the exception String also say as follows
> exceptionString = "Simple text area test failed!";  . 
> c) If user press "Pass" to see the next test then there is no need of  createTextArea() . Correct me if I am wrong?

a) The test createTextArea() does not have JTextArea .
YES, createTextArea () does not create a JTextArea, but the instruction field itself is not editable JTextArea. Take a look at the AccessibleComponentTest to be sure.
b) The test does not say its a non-editable JTextArea. Even the exception String also say as follows
exceptionString = "Simple text area test failed!"; .
Yes, the instructions do not indicate that this is not an editable JTextArea, you can supplement the instructions. As well as an exception String.
c) If user press "Pass" to see the next test then there is no need of createTextArea() .
There is a need.This test tries to cover all cases and possible configurations of various text components: single-line, multi-line, editable, non-editable - and various possible combinations. It is also convenient to use them when developing and debugging native implementations of a11y, for which they were created by me.

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

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


From duke at openjdk.java.net  Thu Dec 16 21:42:05 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 16 Dec 2021 21:42:05 GMT
Subject: Integrated: 8277868: Use Comparable.compare() instead of surrogate
 code
In-Reply-To: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
Message-ID: <5ZOhPiacNs5fjMH_6weWYlaPWVSqPMvRAXY2iT_6T68=.3e2499b4-45e6-497c-b5c0-d549d7c324e2@github.com>

On Fri, 26 Nov 2021 12:46:59 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> Instead of something like
> 
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
> 
> we can use `return Long.compare(x, y);`
> 
> All replacements are done with IDE.

This pull request has now been integrated.

Changeset: 20db7800
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/20db7800a657b311eeac504a2bbae4adbc209dbf
Stats:     77 lines in 12 files changed: 2 ins; 54 del; 21 mod

8277868: Use Comparable.compare() instead of surrogate code

Reviewed-by: rriggs, aivanov

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

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


From duke at openjdk.java.net  Thu Dec 16 23:52:30 2021
From: duke at openjdk.java.net (Jeremy)
Date: Thu, 16 Dec 2021 23:52:30 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v10]
In-Reply-To: <zpv7BNMCYGS46-g71oPhITHOJkvAOmOe9fOZZD3LGM4=.bb761f9a-e2a8-47d4-b377-56a5c0db45a5@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <W1sc79kkjjEU2gMwVffM-tW9nvdr4hIkRNvWJrkPzXY=.0d9881e6-2761-4fe2-81e3-86abb50fd5ca@github.com>
 <zpv7BNMCYGS46-g71oPhITHOJkvAOmOe9fOZZD3LGM4=.bb761f9a-e2a8-47d4-b377-56a5c0db45a5@github.com>
Message-ID: <H_YuES98nIRuFixw-SmXj056tOmyKy9OIesy8CjmJQ4=.14af37a3-4f26-4051-96a7-7004f13bf696@github.com>

On Wed, 15 Dec 2021 23:49:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>>   
>>   Addressing code review feedback: "Use BigDecomal.setScale(40) to ascertain precision."
>>   
>>   The geom.* unit tests passed before & after this change.
>>   
>>   https://github.com/openjdk/jdk/pull/6227#discussion_r752908494
>
> There seems to be a number of things to discuss aside from the maths
> 
> - You are changing the signature of public API
>   src/java.desktop/share/classes/java/awt/geom/Path2D.java
> public final synchronized Rectangle2D getBounds2D() => public Rectangle2D getBounds2D() {
> 
> So no longer final, and no longer synchronized.
> This means a CSR is required and we need to think about it .. the intention was that the subclass not over-ride.
> And why remove synchronized ? I am fairly sure it was there to make sure no one was mutating the Path whilst
> bounds are being calculated.
> And you are using getPathIterator(AffineTransform) and the docs for that say it isn't thread safe.
> So I think this implementation needs to be thought about very carefully.
> 
> - You are adding a new public static method
> 
> public static Rectangle2D getBounds2D(final PathIterator pi);
> 
> Is this really necessary ? It is just for the benefit of the public API caller so can be package private.
> 
> - For me it doesn't build because of a doclint error
> 
> src/java.desktop/share/classes/java/awt/geom/Path2D.java:2102: warning: no @param for pi
>     public static Rectangle2D getBounds2D(final PathIterator pi) {
>                               ^
> error: warnings found and -Werror specified
> 
> Fixing that I find that the updated UnitTest.java fail with a build with these changes :-
> 
> % java UnitTest
> Exception in thread "main" java.lang.RuntimeException: the shape must not intersect anything above its bounds
>     at UnitTest.testGetBounds2D(UnitTest.java:1396)
>     at UnitTest.testBounds(UnitTest.java:1302)
>     at UnitTest.test(UnitTest.java:1175)
>     at UnitTest.main(UnitTest.java:1435)
> 
> Then we have some even more difficult questions.
> The control points may not be within the bounds of the curve which is of course the premise of the bug report.
> The specification (javadoc) isn't very forthcoming on whether it is allowed to not include them .. ie is it expected they should be ?
> And it appears we have JCK tests which expect they ARE included. So as it is this change would not pass the existing TCK/JCK. 
> Which means we'd have to be 100% sure about this change in behaviour and be able to justify it.
> FWIW unless the spec explicitly says they are, in some place I've overlooked,
> then I'd say its a quality-of-implementation thing as to how tight the bounds are, and the new behaviour is allowed by spec.
> Applications however might still find this a behaviourally incompatible change .. and could potentially see undesirable consequences -
> even as other applications see better consequences.
> So perhaps new API that defines tighter bounds  might be  the way to address this .. but I am far from being sure about that.

@prrace thanks for your feedback. The first several points you raised were bugs/problems that I believe I have addressed just now. Specifically:
1. The method signatures were not meant to change, so the method modifiers are restored.
2. I see no reason why the new Path2D#getBounds2D() can't be package private for now. So that's updated. (If we ever want to change that: that can be a separate ticket/PR.)
3. The missing @param tag is fixed
4. The unit test failure you observed is fixed. (That's actually a new unit test. Although your point stands that existing tests had to be modified to adjust for this new behavior.)

Regarding bigger issues, you wrote:
> The specification (javadoc) isn't very forthcoming on whether [the bounding box] is allowed to not include 
> [control points] .. ie is it expected they should be ?

I would argue the crux of the Shape#getBounds2D() contract is this phrase: "the Shape lies entirely within the indicated Rectangle2D". And by "Shape" the original authors probably mean "the defining outline" (a phrase referenced in the second paragraph of the javadoc).

If instead the word "Shape" is interpreted as "all the points in the path, including control points" then (I think?) that means the Area class suddenly violates the contract. (Because it has always returned a very tight bounding box that (I think?) disregards control points.) And if we "fix" the Area class so its getBounds2D() method can intentionally return more empty space: that seems antithetical to the intent of the original ticket under consideration.

So as of this writing:
A. There should be no changed (or new) public method signatures in this PR. 
B. IMO there is no need to review an interface change for the Shape#getBounds2D() method -- or the Path2D#getBounds2D() method.

What do you think? I'm happy to proceed with a CSR if you think this requires further consideration, I just wanted to double-check.

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

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


From prr at openjdk.java.net  Fri Dec 17 02:46:48 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 17 Dec 2021 02:46:48 GMT
Subject: RFR: 8278937: JCK test for java_awt/geom/Line2D.Float fails after
 8277868
Message-ID: <cIaM9pnlUnOXZBD6uaiwhWiA9iXxDUDX92kU94HqgPg=.c39205cf-cc13-4f1e-8fe5-b1fa514d006e@github.com>

This reverts the uses of Float.compare() and Double.compare() made by the fix for 8277868
since it appears clear that for better or worse they are not 100% compatible with the previous code.
These uses are all in the desktop module

For comparison the original changes are here : https://github.com/openjdk/jdk/pull/6575/files

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

Commit messages:
 - 8278937: JCK test for java_awt/geom/Line2D.Float fails after 8277868
 - 8278937: JCK test for java_awt/geom/Line2D.Float fails after 8277868

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

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


From jdv at openjdk.java.net  Fri Dec 17 04:37:24 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Fri, 17 Dec 2021 04:37:24 GMT
Subject: RFR: 8278937: JCK test for java_awt/geom/Line2D.Float fails after
 8277868
In-Reply-To: <cIaM9pnlUnOXZBD6uaiwhWiA9iXxDUDX92kU94HqgPg=.c39205cf-cc13-4f1e-8fe5-b1fa514d006e@github.com>
References: <cIaM9pnlUnOXZBD6uaiwhWiA9iXxDUDX92kU94HqgPg=.c39205cf-cc13-4f1e-8fe5-b1fa514d006e@github.com>
Message-ID: <2M4uaipX38pvCX-Kd9a6Mdqui70YS1UTcdnyVhgWBmo=.9fce553d-4e15-4ccb-85f8-a6dd225b94c3@github.com>

On Fri, 17 Dec 2021 02:40:04 GMT, Phil Race <prr at openjdk.org> wrote:

> This reverts the uses of Float.compare() and Double.compare() made by the fix for 8277868
> since it appears clear that for better or worse they are not 100% compatible with the previous code.
> These uses are all in the desktop module
> 
> For comparison the original changes are here : https://github.com/openjdk/jdk/pull/6575/files

Marked as reviewed by jdv (Reviewer).

Looks like some precision differences in fractional numbers is causing this. As mentioned in JBS, i think these differences might not apply for Integer comparison. 

LGTM.

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

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


From kcr at openjdk.java.net  Fri Dec 17 12:15:24 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 17 Dec 2021 12:15:24 GMT
Subject: RFR: 8278937: JCK test for java_awt/geom/Line2D.Float fails after
 8277868
In-Reply-To: <cIaM9pnlUnOXZBD6uaiwhWiA9iXxDUDX92kU94HqgPg=.c39205cf-cc13-4f1e-8fe5-b1fa514d006e@github.com>
References: <cIaM9pnlUnOXZBD6uaiwhWiA9iXxDUDX92kU94HqgPg=.c39205cf-cc13-4f1e-8fe5-b1fa514d006e@github.com>
Message-ID: <XzG9g__acde0TVSVFHNQCV0yaYx5rG1xHoYixcvR_m8=.d9719cbd-9882-427a-a142-67619f058f84@github.com>

On Fri, 17 Dec 2021 02:40:04 GMT, Phil Race <prr at openjdk.org> wrote:

> This reverts the uses of Float.compare() and Double.compare() made by the fix for 8277868
> since it appears clear that for better or worse they are not 100% compatible with the previous code.
> These uses are all in the desktop module
> 
> For comparison the original changes are here : https://github.com/openjdk/jdk/pull/6575/files

Looks good. I can confirm that the correctly reverts the changes from JDK-8277868 in `java.desktop`.

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

Marked as reviewed by kcr (Author).

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


From kcr at openjdk.java.net  Fri Dec 17 13:08:25 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 17 Dec 2021 13:08:25 GMT
Subject: [jdk18] RFR: 8278604 SwingSet2 table demo does not have accessible
 description set for images
In-Reply-To: <Lyzvep8gxUVfXgtv9eMFTjSRAxr-px2sD47R59Yqmtg=.a1b1c4d2-8c40-4ec9-90e4-27b506d52852@github.com>
References: <MpzD5J0C_EuymSeZVLorPymbQH3QJe9LWmXVykE7_Bs=.8b1fdb8e-c3ab-4ed4-936e-0ae660742cf7@github.com>
 <Lyzvep8gxUVfXgtv9eMFTjSRAxr-px2sD47R59Yqmtg=.a1b1c4d2-8c40-4ec9-90e4-27b506d52852@github.com>
Message-ID: <TwaZkdRi4bqKv8Xx1mQkYMNUXhAiPORO7qyCXL85fF0=.50278473-fa3f-4719-b93b-861f605ed314@github.com>

On Wed, 15 Dec 2021 13:24:53 GMT, Anton Tarasov <ant at openjdk.org> wrote:

>> SwingSet2 demo is often used to check accessibility for different Swing components and has some shortcomings. The major one is that images within the table demo do not have accessible description set which makes accessibility perform differently on different platforms when navigating the table with screen narrator enabled.
>> 
>> This is the next step after the solution [JDK-8277497](https://bugs.openjdk.java.net/browse/JDK-8277497), in which we forwarded the description from the icon into the label description so that this fix was possible.
>
> Marked as reviewed by ant (Reviewer).

> /reviewer credit @forantar @azuev-java @pankaj-bansal

@savoptik For future reference, the `/reviewer credit` command is not the way to request a review, but rather is a way to credit additional reviewers who have made significant review comments, but have not formally reviewed it in the GitHub PR.

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

PR: https://git.openjdk.java.net/jdk18/pull/31


From rriggs at openjdk.java.net  Fri Dec 17 15:06:27 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 17 Dec 2021 15:06:27 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v6]
In-Reply-To: <Oi8A_LWOae14543lPHb3inUSq4s3yF9GRmu5qQdmqh0=.82cc5f87-bb16-420a-8222-03fe6631a29e@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <Oi8A_LWOae14543lPHb3inUSq4s3yF9GRmu5qQdmqh0=.82cc5f87-bb16-420a-8222-03fe6631a29e@github.com>
Message-ID: <GxSLYrrtSHkak2yRopMZZvKVbrsN7qFo-2BmNFUANt8=.aff00657-cdd8-4d5c-b57a-096d3fa68d08@github.com>

On Thu, 9 Dec 2021 13:03:39 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> Instead of something like
>> 
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>> 
>> we can use `return Long.compare(x, y);`
>> 
>> All replacements are done with IDE.
>
> ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8277868: Use Long.compare() for mostSigBits as well
>  - Revert "8277868: Adjust JavaDoc of UUID"
>    
>    This reverts commit f3b95d0e247cf6452955f4f24684fd60d5cb8902.

As it turns out replacing the code was not 100% equivalent and a test failure resulted.
See https://bugs.openjdk.java.net/browse/JDK-8278937

Double.compare and the original code handle the non-numeric forms of Double differently.

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

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


From rriggs at openjdk.java.net  Fri Dec 17 15:08:26 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 17 Dec 2021 15:08:26 GMT
Subject: RFR: 8278937: JCK test for java_awt/geom/Line2D.Float fails after
 8277868
In-Reply-To: <cIaM9pnlUnOXZBD6uaiwhWiA9iXxDUDX92kU94HqgPg=.c39205cf-cc13-4f1e-8fe5-b1fa514d006e@github.com>
References: <cIaM9pnlUnOXZBD6uaiwhWiA9iXxDUDX92kU94HqgPg=.c39205cf-cc13-4f1e-8fe5-b1fa514d006e@github.com>
Message-ID: <q4tG9M6jdQgnZpE2t10RYd2o1d48wMqLRXiOeAloeJE=.a6cf3c9b-6007-4df4-a1e3-99071d0f6160@github.com>

On Fri, 17 Dec 2021 02:40:04 GMT, Phil Race <prr at openjdk.org> wrote:

> This reverts the uses of Float.compare() and Double.compare() made by the fix for 8277868
> since it appears clear that for better or worse they are not 100% compatible with the previous code.
> These uses are all in the desktop module
> 
> For comparison the original changes are here : https://github.com/openjdk/jdk/pull/6575/files

Marked as reviewed by rriggs (Reviewer).

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

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


From prr at openjdk.java.net  Fri Dec 17 15:13:24 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 17 Dec 2021 15:13:24 GMT
Subject: Integrated: 8278937: JCK test for java_awt/geom/Line2D.Float fails
 after 8277868
In-Reply-To: <cIaM9pnlUnOXZBD6uaiwhWiA9iXxDUDX92kU94HqgPg=.c39205cf-cc13-4f1e-8fe5-b1fa514d006e@github.com>
References: <cIaM9pnlUnOXZBD6uaiwhWiA9iXxDUDX92kU94HqgPg=.c39205cf-cc13-4f1e-8fe5-b1fa514d006e@github.com>
Message-ID: <PBZ1NgcoYwV714G5zlxnlczQSEMMFfMGpQshkLUCOmA=.6b5d77f4-0501-42a5-b9fb-5d9d6f766aec@github.com>

On Fri, 17 Dec 2021 02:40:04 GMT, Phil Race <prr at openjdk.org> wrote:

> This reverts the uses of Float.compare() and Double.compare() made by the fix for 8277868
> since it appears clear that for better or worse they are not 100% compatible with the previous code.
> These uses are all in the desktop module
> 
> For comparison the original changes are here : https://github.com/openjdk/jdk/pull/6575/files

This pull request has now been integrated.

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

8278937: JCK test for java_awt/geom/Line2D.Float fails after 8277868

Reviewed-by: jdv, kcr, rriggs

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

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


From prr at openjdk.java.net  Fri Dec 17 18:55:35 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 17 Dec 2021 18:55:35 GMT
Subject: RFR: 6462028: MaskFormatter API documentation refers to
 getDisplayValue [v5]
In-Reply-To: <ZsSVQDV0j9BwBsvmj65mix6YahK3iRUanIvf1kInjUI=.27dc88c6-b3e5-4c49-99b5-0b59d306844a@github.com>
References: <-SOfUt64IAtAG0_rLAwkmMCCd81ZaPuTuF5ORNYuIOs=.fd151cd5-71c7-4e21-bd62-aeec7d296e76@github.com>
 <ZsSVQDV0j9BwBsvmj65mix6YahK3iRUanIvf1kInjUI=.27dc88c6-b3e5-4c49-99b5-0b59d306844a@github.com>
Message-ID: <fQK705MEtcSQM_dCZ1vnX9SHxSBQO-8O7XIoPcw7PeM=.9e146802-53b7-4e59-8822-c917561ad0d8@github.com>

On Thu, 9 Dec 2021 13:31:34 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> MaskFormatter API doesn't have getDisplayValue method, hence removed from Documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6462028:MaskFormatter API documentation refers to getDisplayValue

Marked as reviewed by prr (Reviewer).

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

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


From duke at openjdk.java.net  Fri Dec 17 18:56:52 2021
From: duke at openjdk.java.net (Aleksandr Veselov)
Date: Fri, 17 Dec 2021 18:56:52 GMT
Subject: RFR: 8278609: accessibility frame is misplaced on a secondary monitor
 on macOS
Message-ID: <az7KQunDs7VyirWZBUEeN35Ol2C12KSnql8utM3Hap8=.9a02baa4-f3f2-4838-927d-f24f8b2a26eb@github.com>

Use primary screen instead of window main screen to properly convert mouse position from screen coordinates to window ones.

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

Commit messages:
 - Replace [] syntax with `objectAtIndex` call
 - 8278609: accessibility frame is misplaced on a secondary monitor on macOS

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

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


From serb at openjdk.java.net  Fri Dec 17 18:56:53 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 17 Dec 2021 18:56:53 GMT
Subject: RFR: 8278609: accessibility frame is misplaced on a secondary
 monitor on macOS
In-Reply-To: <az7KQunDs7VyirWZBUEeN35Ol2C12KSnql8utM3Hap8=.9a02baa4-f3f2-4838-927d-f24f8b2a26eb@github.com>
References: <az7KQunDs7VyirWZBUEeN35Ol2C12KSnql8utM3Hap8=.9a02baa4-f3f2-4838-927d-f24f8b2a26eb@github.com>
Message-ID: <NYxrD5GCxiF8S4VnDUU6R5BLuFdNScecKEyiT9YM4LU=.5e483be7-45bb-45f0-9c3e-ee4c574690c0@github.com>

On Mon, 13 Dec 2021 15:33:48 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

> Use primary screen instead of window main screen to properly convert mouse position from screen coordinates to window ones.

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

> 793:     point.y += size.height;
> 794: 
> 795:     point.y = [[NSScreen screens][0] frame].size.height - point.y;

isn't the objectAtIndex is widely used than [] in our code base?

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

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


From duke at openjdk.java.net  Fri Dec 17 18:56:56 2021
From: duke at openjdk.java.net (Aleksandr Veselov)
Date: Fri, 17 Dec 2021 18:56:56 GMT
Subject: RFR: 8278609: accessibility frame is misplaced on a secondary
 monitor on macOS
In-Reply-To: <NYxrD5GCxiF8S4VnDUU6R5BLuFdNScecKEyiT9YM4LU=.5e483be7-45bb-45f0-9c3e-ee4c574690c0@github.com>
References: <az7KQunDs7VyirWZBUEeN35Ol2C12KSnql8utM3Hap8=.9a02baa4-f3f2-4838-927d-f24f8b2a26eb@github.com>
 <NYxrD5GCxiF8S4VnDUU6R5BLuFdNScecKEyiT9YM4LU=.5e483be7-45bb-45f0-9c3e-ee4c574690c0@github.com>
Message-ID: <hVI0D8vAVQGSKw9NvLAon-tXVfLIXh0rbF_XrES2kuo=.e5d05502-f314-4a8d-bd25-7a7fcfa625a9@github.com>

On Mon, 13 Dec 2021 20:01:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Use primary screen instead of window main screen to properly convert mouse position from screen coordinates to window ones.
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 795:
> 
>> 793:     point.y += size.height;
>> 794: 
>> 795:     point.y = [[NSScreen screens][0] frame].size.height - point.y;
> 
> isn't the objectAtIndex is widely used than [] in our code base?

Fixed

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

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


From prr at openjdk.java.net  Fri Dec 17 18:59:24 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 17 Dec 2021 18:59:24 GMT
Subject: RFR: JDK-8275923: Override the LPR path using a system property
In-Reply-To: <IhKxuLB4R8_X2tgTTCUJCABGEdJp7qvEUcRT0FdvWQY=.11fdcbdd-bf4c-48b4-8392-98055e17bf67@github.com>
References: <IhKxuLB4R8_X2tgTTCUJCABGEdJp7qvEUcRT0FdvWQY=.11fdcbdd-bf4c-48b4-8392-98055e17bf67@github.com>
Message-ID: <S1Nh-K44BENDWuuLeoSmWHgYVGugNBS5iia6rBBwK9E=.49c795ad-2ebc-4223-8520-fc09c888e187@github.com>

On Wed, 20 Oct 2021 20:38:17 GMT, Rolf van Kleef <duke at openjdk.java.net> wrote:

> On some select systems, the LPR binary may be placed elsewhere (for example at `/app/bin/lpr`). For that reason, we need to be able to override this value. This proposal also allows overriding the LP's path, as it could experience similar difficulties.

Updates more or less along the lines above might make this acceptable
1) The hardcoded location is tried first REGARDLESS of whether the property is set
2) The property is only read ONCE - in something like a static initializer for the class or some mechanism that has the same effect. 
3) The property name is as described above.

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

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


From aivanov at openjdk.java.net  Fri Dec 17 18:59:26 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 17 Dec 2021 18:59:26 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <hDtJcE8Z_iYWU4JiLcJg2FsuC1PTUZE2B34VeJAoNtc=.075bca12-4ded-4f70-927c-c101b251f4a8@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>
 <_yyT1DE1iec1ea6SsjCE-wT6fBrkBrws9Co61mbukNs=.572220ae-c3a4-4363-864a-bcfcc51c0e73@github.com>
 <uHq1u2ACe0f76QG6LmzL46aajn0wo2ox2EsogAW5LYI=.4c5fd99f-46ba-4e47-8609-50a34cf3f2b1@github.com>
 <P-6pif9tfiiMosYNFbAc28c4CbsvbJfqnjenCFyP2Zw=.3d79147e-5f4b-49f9-9008-bdb3e8635156@github.com>
 <tos3Ywq_UcdsQhS7zEfbfYDNRm6XHCZcMow8zofnay4=.ef0f5ef8-1326-4c50-9dd9-7c606ee75977@github.com>
 <tg7Sv5jpg6jWaFIxwJyvw3_NgW361GA0UlQRf1ahB7U=.1e21b0d6-194a-4fb4-b3ff-2a483e2a51fb@github.com>
 <Y0G41VwQTVY516OakI6mFv3KNZ0CciWWKSU47WA7ScI=.15a26e6e-051d-4ef2-9efd-262b21441bc4@github.com>
 <hDtJcE8Z_iYWU4JiLcJg2FsuC1PTUZE2B34VeJAoNtc=.075bca12-4ded-4f70-927c-c101b251f4a8@github.com>
Message-ID: <bplXMKaL5kE7_6apzBPxugHPuPXU7jOSsdBz60ooN4s=.1515d5c2-17d8-4d56-9cd1-ad2b14d01acd@github.com>

On Thu, 16 Dec 2021 10:28:58 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> Yeah, if u refer this example page [https://bip.weizmann.ac.il/course/prog2/tutorial/uiswing/components/example-1dot4/ColorEditor.java], the interface is used for a cell in a table which has a button in turn invokes "JColorChooser" class. Which means the interface is used to store a particular value while the cell in is editor mode......?
>
> After going on through the example, what I felt is "Adds to CellEditor the extensions necessary to configure an editor in a tree" is little generic description than the updated PR Definition.

> > The object that implements the interface is not necessarily the editor for values. DefaultCellEditor is the perfect example: it's not an editor itself, it's not even a component, all it does is configures a delegate, a JComponent, which serves as the editor.
> 
> My thoughts about this. The object which implements the interface is always the "editor", even if it is not a component. I guess you are mixing it with the other classes like "JEditorPane/JTextField/etc".

No, I don't mix them. It's called CellEditor, however, it's actually CellEditor-provider: the implementation of the interface *provides a component* which is used as the editor for cell values. Or do I miss anything?

What I mean is that this editor object defines the implementation of how an instance of `JTable` acquires an editor component. In that sense it's an editor.

Probably, this part of the discussion is off-topic as we're discussing the terms.

Let's discuss the spec.

> The current spec:
> 
> > This interface defines the method any object that would like to be
> > an editor of values for components such as `JListBox`,
> > `JComboBox`, `JTree`, or `JTable`
> > needs to implement.
> 
> This means that the application may have some values/data stored in the JComboBox/JTree/JTable and the application may create a cell editor by implementing the TableCellEditor. That editor then could be used as a cell editor in the "main" JTable.

Why does the interface reference this? The application can store and display data in any component.

Moreover the statement in the Javadoc is wrong: This interface defines the method that can create an editor for `JTable` only. The returned component is of type `Component`, therefore it can be any component.

> So the next statement in the description of this PR is not completely right:
> 
> > "CellTableEditor Interface doesn't support JComboBox and JTree components"
> 
> The JComboBox and other classes do not have to implement/support that interface.

No, they don't. At the same time `TableCellEditor` interface can't be used to return a cell editor for `JComboBox` and for `JTree` components. These components use `ComboBoxEditor` and `TreeCellEditor` correspondingly.

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

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


From vdyakov at openjdk.java.net  Fri Dec 17 19:05:26 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Fri, 17 Dec 2021 19:05:26 GMT
Subject: RFR: 8278609: accessibility frame is misplaced on a secondary
 monitor on macOS
In-Reply-To: <az7KQunDs7VyirWZBUEeN35Ol2C12KSnql8utM3Hap8=.9a02baa4-f3f2-4838-927d-f24f8b2a26eb@github.com>
References: <az7KQunDs7VyirWZBUEeN35Ol2C12KSnql8utM3Hap8=.9a02baa4-f3f2-4838-927d-f24f8b2a26eb@github.com>
Message-ID: <U9m_-oDi2Cid63b4oD_hm-BeD0s7nVo88k8iK9DhS8A=.c4f292b2-b8d2-43ea-a3aa-fc31d1cfe2ff@github.com>

On Mon, 13 Dec 2021 15:33:48 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

> Use primary screen instead of window main screen to properly convert mouse position from screen coordinates to window ones.

please re-submit against 18 repo

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

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


From prr at openjdk.java.net  Fri Dec 17 19:05:28 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 17 Dec 2021 19:05:28 GMT
Subject: RFR: 8278050: Armenian text isn't rendered on macOS if text layout
 is performed
In-Reply-To: <AVc7kmSSNLQ4e7z9IVVhgrQ4D_XLvHZmhVAkbvU7Brs=.0d78378d-44c1-430c-be54-1dd13c552e38@github.com>
References: <j-u-5_YNo6tZ9HE0iDmQF5KcX26bpaGtR7jiehkNVO8=.5e2aaf73-7486-4e55-9d7a-684e7d7f9da2@github.com>
 <FwIjsE0K2xcvCUHoLg2P-lCcZzumYhYK3q7DIwR4oXM=.21785b5d-2ee8-4d7f-8047-7e4bfc7feac9@github.com>
 <mog38DarYTIQF7-X8Ou4MUCYefOYT8xkiGnBP-qA2zA=.24e2c771-c2f6-45bf-a631-1fdf6dfe77d6@github.com>
 <AVc7kmSSNLQ4e7z9IVVhgrQ4D_XLvHZmhVAkbvU7Brs=.0d78378d-44c1-430c-be54-1dd13c552e38@github.com>
Message-ID: <J052rdt0hZkOdbbhlYj9Za7W4HyFaAmvI7jUrF9VWAc=.ae08f1ca-11c9-462f-be85-843a0dc0c61d@github.com>

On Thu, 16 Dec 2021 05:35:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> I would like to clarify why we cannot merge the results of the availableFontFamilies and availableFonts?
>> 
>> We can do it, if everyone is OK with increasing the scope of the change, due to the following factors:
>> * The number of fonts advertised via `GraphicsEnvironment.getAllFonts` and `GraphicsEnvironment.getAvailableFontFamilyNames` will increase, so a potential Java application showing a font chooser combo-box will display more fonts there, than a native macOS application. Not sure whether that's a good or a bad thing, but that's a change in behaviour that will occur.
>> * As the number of loaded fonts will increase, the execution time of `CFontManager.loadNativeFonts` will also increase, introducing a certain regression in Java UI application startup time. Ideally, this should be fixed simultaneously, e.g. by adjusting `sun.font.FontFamily` logic to perform style resolution lazily (when the particular family is accessed), not at the time `loadNativeFonts` is executed.
>> * `[NSFontManager availableFonts]` returns the fonts in alphabetical order, while `NSFontManager availableMembersOfFontFamily:]` (used currently) uses font weight to sort the results. The order in which fonts are processed during `loadNativeFonts` impacts the resulting resolution of fonts into styles in `FontFamily`. So, to keep the currently used approach, an additional fonts sorting would need to be introduced - that can be done, e.g. as part of lazy resolution in `FontFamily` mentioned above.
>> 
>> Even though it can make sense to implement all of the above (which JetBrains Runtime already does), I'd rather not do everything in one go. For now, what I'd like to achieve is to switch to `CTFontCopyDefaultCascadeListForLanguages`-based font fallback, as mentioned above. And current change, while having a value of its own, is a necessary step towards that.
>> If OpenJDK will ever switch to using `[NSFontManager availableFonts]`, as a sole source of system fonts or in addition to `[NSFontManager availableFontFamilies]`, this change can just be reverted.
>
> Ok, let's investigate that possibility separately.

I have a plan to re-do a lot of this code. Things like lazily loading the fonts would be good since right now we take a big hit especially right after reboot . But we shouldn't be enumerating (to the API) fonts that are not enumerated in FontBook.
A tricky aspect is that we have had a couple of bugs like this where we are doing fall back essentially using the standard way of doing it that doesn't get as many glyphs as what you get from the JRS code.
Getting away from the JRS code is part of the idea but it needs to be done carefully.

I don't mind you looking into it (obviously not today) but equally I don't promise not to obsolete whatever you do with whatever I do ..

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

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


From aivanov at openjdk.java.net  Fri Dec 17 19:08:30 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 17 Dec 2021 19:08:30 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <bplXMKaL5kE7_6apzBPxugHPuPXU7jOSsdBz60ooN4s=.1515d5c2-17d8-4d56-9cd1-ad2b14d01acd@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>
 <_yyT1DE1iec1ea6SsjCE-wT6fBrkBrws9Co61mbukNs=.572220ae-c3a4-4363-864a-bcfcc51c0e73@github.com>
 <uHq1u2ACe0f76QG6LmzL46aajn0wo2ox2EsogAW5LYI=.4c5fd99f-46ba-4e47-8609-50a34cf3f2b1@github.com>
 <P-6pif9tfiiMosYNFbAc28c4CbsvbJfqnjenCFyP2Zw=.3d79147e-5f4b-49f9-9008-bdb3e8635156@github.com>
 <tos3Ywq_UcdsQhS7zEfbfYDNRm6XHCZcMow8zofnay4=.ef0f5ef8-1326-4c50-9dd9-7c606ee75977@github.com>
 <tg7Sv5jpg6jWaFIxwJyvw3_NgW361GA0UlQRf1ahB7U=.1e21b0d6-194a-4fb4-b3ff-2a483e2a51fb@github.com>
 <Y0G41VwQTVY516OakI6mFv3KNZ0CciWWKSU47WA7ScI=.15a26e6e-051d-4ef2-9efd-262b21441bc4@github.com>
 <hDtJcE8Z_iYWU4JiLcJg2FsuC1PTUZE2B34VeJAoNtc=.075bca12-4ded-4f70-927c-c101b251f4a8@github.com>
 <bplXMKaL5kE7_6apzBPxugHPuPXU7jOSsdBz60ooN4s=.1515d5c2-17d8-4d56-9cd1-ad2b14d01acd@github.com>
Message-ID: <xTEMQ3AMTexSH_m3q2TK2tAv9PlVvXLVgllbkQNQDac=.a11c18cd-19eb-48ec-ba7c-eea2b682682d@github.com>

On Fri, 17 Dec 2021 18:56:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> After going on through the example, what I felt is "Adds to CellEditor the extensions necessary to configure an editor in a tree" is little generic description than the updated PR Definition.
>
>> > The object that implements the interface is not necessarily the editor for values. DefaultCellEditor is the perfect example: it's not an editor itself, it's not even a component, all it does is configures a delegate, a JComponent, which serves as the editor.
>> 
>> My thoughts about this. The object which implements the interface is always the "editor", even if it is not a component. I guess you are mixing it with the other classes like "JEditorPane/JTextField/etc".
> 
> No, I don't mix them. It's called CellEditor, however, it's actually CellEditor-provider: the implementation of the interface *provides a component* which is used as the editor for cell values. Or do I miss anything?
> 
> What I mean is that this editor object defines the implementation of how an instance of `JTable` acquires an editor component. In that sense it's an editor.
> 
> Probably, this part of the discussion is off-topic as we're discussing the terms.
> 
> Let's discuss the spec.
> 
>> The current spec:
>> 
>> > This interface defines the method any object that would like to be
>> > an editor of values for components such as `JListBox`,
>> > `JComboBox`, `JTree`, or `JTable`
>> > needs to implement.
>> 
>> This means that the application may have some values/data stored in the JComboBox/JTree/JTable and the application may create a cell editor by implementing the TableCellEditor. That editor then could be used as a cell editor in the "main" JTable.
> 
> Why does the interface reference this? The application can store and display data in any component.
> 
> Moreover the statement in the Javadoc is wrong: This interface defines the method that can create an editor for `JTable` only. The returned component is of type `Component`, therefore it can be any component.
> 
>> So the next statement in the description of this PR is not completely right:
>> 
>> > "CellTableEditor Interface doesn't support JComboBox and JTree components"
>> 
>> The JComboBox and other classes do not have to implement/support that interface.
> 
> No, they don't. At the same time `TableCellEditor` interface can't be used to return a cell editor for `JComboBox` and for `JTree` components. These components use `ComboBoxEditor` and `TreeCellEditor` correspondingly.

> After going on through the example, what I felt is "Adds to CellEditor the extensions necessary to configure an editor in a tree" is little generic description than the updated PR Definition.

The interface is generic, so the generic description fits well.

I still find the proposed version quite hard to parse. In my first comment, I suggested rephrasing the Javadoc to make it clearer and easier to understand.

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

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


From prr at openjdk.java.net  Fri Dec 17 19:13:25 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 17 Dec 2021 19:13:25 GMT
Subject: RFR: 8278908: [macOS] Unexpected text normalization on pasting
 from clipboard
In-Reply-To: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
References: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
Message-ID: <o9VvsCo0Mm8G5pV1oFHpDhxtxURx9rxQ-XELls2fVFg=.92621698-8009-49c9-8ea3-5b84fa0a40a2@github.com>

On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The fix just removes the explicit normalization of text obtained from system clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS version.
> The same fix was performed in JetBrains Runtime by a user's request more than 4 years ago, and we didn't receive any
> related complaints from our users ever since.

I don't know much at all about this code and DnD / clipboard java->java, and java<->native and the differences per platform but I see an update to a test which very deliberately tests the behaviour you are affecting. And that test runs on all platforms but you are only updating macOS .. hmm. I'd like to know why. I'd also like to know that all the scenarios work on all platforms and also why someone previously was so sure the existing code was right ...

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

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


From asemenov at openjdk.java.net  Fri Dec 17 19:35:27 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Fri, 17 Dec 2021 19:35:27 GMT
Subject: [jdk18] Integrated: 8278604 SwingSet2 table demo does not have
 accessible description set for images
In-Reply-To: <MpzD5J0C_EuymSeZVLorPymbQH3QJe9LWmXVykE7_Bs=.8b1fdb8e-c3ab-4ed4-936e-0ae660742cf7@github.com>
References: <MpzD5J0C_EuymSeZVLorPymbQH3QJe9LWmXVykE7_Bs=.8b1fdb8e-c3ab-4ed4-936e-0ae660742cf7@github.com>
Message-ID: <IIuNF5b_yNLDp8udTueCNZzt9cIghlNWKBBh1EOs0MQ=.dd7883bc-8d48-4dca-bd6d-401e22877b80@github.com>

On Wed, 15 Dec 2021 12:43:40 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> SwingSet2 demo is often used to check accessibility for different Swing components and has some shortcomings. The major one is that images within the table demo do not have accessible description set which makes accessibility perform differently on different platforms when navigating the table with screen narrator enabled.
> 
> This is the next step after the solution [JDK-8277497](https://bugs.openjdk.java.net/browse/JDK-8277497), in which we forwarded the description from the icon into the label description so that this fix was possible.

This pull request has now been integrated.

Changeset: 8fbe1724
Author:    Artem Semenov <asemenov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/8fbe1724e0f783132a65c45503addad9d98a329e
Stats:     9 lines in 1 file changed: 9 ins; 0 del; 0 mod

8278604: SwingSet2 table demo does not have accessible description set for images
8278526: [macos] Screen reader reads SwingSet2 JTable row selection as null, dimmed row for last column

Reviewed-by: ant, kizune, pbansal

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

PR: https://git.openjdk.java.net/jdk18/pull/31


From dbatrak at openjdk.java.net  Fri Dec 17 20:16:30 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Fri, 17 Dec 2021 20:16:30 GMT
Subject: RFR: 8278908: [macOS] Unexpected text normalization on pasting
 from clipboard
In-Reply-To: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
References: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
Message-ID: <MXoEEzAlV9suy4iTDBMcRLA-LLdu562eyIkG7yA-BC8=.29caf22d-89c3-48e3-aada-b05270691d70@github.com>

On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The fix just removes the explicit normalization of text obtained from system clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS version.
> The same fix was performed in JetBrains Runtime by a user's request more than 4 years ago, and we didn't receive any
> related complaints from our users ever since.

The test doesn't check the normalization logic in `CDataTransferer.m`, it actually tests that the string is unchanged during transfer through clipboard. The test just prepares the initial string so that it won't be affected by the normalization.
So it looks like that normalization in test was added to make the test pass on all platforms, including macOS.
The test would pass even after the change I've made to `CDataTransferer.m`. I'm making a modification to it, so that it would now verify that even a non-normalized string passes through clipboard unchanged.
The test keeps passing on Windows, Linux and macOS after the change.

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

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


From prr at openjdk.java.net  Fri Dec 17 21:46:21 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 17 Dec 2021 21:46:21 GMT
Subject: RFR: 6496103: isFileHidingEnabled return false by default [v2]
In-Reply-To: <6ZrzvASjvTYEe1dazchVcggakWgIN_6-SFxCyHJdl58=.fc97f95f-6ba2-476c-835b-0850b533d5bb@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
 <6ZrzvASjvTYEe1dazchVcggakWgIN_6-SFxCyHJdl58=.fc97f95f-6ba2-476c-835b-0850b533d5bb@github.com>
Message-ID: <-r0KAdQiWUNyV7YEyvQADMreqAAoxy8tlVplIiN0Mts=.8d1c66c8-2b93-492c-bdcc-f6578beb78b4@github.com>

On Wed, 15 Dec 2021 06:29:43 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> The default value of this property is derived from native platform. The same is updated in the documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6496103: isFileHidingEnabled return false by default

src/java.desktop/share/classes/javax/swing/JFileChooser.java line 1416:

> 1414:      * Returns true if hidden files are not shown in the file chooser;
> 1415:      * otherwise, returns false. The default value of this property is derived
> 1416:      * from native Operating System, unless set explicitly by the programmer.

Is this true on all platforms ? The bug report seems concerned only about windows.
Should the wording be
"The default value of this property may be derived from the underlying operating system"

ie "is" -> "may be" (and some other slight wording change).

If we REALLY will always get it from the O/S, including on Linux, macOS and whatever else .. then it is OK otherwise the new wording would be better.

"unless set explicitly by the programmer."

hmm, well if you set it, it isn't the default, so there's no need to say that, is there ?

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

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


From aivanov at openjdk.java.net  Fri Dec 17 22:00:26 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 17 Dec 2021 22:00:26 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v9]
In-Reply-To: <49gYRPX_QAzZcEsFovkzHbBn2I28lXo-3fYDHmYSUD0=.cf6525da-c24b-406f-ad90-2eabcbd840c3@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <49gYRPX_QAzZcEsFovkzHbBn2I28lXo-3fYDHmYSUD0=.cf6525da-c24b-406f-ad90-2eabcbd840c3@github.com>
Message-ID: <xSFX3lZKbueEeWY3BZxQIT9ybhXONYy42qZoweM1Drg=.a099733f-5a1c-4c17-9d29-03fca162bd93@github.com>

On Fri, 10 Dec 2021 17:03:49 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a few more missing calls to LookAndFeel.uninstallColors

I see the problem: the constructors do not allow setting invalid values to the fields. This is what the *special version of JDK* refers to, the build where the checks for invalid values are removed from the constructors. It explains why the serialized form can't be obtained by writing an object out, it's impossible to create such an object.

I wonder if it's possible to modify the value of the field using reflection via `setAccessible(true)`. With strong encapsulation, it may not work. If it works, the objects with invalid can be serialized on the fly.

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

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


From prr at openjdk.java.net  Fri Dec 17 22:22:24 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 17 Dec 2021 22:22:24 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <fK3Su35ju9JGP1TQBYEpUdCgNU-1PGZLYf19HYyl3a0=.d0936a5f-cee9-4938-b366-b86a6c5203e7@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <fK3Su35ju9JGP1TQBYEpUdCgNU-1PGZLYf19HYyl3a0=.d0936a5f-cee9-4938-b366-b86a6c5203e7@github.com>
Message-ID: <kphUjUwBWGDu5rtgADWEqQP54jhhGvaI_e8YYCCfoaQ=.e69408d3-2dd4-4a94-8bbb-de9aed9a0a56@github.com>

On Thu, 9 Dec 2021 13:31:38 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> JListBox is invalid component. CellTableEditor Interface doesn't support JComboBox and JTree components. Hence its removed from Documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6465404: some problems in CellEditor related API docs

src/java.desktop/share/classes/javax/swing/table/TableCellEditor.java line 34:

> 32: /**
> 33:  * This interface defines the method any object that would like to be
> 34:  * an editor of values for the {@code JTable} component needs to implement.

"This interface must be implemented to provide an editor of cell values for a {@code JTable}" ?

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

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


From duke at openjdk.java.net  Mon Dec 20 06:51:26 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 20 Dec 2021 06:51:26 GMT
Subject: RFR: 6496103: isFileHidingEnabled return false by default [v2]
In-Reply-To: <-r0KAdQiWUNyV7YEyvQADMreqAAoxy8tlVplIiN0Mts=.8d1c66c8-2b93-492c-bdcc-f6578beb78b4@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
 <6ZrzvASjvTYEe1dazchVcggakWgIN_6-SFxCyHJdl58=.fc97f95f-6ba2-476c-835b-0850b533d5bb@github.com>
 <-r0KAdQiWUNyV7YEyvQADMreqAAoxy8tlVplIiN0Mts=.8d1c66c8-2b93-492c-bdcc-f6578beb78b4@github.com>
Message-ID: <8A0M2nAriO6kWE6BQ-D9eSpjLjfjkrvBFhgorV0wdjs=.cc7ad0cc-9377-4db5-9d80-84265ed8ff15@github.com>

On Fri, 17 Dec 2021 21:42:57 GMT, Phil Race <prr at openjdk.org> wrote:

> If we REALLY will always get it from the O/S, including on Linux, macOS and whatever else .. then it is OK otherwise the new wording would be better.

Haven't checked in Linux or macOS...... Yeah, I think no need to explicitly mention about setting it by programmer...... Sure will update the PR based on your feedback @prrace .......

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

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


From duke at openjdk.java.net  Mon Dec 20 06:54:56 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 20 Dec 2021 06:54:56 GMT
Subject: RFR: 6496103: isFileHidingEnabled return false by default [v3]
In-Reply-To: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
Message-ID: <hgUMCet8jzlF6nTqCeDTzq3XXMfM8R0jLaeONIYqkmI=.4fdfd154-55c7-4599-bf9b-6ac4626a509b@github.com>

> The default value of this property is derived from native platform. The same is updated in the documentation.

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

  6496103: isFileHidingEnabled return false by default

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6780/files
  - new: https://git.openjdk.java.net/jdk/pull/6780/files/f173600e..df57ab4f

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

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

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


From duke at openjdk.java.net  Mon Dec 20 09:34:30 2021
From: duke at openjdk.java.net (Aleksandr Veselov)
Date: Mon, 20 Dec 2021 09:34:30 GMT
Subject: RFR: 8278609: accessibility frame is misplaced on a secondary
 monitor on macOS
In-Reply-To: <az7KQunDs7VyirWZBUEeN35Ol2C12KSnql8utM3Hap8=.9a02baa4-f3f2-4838-927d-f24f8b2a26eb@github.com>
References: <az7KQunDs7VyirWZBUEeN35Ol2C12KSnql8utM3Hap8=.9a02baa4-f3f2-4838-927d-f24f8b2a26eb@github.com>
Message-ID: <xkoUPNo2-kSChMBJWPG-nmyqulZ2Brv6fSYL3ESlTIA=.d20be1cb-cdc6-4109-896a-4de24edee588@github.com>

On Mon, 13 Dec 2021 15:33:48 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

> Use primary screen instead of window main screen to properly convert mouse position from screen coordinates to window ones.

Changes moved to [jdk18/48](https://github.com/openjdk/jdk18/pull/48), closing

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

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


From duke at openjdk.java.net  Mon Dec 20 09:34:30 2021
From: duke at openjdk.java.net (Aleksandr Veselov)
Date: Mon, 20 Dec 2021 09:34:30 GMT
Subject: Withdrawn: 8278609: accessibility frame is misplaced on a secondary
 monitor on macOS
In-Reply-To: <az7KQunDs7VyirWZBUEeN35Ol2C12KSnql8utM3Hap8=.9a02baa4-f3f2-4838-927d-f24f8b2a26eb@github.com>
References: <az7KQunDs7VyirWZBUEeN35Ol2C12KSnql8utM3Hap8=.9a02baa4-f3f2-4838-927d-f24f8b2a26eb@github.com>
Message-ID: <03T8HbxApMW_RPqjyJkjJ7xaOWH-auPtt8KGKo41bp0=.7878f4e7-eedd-49d6-abe2-a27b9c58e426@github.com>

On Mon, 13 Dec 2021 15:33:48 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

> Use primary screen instead of window main screen to properly convert mouse position from screen coordinates to window ones.

This pull request has been closed without being integrated.

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

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


From duke at openjdk.java.net  Mon Dec 20 09:34:55 2021
From: duke at openjdk.java.net (Aleksandr Veselov)
Date: Mon, 20 Dec 2021 09:34:55 GMT
Subject: [jdk18] RFR: 8278609: accessibility frame is misplaced on a secondary
 monitor on macOS
Message-ID: <UdHK-t4SxlhzaxjfeDKUwkVBVaAXtwui1A4tZLUwBCY=.627edcc4-4030-405c-8cbc-71da7c3c14a7@github.com>

Use primary screen instead of window main screen to properly convert mouse position from screen coordinates to window ones.

Copy of [jdk/6815](https://github.com/openjdk/jdk/pull/6815)

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

Commit messages:
 - 8278609: accessibility frame is misplaced on a secondary monitor on macOS

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

PR: https://git.openjdk.java.net/jdk18/pull/48


From ant at openjdk.java.net  Mon Dec 20 09:34:56 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Mon, 20 Dec 2021 09:34:56 GMT
Subject: [jdk18] RFR: 8278609: accessibility frame is misplaced on a
 secondary monitor on macOS
In-Reply-To: <UdHK-t4SxlhzaxjfeDKUwkVBVaAXtwui1A4tZLUwBCY=.627edcc4-4030-405c-8cbc-71da7c3c14a7@github.com>
References: <UdHK-t4SxlhzaxjfeDKUwkVBVaAXtwui1A4tZLUwBCY=.627edcc4-4030-405c-8cbc-71da7c3c14a7@github.com>
Message-ID: <2R_cGjYxargTsThFSBMu93I-3BZIue3HTF1f_F93F7k=.0fea22a0-6d4d-4d07-8377-9b73e5d1691c@github.com>

On Mon, 20 Dec 2021 09:26:31 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

> Use primary screen instead of window main screen to properly convert mouse position from screen coordinates to window ones.
> 
> Copy of [jdk/6815](https://github.com/openjdk/jdk/pull/6815)

Marked as reviewed by ant (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/48


From myano at openjdk.java.net  Mon Dec 20 09:36:15 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 20 Dec 2021 09:36:15 GMT
Subject: RFR: 8277463: JFileChooser with Metal L&F doesn't show
 non-canonical UNC path in - Look in [v2]
In-Reply-To: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
References: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
Message-ID: <PDeNBGd9p-xat77BmOd_cxkOA0cR6wNAODfOByGnaYw=.0102439c-7d1d-4d93-9c36-3f0e4a9cf178@github.com>

> I would like to fix the bug reported in JDK-8277463.
> 
> As reporter's investigation, ShellFolder.getNormalizedFile() returns incorrect value for non-canonical Windows UNC path. getNormalizedFile() is used for symbolic link path, but Windows environment does not handle symbolic link. And, getCanonicalFile() returns correct path for a directory link in Windows which is made with `mklink` command. So getNormalizedFile() should perform to return getCanonicalFile() like WindowsFileChooserUI.addItem() at Windows environment.

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

  8277463: JFileChooser with Metal L&F doesn't show non-canonical UNC path in - Look in

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6796/files
  - new: https://git.openjdk.java.net/jdk/pull/6796/files/5775b5f6..3e163ff9

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

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

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


From myano at openjdk.java.net  Mon Dec 20 09:36:18 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 20 Dec 2021 09:36:18 GMT
Subject: RFR: 8277463: JFileChooser with Metal L&F doesn't show
 non-canonical UNC path in - Look in [v2]
In-Reply-To: <1APEWt6EfSMXZSLa9JNxgLwQpdtfpOBE1VBgXCUntxM=.83285e41-fd61-452d-b3bf-7da6ce4f432b@github.com>
References: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
 <1APEWt6EfSMXZSLa9JNxgLwQpdtfpOBE1VBgXCUntxM=.83285e41-fd61-452d-b3bf-7da6ce4f432b@github.com>
Message-ID: <T6_ck6kgpSKNJA2rgB-GtP5dnTpV02QWh7r583Sf-R8=.5fff3497-d130-450c-8c20-ba0a902396cc@github.com>

On Wed, 15 Dec 2021 03:50:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277463: JFileChooser with Metal L&F doesn't show non-canonical UNC path in - Look in
>
> test/jdk/javax/swing/JFileChooser/8277463/UNCFileChooserTest.java line 105:
> 
>> 103:             throw new RuntimeException("Enter the directory path to test.");
>> 104:         }
>> 105:         UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");
> 
> The test might be executed under some non-default L&F and switching it here might cause some issues for the instruction dialog which will not be updated to use the metal. So it is better to set metal at the start of the test.

I fixed the test as it was pointed out to me.

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

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


From myano at openjdk.java.net  Mon Dec 20 09:30:27 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 20 Dec 2021 09:30:27 GMT
Subject: RFR: 8277463: JFileChooser with Metal L&F doesn't show
 non-canonical UNC path in - Look in
In-Reply-To: <1APEWt6EfSMXZSLa9JNxgLwQpdtfpOBE1VBgXCUntxM=.83285e41-fd61-452d-b3bf-7da6ce4f432b@github.com>
References: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
 <1APEWt6EfSMXZSLa9JNxgLwQpdtfpOBE1VBgXCUntxM=.83285e41-fd61-452d-b3bf-7da6ce4f432b@github.com>
Message-ID: <Go3zzVlXdKhynAChTUwRcfeQn3Sf_2vypmj1daT2iJc=.6531b130-6bdb-441e-8a7d-0be396bb3c7a@github.com>

On Wed, 15 Dec 2021 22:58:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I would like to fix the bug reported in JDK-8277463.
>> 
>> As reporter's investigation, ShellFolder.getNormalizedFile() returns incorrect value for non-canonical Windows UNC path. getNormalizedFile() is used for symbolic link path, but Windows environment does not handle symbolic link. And, getCanonicalFile() returns correct path for a directory link in Windows which is made with `mklink` command. So getNormalizedFile() should perform to return getCanonicalFile() like WindowsFileChooserUI.addItem() at Windows environment.
>
> src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java line 301:
> 
>> 299:         if (f.equals(canonical) || OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
>> 300:             // path of f doesn't contain symbolic links
>> 301:             return canonical;
> 
> Is it possible that the code below was used when the "Libraries"  or some "virtual folders" were navigated?

Yes. I traced with debugger. 
Even after this fix, JFileChooser displays and can navigate "Libraries" and "Recent". The paths of these folders are expressed as "::{CLSID}", that can be handled correctly only with Win32ShellFolder class. And, if "Videos" is selected, the path is canonicalized. (e.g. C:\Users\User\Videos)

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

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


From ant at openjdk.java.net  Mon Dec 20 09:55:41 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Mon, 20 Dec 2021 09:55:41 GMT
Subject: [jdk18] RFR: 8278609: [macos] accessibility frame is misplaced on
 a secondary monitor on macOS
In-Reply-To: <UdHK-t4SxlhzaxjfeDKUwkVBVaAXtwui1A4tZLUwBCY=.627edcc4-4030-405c-8cbc-71da7c3c14a7@github.com>
References: <UdHK-t4SxlhzaxjfeDKUwkVBVaAXtwui1A4tZLUwBCY=.627edcc4-4030-405c-8cbc-71da7c3c14a7@github.com>
Message-ID: <fUVSKp1hl2Btezt4hlZ6o4BGS4ZdqIEZwGPSjsqYKZE=.26557678-f27c-4bf8-ba9c-a9299c6eca05@github.com>

On Mon, 20 Dec 2021 09:26:31 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

> Use primary screen instead of window main screen to properly convert mouse position from screen coordinates to window ones.
> 
> Copy of [jdk/6815](https://github.com/openjdk/jdk/pull/6815)

@azuev-java please review.

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

PR: https://git.openjdk.java.net/jdk18/pull/48


From duke at openjdk.java.net  Mon Dec 20 09:56:25 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 20 Dec 2021 09:56:25 GMT
Subject: Integrated: 6462028: MaskFormatter API documentation refers to
 getDisplayValue
In-Reply-To: <-SOfUt64IAtAG0_rLAwkmMCCd81ZaPuTuF5ORNYuIOs=.fd151cd5-71c7-4e21-bd62-aeec7d296e76@github.com>
References: <-SOfUt64IAtAG0_rLAwkmMCCd81ZaPuTuF5ORNYuIOs=.fd151cd5-71c7-4e21-bd62-aeec7d296e76@github.com>
Message-ID: <z-X1_MbXO_z6_MPiOpF--TTVAEw6J-caa42txst_hn0=.3e11bfbf-2e2a-4ae2-bced-bb9c86ee4017@github.com>

On Thu, 25 Nov 2021 09:54:47 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> MaskFormatter API doesn't have getDisplayValue method, hence removed from Documentation.

This pull request has now been integrated.

Changeset: 31fbb872
Author:    TejeshR13 <tejesh.r at oracle.com>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/31fbb8723e973d4217c80cccba90b2dceb6fa792
Stats:     9 lines in 1 file changed: 3 ins; 0 del; 6 mod

6462028: MaskFormatter API documentation refers to getDisplayValue

Reviewed-by: psadhukhan, aivanov, prr

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

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


From kizune at openjdk.java.net  Mon Dec 20 11:23:33 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 20 Dec 2021 11:23:33 GMT
Subject: [jdk18] RFR: 8278609: [macos] accessibility frame is misplaced on
 a secondary monitor on macOS
In-Reply-To: <UdHK-t4SxlhzaxjfeDKUwkVBVaAXtwui1A4tZLUwBCY=.627edcc4-4030-405c-8cbc-71da7c3c14a7@github.com>
References: <UdHK-t4SxlhzaxjfeDKUwkVBVaAXtwui1A4tZLUwBCY=.627edcc4-4030-405c-8cbc-71da7c3c14a7@github.com>
Message-ID: <8MagsvbqqWMhsN5uFkjwPOuHEjfd8hAqd7Loxtd28gw=.26d70cf0-06aa-4d33-84cb-f977e7f02544@github.com>

On Mon, 20 Dec 2021 09:26:31 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

> Use primary screen instead of window main screen to properly convert mouse position from screen coordinates to window ones.
> 
> Copy of [jdk/6815](https://github.com/openjdk/jdk/pull/6815)

Looks good.

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

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/48


From duke at openjdk.java.net  Mon Dec 20 11:44:34 2021
From: duke at openjdk.java.net (Aleksandr Veselov)
Date: Mon, 20 Dec 2021 11:44:34 GMT
Subject: [jdk18] Integrated: 8278609: [macos] accessibility frame is misplaced
 on a secondary monitor on macOS
In-Reply-To: <UdHK-t4SxlhzaxjfeDKUwkVBVaAXtwui1A4tZLUwBCY=.627edcc4-4030-405c-8cbc-71da7c3c14a7@github.com>
References: <UdHK-t4SxlhzaxjfeDKUwkVBVaAXtwui1A4tZLUwBCY=.627edcc4-4030-405c-8cbc-71da7c3c14a7@github.com>
Message-ID: <aGlV5h10oJpRGu1jl8EzjZQ5UQnFmSa_ZbQIx7odC4U=.7e371909-d67f-4e44-aed8-c54a19ee7846@github.com>

On Mon, 20 Dec 2021 09:26:31 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

> Use primary screen instead of window main screen to properly convert mouse position from screen coordinates to window ones.
> 
> Copy of [jdk/6815](https://github.com/openjdk/jdk/pull/6815)

This pull request has now been integrated.

Changeset: ad128284
Author:    Aleksandr Veselov <aleksandr.veselov at jetbrains.com>
Committer: Anton Tarasov <ant at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/ad1282842c5eefdad151afe6f4db97a09d643546
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8278609: [macos] accessibility frame is misplaced on a secondary monitor on macOS

Reviewed-by: ant, kizune

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

PR: https://git.openjdk.java.net/jdk18/pull/48


From serb at openjdk.java.net  Tue Dec 21 02:03:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 21 Dec 2021 02:03:15 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <xTEMQ3AMTexSH_m3q2TK2tAv9PlVvXLVgllbkQNQDac=.a11c18cd-19eb-48ec-ba7c-eea2b682682d@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>
 <_yyT1DE1iec1ea6SsjCE-wT6fBrkBrws9Co61mbukNs=.572220ae-c3a4-4363-864a-bcfcc51c0e73@github.com>
 <uHq1u2ACe0f76QG6LmzL46aajn0wo2ox2EsogAW5LYI=.4c5fd99f-46ba-4e47-8609-50a34cf3f2b1@github.com>
 <P-6pif9tfiiMosYNFbAc28c4CbsvbJfqnjenCFyP2Zw=.3d79147e-5f4b-49f9-9008-bdb3e8635156@github.com>
 <tos3Ywq_UcdsQhS7zEfbfYDNRm6XHCZcMow8zofnay4=.ef0f5ef8-1326-4c50-9dd9-7c606ee75977@github.com>
 <tg7Sv5jpg6jWaFIxwJyvw3_NgW361GA0UlQRf1ahB7U=.1e21b0d6-194a-4fb4-b3ff-2a483e2a51fb@github.com>
 <Y0G41VwQTVY516OakI6mFv3KNZ0CciWWKSU47WA7ScI=.15a26e6e-051d-4ef2-9efd-262b21441bc4@github.com>
 <hDtJcE8Z_iYWU4JiLcJg2FsuC1PTUZE2B34VeJAoNtc=.075bca12-4ded-4f70-927c-c101b251f4a8@github.com>
 <bplXMKaL5kE7_6apzBPxugHPuPXU7jOSsdBz60ooN4s=.1515d5c2-17d8-4d56-9cd1-ad2b14d01acd@github.com>
 <xTEMQ3AMTexSH_m3q2TK2tAv9PlVvXLVgll
 bkQNQDac=.a11c18cd-19eb-48ec-ba7c-eea2b682682d@github.com>
Message-ID: <PwMw_Em7_AoLxSptmqRA81cpFgLdCAWCKnE6QGGiXKA=.2d750d15-bb93-4f35-8a3e-856e1088a92d@github.com>

On Fri, 17 Dec 2021 19:04:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> > The object that implements the interface is not necessarily the editor for values. DefaultCellEditor is the perfect example: it's not an editor itself, it's not even a component, all it does is configures a delegate, a JComponent, which serves as the editor.
>>> 
>>> My thoughts about this. The object which implements the interface is always the "editor", even if it is not a component. I guess you are mixing it with the other classes like "JEditorPane/JTextField/etc".
>> 
>> No, I don't mix them. It's called CellEditor, however, it's actually CellEditor-provider: the implementation of the interface *provides a component* which is used as the editor for cell values. Or do I miss anything?
>> 
>> What I mean is that this editor object defines the implementation of how an instance of `JTable` acquires an editor component. In that sense it's an editor.
>> 
>> Probably, this part of the discussion is off-topic as we're discussing the terms.
>> 
>> Let's discuss the spec.
>> 
>>> The current spec:
>>> 
>>> > This interface defines the method any object that would like to be
>>> > an editor of values for components such as `JListBox`,
>>> > `JComboBox`, `JTree`, or `JTable`
>>> > needs to implement.
>>> 
>>> This means that the application may have some values/data stored in the JComboBox/JTree/JTable and the application may create a cell editor by implementing the TableCellEditor. That editor then could be used as a cell editor in the "main" JTable.
>> 
>> Why does the interface reference this? The application can store and display data in any component.
>> 
>> Moreover the statement in the Javadoc is wrong: This interface defines the method that can create an editor for `JTable` only. The returned component is of type `Component`, therefore it can be any component.
>> 
>>> So the next statement in the description of this PR is not completely right:
>>> 
>>> > "CellTableEditor Interface doesn't support JComboBox and JTree components"
>>> 
>>> The JComboBox and other classes do not have to implement/support that interface.
>> 
>> No, they don't. At the same time `TableCellEditor` interface can't be used to return a cell editor for `JComboBox` and for `JTree` components. These components use `ComboBoxEditor` and `TreeCellEditor` correspondingly.
>
>> After going on through the example, what I felt is "Adds to CellEditor the extensions necessary to configure an editor in a tree" is little generic description than the updated PR Definition.
> 
> The interface is generic, so the generic description fits well.
> 
> I still find the proposed version quite hard to parse. In my first comment, I suggested rephrasing the Javadoc to make it clearer and easier to understand.

> No, they don't. At the same time `TableCellEditor` interface can't be used to return a cell editor for `JComboBox` and for `JTree` components. These components use `ComboBoxEditor` and `TreeCellEditor` correspondingly.

Right the TableCellEditor should not be used as a JComboBox/JTree editor, it is only for JTable. But the objects implemented TableCellEditor interface can be used to modify the values stored as the JComboBox/JTree when the user edits the cell of the table. So the user selects the cell -> the TableCellEditor is activated for editing that cell -> if the data for the cell may be stored as a list then the JComboBox could be shown -> the user may change/edit the current value of the cell using JComboBox and its values? And the list of components in the spec is just an example of what components can be used by the TableCellEditor.

At least this is how I read it, might be wrong.

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

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


From serb at openjdk.java.net  Tue Dec 21 05:31:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 21 Dec 2021 05:31:16 GMT
Subject: RFR: 8277463: JFileChooser with Metal L&F doesn't show
 non-canonical UNC path in - Look in [v2]
In-Reply-To: <T6_ck6kgpSKNJA2rgB-GtP5dnTpV02QWh7r583Sf-R8=.5fff3497-d130-450c-8c20-ba0a902396cc@github.com>
References: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
 <1APEWt6EfSMXZSLa9JNxgLwQpdtfpOBE1VBgXCUntxM=.83285e41-fd61-452d-b3bf-7da6ce4f432b@github.com>
 <T6_ck6kgpSKNJA2rgB-GtP5dnTpV02QWh7r583Sf-R8=.5fff3497-d130-450c-8c20-ba0a902396cc@github.com>
Message-ID: <EzgzwF2UBALTquK53lMx3zFJ5WAjr6aVdVmknJzto5k=.5808613e-7df4-4483-b364-18102b7ce285@github.com>

On Mon, 20 Dec 2021 09:32:24 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/8277463/UNCFileChooserTest.java line 105:
>> 
>>> 103:             throw new RuntimeException("Enter the directory path to test.");
>>> 104:         }
>>> 105:         UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");
>> 
>> The test might be executed under some non-default L&F and switching it here might cause some issues for the instruction dialog which will not be updated to use the metal. So it is better to set metal at the start of the test.
>
> I fixed the test as it was pointed out to me.

Now it cannot be compiled due to "unreported exception java.lang.ClassNotFoundException; must be caught or declared to be thrown" from the setLookAndFeel(); Note that the new version still has a race, the invokeLater/setLookAndFeel can be executed later than the code in the showOpenDialog(), so the code in showOpenDialog may use the wrong L&F properties, can we move the showOpenDialog to the EDT as well?

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

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


From aivanov at openjdk.java.net  Tue Dec 21 15:28:50 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 21 Dec 2021 15:28:50 GMT
Subject: [jdk18] RFR: 8278472: Invalid value set to CANDIDATEFORM structure
Message-ID: <erLwxQNzoVktLmhb-8HllHRwNwUWzKXkZ9VbL-yHFpg=.d74d8049-6255-472a-8ff2-ac4625fba3a6@github.com>

According to the Windows API reference, `dwStyle` of [`CANDIDATEFORM`](https://docs.microsoft.com/en-us/windows/win32/api/imm/ns-imm-candidateform) structure should be set to `CFS_CANDIDATEPOS` or `CFS_EXCLUDE`. So, `CFS_POINT` is wrong here.

There are two instances in `AwtComponent::SetCandidateWindow` in [`awt_Component.cpp`](https://github.com/openjdk/jdk/blob/f90425a1cbbc686045c87086af586e62f05f6c49/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3914) where the incorrect value is used.

I've created the PR for jdk18 as it's a low-risk fix. If it's inappropriate at this time, I'll open the PR for mainline jdk.

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

Commit messages:
 - 8278472: Invalid value set to CANDIDATEFORM structure

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

PR: https://git.openjdk.java.net/jdk18/pull/54


From jwilhelm at openjdk.java.net  Tue Dec 21 19:59:51 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 21 Dec 2021 19:59:51 GMT
Subject: RFR: Merge jdk18
Message-ID: <2qAXnV7AsRJ0Z5Of9gkLOHIACVFGRfrl3MVhJsfpSew=.b02d2da2-3ce5-497d-a979-4e602c3834be@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge
 - 8278627: Shenandoah: TestHeapDump test failed
 - 8279074: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macosx-aarch64
 - 8278044: ObjectInputStream methods invoking the OIF.CFG.getSerialFilterFactory() silent about error cases.
 - 8278087: Deserialization filter and filter factory property error reporting under specified
 - 8279011: JFR: JfrChunkWriter incorrectly handles int64_t chunk size as size_t
 - 8274323: compiler/codegen/aes/TestAESMain.java failed with "Error: invalid offset: -1434443640" after 8273297
 - 8278609: [macos] accessibility frame is misplaced on a secondary monitor on macOS
 - 8278413: C2 crash when allocating array of size too large
 - 8278970: [macos] SigningPackageTest is failed with runtime exception
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/f31dead6...d5d5bad9

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

Changes: https://git.openjdk.java.net/jdk/pull/6911/files
  Stats: 1086 lines in 80 files changed: 695 ins; 107 del; 284 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6911.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6911/head:pull/6911

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


From aivanov at openjdk.java.net  Tue Dec 21 20:39:16 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 21 Dec 2021 20:39:16 GMT
Subject: RFR: 6496103: isFileHidingEnabled return false by default [v3]
In-Reply-To: <hgUMCet8jzlF6nTqCeDTzq3XXMfM8R0jLaeONIYqkmI=.4fdfd154-55c7-4599-bf9b-6ac4626a509b@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
 <hgUMCet8jzlF6nTqCeDTzq3XXMfM8R0jLaeONIYqkmI=.4fdfd154-55c7-4599-bf9b-6ac4626a509b@github.com>
Message-ID: <TtPdKJiqDdCSd2xiwIJiFdwBRHRxoUctD6xUWCP8dH8=.9d5c320d-a405-40af-b565-9c431165bee6@github.com>

On Mon, 20 Dec 2021 06:54:56 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> The default value of this property is derived from native platform. The same is updated in the documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6496103: isFileHidingEnabled return false by default

src/java.desktop/share/classes/javax/swing/JFileChooser.java line 1416:

> 1414:      * Returns true if hidden files are not shown in the file chooser;
> 1415:      * otherwise, returns false. The default value of this property may be
> 1416:      * derived from the underlying Operating System.

Should true and false be marked up as `{@code true}` and `{@code false}`?
Probably not, for consistency with other methods in the JFileChooser class.

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

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


From aivanov at openjdk.java.net  Tue Dec 21 21:04:22 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 21 Dec 2021 21:04:22 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <PwMw_Em7_AoLxSptmqRA81cpFgLdCAWCKnE6QGGiXKA=.2d750d15-bb93-4f35-8a3e-856e1088a92d@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>
 <_yyT1DE1iec1ea6SsjCE-wT6fBrkBrws9Co61mbukNs=.572220ae-c3a4-4363-864a-bcfcc51c0e73@github.com>
 <uHq1u2ACe0f76QG6LmzL46aajn0wo2ox2EsogAW5LYI=.4c5fd99f-46ba-4e47-8609-50a34cf3f2b1@github.com>
 <P-6pif9tfiiMosYNFbAc28c4CbsvbJfqnjenCFyP2Zw=.3d79147e-5f4b-49f9-9008-bdb3e8635156@github.com>
 <tos3Ywq_UcdsQhS7zEfbfYDNRm6XHCZcMow8zofnay4=.ef0f5ef8-1326-4c50-9dd9-7c606ee75977@github.com>
 <tg7Sv5jpg6jWaFIxwJyvw3_NgW361GA0UlQRf1ahB7U=.1e21b0d6-194a-4fb4-b3ff-2a483e2a51fb@github.com>
 <Y0G41VwQTVY516OakI6mFv3KNZ0CciWWKSU47WA7ScI=.15a26e6e-051d-4ef2-9efd-262b21441bc4@github.com>
 <hDtJcE8Z_iYWU4JiLcJg2FsuC1PTUZE2B34VeJAoNtc=.075bca12-4ded-4f70-927c-c101b251f4a8@github.com>
 <bplXMKaL5kE7_6apzBPxugHPuPXU7jOSsdBz60ooN4s=.1515d5c2-17d8-4d56-9cd1-ad2b14d01acd@github.com>
 <xTEMQ3AMTexSH_m3q2TK2tAv9PlVvXLVgll
 bkQNQDac=.a11c18cd-19eb-48ec-ba7c-eea2b682682d@github.com>
 <PwMw_Em7_AoLxSptmqRA81cpFgLdCAWCKnE6QGGiXKA=.2d750d15-bb93-4f35-8a3e-856e1088a92d@github.com>
Message-ID: <YQGC2t2uXMgorcovl6sZEXySRvH_DLDwj_z8gjAYtJ8=.3ae80f8e-5ee8-4e78-9a3c-0532ebdeb26d@github.com>

On Tue, 21 Dec 2021 02:00:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> After going on through the example, what I felt is "Adds to CellEditor the extensions necessary to configure an editor in a tree" is little generic description than the updated PR Definition.
>> 
>> The interface is generic, so the generic description fits well.
>> 
>> I still find the proposed version quite hard to parse. In my first comment, I suggested rephrasing the Javadoc to make it clearer and easier to understand.
>
>> No, they don't. At the same time `TableCellEditor` interface can't be used to return a cell editor for `JComboBox` and for `JTree` components. These components use `ComboBoxEditor` and `TreeCellEditor` correspondingly.
> 
> Right the TableCellEditor should not be used as a JComboBox/JTree editor, it is only for JTable. But the objects implemented TableCellEditor interface can be used to modify the values stored as the JComboBox/JTree when the user edits the cell of the table. So the user selects the cell -> the TableCellEditor is activated for editing that cell -> if the data for the cell may be stored as a list then the JComboBox could be shown -> the user may change/edit the current value of the cell using JComboBox and its values? And the list of components in the spec is just an example of what components can be used by the TableCellEditor.
> 
> At least this is how I read it, might be wrong.

I agree it probably referred to components which can be used as an editor. `DefaultEditorCell` supports three components: `JCheckBox`, `JComboBox`, and `JTextField`.

> But the objects implemented TableCellEditor interface can be used to modify the values stored as the JComboBox/JTree when the user edits the cell of the table.

And this just adds to the confusion rather than clarifies the purpose of the interface.

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

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


From aivanov at openjdk.java.net  Tue Dec 21 21:16:18 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 21 Dec 2021 21:16:18 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <kphUjUwBWGDu5rtgADWEqQP54jhhGvaI_e8YYCCfoaQ=.e69408d3-2dd4-4a94-8bbb-de9aed9a0a56@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <fK3Su35ju9JGP1TQBYEpUdCgNU-1PGZLYf19HYyl3a0=.d0936a5f-cee9-4938-b366-b86a6c5203e7@github.com>
 <kphUjUwBWGDu5rtgADWEqQP54jhhGvaI_e8YYCCfoaQ=.e69408d3-2dd4-4a94-8bbb-de9aed9a0a56@github.com>
Message-ID: <3l3-MvcdKypoW9KMcKQDyk5jBw_9OEjfOWBkRDr7wpw=.b84d6330-e300-4601-960b-0ca43996f663@github.com>

On Fri, 17 Dec 2021 22:19:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6465404: some problems in CellEditor related API docs
>
> src/java.desktop/share/classes/javax/swing/table/TableCellEditor.java line 34:
> 
>> 32: /**
>> 33:  * This interface defines the method any object that would like to be
>> 34:  * an editor of values for the {@code JTable} component needs to implement.
> 
> "This interface must be implemented to provide an editor of cell values for a {@code JTable}" ?

Clear and to the point.

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

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


From aivanov at openjdk.java.net  Tue Dec 21 21:26:24 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 21 Dec 2021 21:26:24 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <3l3-MvcdKypoW9KMcKQDyk5jBw_9OEjfOWBkRDr7wpw=.b84d6330-e300-4601-960b-0ca43996f663@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <fK3Su35ju9JGP1TQBYEpUdCgNU-1PGZLYf19HYyl3a0=.d0936a5f-cee9-4938-b366-b86a6c5203e7@github.com>
 <kphUjUwBWGDu5rtgADWEqQP54jhhGvaI_e8YYCCfoaQ=.e69408d3-2dd4-4a94-8bbb-de9aed9a0a56@github.com>
 <3l3-MvcdKypoW9KMcKQDyk5jBw_9OEjfOWBkRDr7wpw=.b84d6330-e300-4601-960b-0ca43996f663@github.com>
Message-ID: <gXwvopkmNueoEz1tPHpeQhaDYxnkwKb8-DHDiJiS4GQ=.5a4055ca-04a5-446a-9b94-924fa591074a@github.com>

On Tue, 21 Dec 2021 21:12:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/table/TableCellEditor.java line 34:
>> 
>>> 32: /**
>>> 33:  * This interface defines the method any object that would like to be
>>> 34:  * an editor of values for the {@code JTable} component needs to implement.
>> 
>> "This interface must be implemented to provide an editor of cell values for a {@code JTable}" ?
>
> Clear and to the point.

I wonder if it makes sense to update the Javadoc for `TreeCellEditor` for consistency.

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

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


From aivanov at openjdk.java.net  Tue Dec 21 21:26:25 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 21 Dec 2021 21:26:25 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <YQGC2t2uXMgorcovl6sZEXySRvH_DLDwj_z8gjAYtJ8=.3ae80f8e-5ee8-4e78-9a3c-0532ebdeb26d@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>
 <_yyT1DE1iec1ea6SsjCE-wT6fBrkBrws9Co61mbukNs=.572220ae-c3a4-4363-864a-bcfcc51c0e73@github.com>
 <uHq1u2ACe0f76QG6LmzL46aajn0wo2ox2EsogAW5LYI=.4c5fd99f-46ba-4e47-8609-50a34cf3f2b1@github.com>
 <P-6pif9tfiiMosYNFbAc28c4CbsvbJfqnjenCFyP2Zw=.3d79147e-5f4b-49f9-9008-bdb3e8635156@github.com>
 <tos3Ywq_UcdsQhS7zEfbfYDNRm6XHCZcMow8zofnay4=.ef0f5ef8-1326-4c50-9dd9-7c606ee75977@github.com>
 <tg7Sv5jpg6jWaFIxwJyvw3_NgW361GA0UlQRf1ahB7U=.1e21b0d6-194a-4fb4-b3ff-2a483e2a51fb@github.com>
 <Y0G41VwQTVY516OakI6mFv3KNZ0CciWWKSU47WA7ScI=.15a26e6e-051d-4ef2-9efd-262b21441bc4@github.com>
 <hDtJcE8Z_iYWU4JiLcJg2FsuC1PTUZE2B34VeJAoNtc=.075bca12-4ded-4f70-927c-c101b251f4a8@github.com>
 <bplXMKaL5kE7_6apzBPxugHPuPXU7jOSsdBz60ooN4s=.1515d5c2-17d8-4d56-9cd1-ad2b14d01acd@github.com>
 <xTEMQ3AMTexSH_m3q2TK2tAv9PlVvXLVgll
 bkQNQDac=.a11c18cd-19eb-48ec-ba7c-eea2b682682d@github.com>
 <PwMw_Em7_AoLxSptmqRA81cpFgLdCAWCKnE6QGGiXKA=.2d750d15-bb93-4f35-8a3e-856e1088a92d@github.com>
 <YQGC2t2uXMgorcovl6sZEXySRvH_DLDwj_z8gjAYtJ8=.3ae80f8e-5ee8-4e78-9a3c-0532ebdeb26d@github.com>
Message-ID: <Jb1zrYEqMl8cfElZshOSBPBexEJFz_ube6QKi5f_n0A=.436fdaad-4dfe-46f6-b668-eba686932e90@github.com>

On Tue, 21 Dec 2021 21:01:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> No, they don't. At the same time `TableCellEditor` interface can't be used to return a cell editor for `JComboBox` and for `JTree` components. These components use `ComboBoxEditor` and `TreeCellEditor` correspondingly.
>> 
>> Right the TableCellEditor should not be used as a JComboBox/JTree editor, it is only for JTable. But the objects implemented TableCellEditor interface can be used to modify the values stored as the JComboBox/JTree when the user edits the cell of the table. So the user selects the cell -> the TableCellEditor is activated for editing that cell -> if the data for the cell may be stored as a list then the JComboBox could be shown -> the user may change/edit the current value of the cell using JComboBox and its values? And the list of components in the spec is just an example of what components can be used by the TableCellEditor.
>> 
>> At least this is how I read it, might be wrong.
>
> I agree it probably referred to components which can be used as an editor. `DefaultEditorCell` supports three components: `JCheckBox`, `JComboBox`, and `JTextField`.
> 
>> But the objects implemented TableCellEditor interface can be used to modify the values stored as the JComboBox/JTree when the user edits the cell of the table.
> 
> And this just adds to the confusion rather than clarifies the purpose of the interface.

In fact, the `CellEditor` interface describes how the interface can be used for `JTable` and `JTree` and gives `JTextField`, `JCheckBox`, `JComboBox` as the examples of specific editors.

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

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


From aivanov at openjdk.java.net  Tue Dec 21 21:30:13 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 21 Dec 2021 21:30:13 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <fK3Su35ju9JGP1TQBYEpUdCgNU-1PGZLYf19HYyl3a0=.d0936a5f-cee9-4938-b366-b86a6c5203e7@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <fK3Su35ju9JGP1TQBYEpUdCgNU-1PGZLYf19HYyl3a0=.d0936a5f-cee9-4938-b366-b86a6c5203e7@github.com>
Message-ID: <ITpG-N5Y3CEzdN_vYEL88IILX0T5RIyxwkQajXTrooQ=.e2170157-156d-40ca-916d-21f090b4026c@github.com>

On Thu, 9 Dec 2021 13:31:38 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> JListBox is invalid component. CellTableEditor Interface doesn't support JComboBox and JTree components. Hence its removed from Documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6465404: some problems in CellEditor related API docs

Should we add `@see javax.swing.JTable` to the Javadoc?

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

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


From jwilhelm at openjdk.java.net  Tue Dec 21 22:02:00 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 21 Dec 2021 22:02:00 GMT
Subject: RFR: Merge jdk18 [v2]
In-Reply-To: <2qAXnV7AsRJ0Z5Of9gkLOHIACVFGRfrl3MVhJsfpSew=.b02d2da2-3ce5-497d-a979-4e602c3834be@github.com>
References: <2qAXnV7AsRJ0Z5Of9gkLOHIACVFGRfrl3MVhJsfpSew=.b02d2da2-3ce5-497d-a979-4e602c3834be@github.com>
Message-ID: <06_kDiLlkp6QNtnHGLkuV7TxzucQtDwRaGLnjWX0dpM=.a14aed52-214c-4723-be0c-6bf07ef3a6e0@github.com>

> Forwardport JDK 18 -> JDK 19

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

 - Merge
 - 8279043: Some Security Exception Messages Miss Spaces
   
   Reviewed-by: weijun
 - 8278793: Interpreter(x64) intrinsify Thread.currentThread()
   
   Reviewed-by: rkennke, dcubed, dholmes
 - 8278044: ObjectInputStream methods invoking the OIF.CFG.getSerialFilterFactory() silent about error cases.
   
   Reviewed-by: lancea, bpb
 - 8278087: Deserialization filter and filter factory property error reporting under specified
   
   Reviewed-by: lancea, bpb
 - 8278917: Use Prev Bitmap for recording evac failed objects
   
   Reviewed-by: ayang, mli, tschatzl
 - 8277893: Arraycopy stress tests
   
   Reviewed-by: kvn, mli
 - 8278893: Parallel: Remove GCWorkerDelayMillis
   
   Reviewed-by: ayang, mli
 - 8278953: Clarify Class.getDeclaredConstructor specification
   
   Reviewed-by: mchung, alanb
 - 8277100: Dynamic dump can inadvertently overwrite default CDS archive
   
   Reviewed-by: iklam, minqi, dholmes
 - ... and 86 more: https://git.openjdk.java.net/jdk/compare/1128674d...d5d5bad9

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

Changes: https://git.openjdk.java.net/jdk/pull/6911/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6911&range=01
  Stats: 18631 lines in 509 files changed: 14435 ins; 3002 del; 1194 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6911.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6911/head:pull/6911

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


From jwilhelm at openjdk.java.net  Tue Dec 21 22:02:03 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 21 Dec 2021 22:02:03 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <2qAXnV7AsRJ0Z5Of9gkLOHIACVFGRfrl3MVhJsfpSew=.b02d2da2-3ce5-497d-a979-4e602c3834be@github.com>
References: <2qAXnV7AsRJ0Z5Of9gkLOHIACVFGRfrl3MVhJsfpSew=.b02d2da2-3ce5-497d-a979-4e602c3834be@github.com>
Message-ID: <TnCXLVYvZ6SiDvL3L7DRxa_QvPaRL5uUITCHiS9QCsM=.e6e56e39-bf83-40f9-a83c-be5cda06fce3@github.com>

On Tue, 21 Dec 2021 19:50:51 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 803cb8a7
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/803cb8a76827a21fcf9e033b4ca6a777c509169b
Stats:     1086 lines in 80 files changed: 695 ins; 107 del; 284 mod

Merge

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

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


From tnakamura at openjdk.java.net  Wed Dec 22 01:40:26 2021
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Wed, 22 Dec 2021 01:40:26 GMT
Subject: RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese
 characters were garbled [v3]
In-Reply-To: <wtw6CL7UmKW6QM67dWNhZNGz2N1dQOvVs_-0w57iKao=.9c965195-4343-48b4-a8b0-65d75a38da23@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
 <wtw6CL7UmKW6QM67dWNhZNGz2N1dQOvVs_-0w57iKao=.9c965195-4343-48b4-a8b0-65d75a38da23@github.com>
Message-ID: <weNmBxHYfA2leWwlTvhJCCA7zLv29j9hh2wba0leBNA=.25e39ba2-5ead-4556-af96-171202a29686@github.com>

On Thu, 21 Oct 2021 00:57:47 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> Hi,
>> 
>> Could you review the fix?
>> When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts.
>> 
>> The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn.
>
> Toshio Nakamura has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
>  - revert previous proposal
>  - Merge branch 'master' into 8240756
>  - 2nd proposal
>  - Revert previous change
>  - Merge branch 'master' into 8240756
>    merge master
>  - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled

(Adding comment to keep this PR active.)
This fix tries to fill a gap between a native API and Composite font, since the native API can work for a single font with GlyphVector. This fix switches an appropriate font from the font list of Composite font of Java codes.
I appreciate any comments or advices.

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

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


From duke at openjdk.java.net  Wed Dec 22 10:54:17 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 22 Dec 2021 10:54:17 GMT
Subject: RFR: 6496103: isFileHidingEnabled return false by default [v3]
In-Reply-To: <TtPdKJiqDdCSd2xiwIJiFdwBRHRxoUctD6xUWCP8dH8=.9d5c320d-a405-40af-b565-9c431165bee6@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
 <hgUMCet8jzlF6nTqCeDTzq3XXMfM8R0jLaeONIYqkmI=.4fdfd154-55c7-4599-bf9b-6ac4626a509b@github.com>
 <TtPdKJiqDdCSd2xiwIJiFdwBRHRxoUctD6xUWCP8dH8=.9d5c320d-a405-40af-b565-9c431165bee6@github.com>
Message-ID: <RcBlPEhwF1BnS5I84pv5pBrwhv_-0nFicbLR_09XEoU=.e4459f71-68e0-4263-8739-5004f25341ab@github.com>

On Tue, 21 Dec 2021 20:35:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6496103: isFileHidingEnabled return false by default
>
> src/java.desktop/share/classes/javax/swing/JFileChooser.java line 1416:
> 
>> 1414:      * Returns true if hidden files are not shown in the file chooser;
>> 1415:      * otherwise, returns false. The default value of this property may be
>> 1416:      * derived from the underlying Operating System.
> 
> Should true and false be marked up as `{@code true}` and `{@code false}`?
> Probably not, for consistency with other methods in the JFileChooser class.

@aivanov-jdk Yeah, could have done that, but still lot of places in the same file doesn't have the consistency, so taking it up in another PR will be better I guess....

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

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


From myano at openjdk.java.net  Wed Dec 22 11:02:22 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 22 Dec 2021 11:02:22 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails [v2]
In-Reply-To: <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>
 <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
Message-ID: <jlcsnW7WM-DJyjOh3V1OJb0NJURoTq4URH3ack_ZIlA=.5686ee85-6bbf-44e5-ae9b-5e21169af849@github.com>

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

>> Masanori Yano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - Merge branch 'master' of https://github.com/masyano/jdk into 7001973
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>
> I'll check it, let me some time.

@mrserb Could you please review the above comments?

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

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


From duke at openjdk.java.net  Wed Dec 22 11:13:56 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 22 Dec 2021 11:13:56 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v6]
In-Reply-To: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
Message-ID: <WRC9Z9m84KB7ziLtEnd7X9qV27QZpc78F4fOvGGkkXs=.e5dc3308-d589-4a65-a82e-9d06073e33f8@github.com>

> JListBox is invalid component. CellTableEditor Interface doesn't support JComboBox and JTree components. Hence its removed from Documentation.

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

  6465404: some problems in CellEditor related API docs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6608/files
  - new: https://git.openjdk.java.net/jdk/pull/6608/files/d411b906..9face9ec

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

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

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


From duke at openjdk.java.net  Wed Dec 22 11:13:57 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 22 Dec 2021 11:13:57 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <gXwvopkmNueoEz1tPHpeQhaDYxnkwKb8-DHDiJiS4GQ=.5a4055ca-04a5-446a-9b94-924fa591074a@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <fK3Su35ju9JGP1TQBYEpUdCgNU-1PGZLYf19HYyl3a0=.d0936a5f-cee9-4938-b366-b86a6c5203e7@github.com>
 <kphUjUwBWGDu5rtgADWEqQP54jhhGvaI_e8YYCCfoaQ=.e69408d3-2dd4-4a94-8bbb-de9aed9a0a56@github.com>
 <3l3-MvcdKypoW9KMcKQDyk5jBw_9OEjfOWBkRDr7wpw=.b84d6330-e300-4601-960b-0ca43996f663@github.com>
 <gXwvopkmNueoEz1tPHpeQhaDYxnkwKb8-DHDiJiS4GQ=.5a4055ca-04a5-446a-9b94-924fa591074a@github.com>
Message-ID: <SwJ1sFFB308D61VW1jMEONtbGGQgE0YnXNf0ceD0DQg=.56bfdfc5-a17b-4597-9fa6-c86ea6ab6ea5@github.com>

On Tue, 21 Dec 2021 21:23:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Clear and to the point.
>
> I wonder if it makes sense to update the Javadoc for `TreeCellEditor` for consistency.

Yeah, this description is clear and to the point. Will updated the PR.

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

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


From duke at openjdk.java.net  Wed Dec 22 11:17:16 2021
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 22 Dec 2021 11:17:16 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v6]
In-Reply-To: <Jb1zrYEqMl8cfElZshOSBPBexEJFz_ube6QKi5f_n0A=.436fdaad-4dfe-46f6-b668-eba686932e90@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <70BX5SXk_YBwACbsXf3aMS4KytQQoxkwNhXuuRgOYgo=.4e15bbad-05b2-456a-965d-b9c20b9c6303@github.com>
 <_yyT1DE1iec1ea6SsjCE-wT6fBrkBrws9Co61mbukNs=.572220ae-c3a4-4363-864a-bcfcc51c0e73@github.com>
 <uHq1u2ACe0f76QG6LmzL46aajn0wo2ox2EsogAW5LYI=.4c5fd99f-46ba-4e47-8609-50a34cf3f2b1@github.com>
 <P-6pif9tfiiMosYNFbAc28c4CbsvbJfqnjenCFyP2Zw=.3d79147e-5f4b-49f9-9008-bdb3e8635156@github.com>
 <tos3Ywq_UcdsQhS7zEfbfYDNRm6XHCZcMow8zofnay4=.ef0f5ef8-1326-4c50-9dd9-7c606ee75977@github.com>
 <tg7Sv5jpg6jWaFIxwJyvw3_NgW361GA0UlQRf1ahB7U=.1e21b0d6-194a-4fb4-b3ff-2a483e2a51fb@github.com>
 <Y0G41VwQTVY516OakI6mFv3KNZ0CciWWKSU47WA7ScI=.15a26e6e-051d-4ef2-9efd-262b21441bc4@github.com>
 <hDtJcE8Z_iYWU4JiLcJg2FsuC1PTUZE2B34VeJAoNtc=.075bca12-4ded-4f70-927c-c101b251f4a8@github.com>
 <bplXMKaL5kE7_6apzBPxugHPuPXU7jOSsdBz60ooN4s=.1515d5c2-17d8-4d56-9cd1-ad2b14d01acd@github.com>
 <xTEMQ3AMTexSH_m3q2TK2tAv9PlVvXLVgll
 bkQNQDac=.a11c18cd-19eb-48ec-ba7c-eea2b682682d@github.com>
 <PwMw_Em7_AoLxSptmqRA81cpFgLdCAWCKnE6QGGiXKA=.2d750d15-bb93-4f35-8a3e-856e1088a92d@github.com>
 <YQGC2t2uXMgorcovl6sZEXySRvH_DLDwj_z8gjAYtJ8=.3ae80f8e-5ee8-4e78-9a3c-0532ebdeb26d@github.com>
 <Jb1zrYEqMl8cfElZshOSBPBexEJFz_ube6QKi5f_n0A=.436fdaad-4dfe-46f6-b668-eba686932e90@github.com>
Message-ID: <aDPSQ0j8-lBlksK30HffYMRGD07ZeBuaBUR7zawIlOY=.77c73b12-2d77-43a8-89f1-590567c00571@github.com>

On Tue, 21 Dec 2021 21:21:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I agree it probably referred to components which can be used as an editor. `DefaultEditorCell` supports three components: `JCheckBox`, `JComboBox`, and `JTextField`.
>> 
>>> But the objects implemented TableCellEditor interface can be used to modify the values stored as the JComboBox/JTree when the user edits the cell of the table.
>> 
>> And this just adds to the confusion rather than clarifies the purpose of the interface.
>
> In fact, the `CellEditor` interface describes how the interface can be used for `JTable` and `JTree` and gives `JTextField`, `JCheckBox`, `JComboBox` as the examples of specific editors.

Hi, I have updated the PR as per latest discussions and Input, any other suggestions or Inputs......?

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

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


From myano at openjdk.java.net  Wed Dec 22 11:33:14 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 22 Dec 2021 11:33:14 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <XNGsAkbvY13zmHrSmo3LpPDQNQNb97ocf_501nLgCMY=.da8f1bf4-c305-4e32-9d39-b2ab01a3da26@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <-hj0v7RZ0HPpP9GND5csZsZ1Vz7oxaufOAC0-ZygtwM=.6a5ae7a8-52d6-4e3e-a166-2fae2c23dbe0@github.com>
 <cTqTWZsK6uJI_Kw9nUymKQnYxxzWBRrk52qJAKpAc9I=.18f7dffd-3ebe-4bd0-bc2f-d61b55437036@github.com>
 <aZX6pJkrGOTYLlAHRl9WlEGtoahiInx4QzelDWpV2b0=.c9a736f9-5dd5-4382-8513-94a0233105dc@github.com>
 <QPyLlBXqr80h-_OjGxuv6tGNl8_-IZ8IHF-_8QWy894=.b18fd0a2-4497-4aae-87b1-1570531f2862@github.com>
 <2rBhm1b2wZwnJFYIve6hdNLHFE0iAkGbj1GkDkSOUCs=.726e6e6a-76b6-4657-b44b-dd854769055c@github.com>
 <k1gQRfQhMEC2tFwq5ZyyEmfebNqR6Mws651ijtdhTc8=.57c33d5c-9b6e-4b6c-9f4b-0afae0d0615f@github.com>
 <XNGsAkbvY13zmHrSmo3LpPDQNQNb97ocf_501nLgCMY=.da8f1bf4-c305-4e32-9d39-b2ab01a3da26@github.com>
Message-ID: <z0_-vSGr4HqnclIaMqrOSCEKkDvNA6TTQoUs3lgp1q8=.7ca0d177-f680-4333-9713-c1f6fe27d525@github.com>

On Thu, 18 Nov 2021 00:02:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @mrserb Can I hope this fix will be integrated after JDK-8270874 is fixed?
>
> Yes.

@mrserb @prrace Could you please review the above comments?

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

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


From ant at openjdk.java.net  Wed Dec 22 12:49:16 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Wed, 22 Dec 2021 12:49:16 GMT
Subject: RFR: 8278612: test/jdk/java/awt/dnd/RemoveDropTargetCrashTest
 crashes with VoiceOver on macOS
In-Reply-To: <XVBgpRNivpgbQ1wkWRKwyu3_dmyZIYAsVNemrF_pKMw=.58f6869b-d7a0-488d-9eb7-9f17516974c0@github.com>
References: <XVBgpRNivpgbQ1wkWRKwyu3_dmyZIYAsVNemrF_pKMw=.58f6869b-d7a0-488d-9eb7-9f17516974c0@github.com>
Message-ID: <LKWLzsbV72ZXgRkfPZDDaDja0cGjR6rDI5ovoNiduIw=.3f0ba7f4-e786-47a9-9da6-51413b94c0dc@github.com>

On Mon, 13 Dec 2021 16:50:00 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> ? VoiceOver on macOS

Moved to jdk18: https://github.com/openjdk/jdk18/pull/65

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

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


From ant at openjdk.java.net  Wed Dec 22 12:49:17 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Wed, 22 Dec 2021 12:49:17 GMT
Subject: RFR: 8278612: test/jdk/java/awt/dnd/RemoveDropTargetCrashTest
 crashes with VoiceOver on macOS
In-Reply-To: <SAOHestUTAdUoy17Ww5gRg17BNWAKph-mHp3lxDstME=.433851d5-8ac7-429e-b29f-39e842baa9b4@github.com>
References: <XVBgpRNivpgbQ1wkWRKwyu3_dmyZIYAsVNemrF_pKMw=.58f6869b-d7a0-488d-9eb7-9f17516974c0@github.com>
 <SAOHestUTAdUoy17Ww5gRg17BNWAKph-mHp3lxDstME=.433851d5-8ac7-429e-b29f-39e842baa9b4@github.com>
Message-ID: <322EDIQQfRkAYFHAKlBmqJAh0QEyqKHQSXeWhNmX-Qw=.be190956-e68a-42a2-b34f-6793092f26ec@github.com>

On Mon, 13 Dec 2021 20:08:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> ? VoiceOver on macOS
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.m line 62:
> 
>> 60: {
>> 61:     if (fTabGroupAxContext == NULL) {
>> 62:         id parent = [self parent];
> 
> Probably we can sanitize all casts to (CommonComponentAccessibility *) via some utility method which will check the type and then cast, so all calling code will get a CommonComponentAccessibility or nil?

@mrserb Thanks, I did that.  I had to re-submit PR for jdk18, please proceed in https://github.com/openjdk/jdk18/pull/65

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

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


From ant at openjdk.java.net  Wed Dec 22 12:49:17 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Wed, 22 Dec 2021 12:49:17 GMT
Subject: Withdrawn: 8278612: test/jdk/java/awt/dnd/RemoveDropTargetCrashTest
 crashes with VoiceOver on macOS
In-Reply-To: <XVBgpRNivpgbQ1wkWRKwyu3_dmyZIYAsVNemrF_pKMw=.58f6869b-d7a0-488d-9eb7-9f17516974c0@github.com>
References: <XVBgpRNivpgbQ1wkWRKwyu3_dmyZIYAsVNemrF_pKMw=.58f6869b-d7a0-488d-9eb7-9f17516974c0@github.com>
Message-ID: <x2U6v3HyObzWwTZM2AvnWpG-vFARekOmk0FfaEv-8xw=.8b65d7e7-c88b-42c1-935e-8f5171c22ac5@github.com>

On Mon, 13 Dec 2021 16:50:00 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> ? VoiceOver on macOS

This pull request has been closed without being integrated.

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

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


From ant at openjdk.java.net  Wed Dec 22 12:50:30 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Wed, 22 Dec 2021 12:50:30 GMT
Subject: [jdk18] RFR: 8278612: test/jdk/java/awt/dnd/RemoveDropTargetCrashTest
 crashes with VoiceOver on macOS
Message-ID: <H3iBh16sydeJH-75Mc7F1g_V9Q8b6fqffVirO0ICMLc=.2b160644-f689-48f6-b28e-8b42c567ae19@github.com>

8278612: test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on macOS

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

Commit messages:
 - 8278612: test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on macOS

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

PR: https://git.openjdk.java.net/jdk18/pull/65


From serb at openjdk.java.net  Wed Dec 22 19:45:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 22 Dec 2021 19:45:16 GMT
Subject: [jdk18] RFR: 8278612:
 test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on
 macOS
In-Reply-To: <H3iBh16sydeJH-75Mc7F1g_V9Q8b6fqffVirO0ICMLc=.2b160644-f689-48f6-b28e-8b42c567ae19@github.com>
References: <H3iBh16sydeJH-75Mc7F1g_V9Q8b6fqffVirO0ICMLc=.2b160644-f689-48f6-b28e-8b42c567ae19@github.com>
Message-ID: <xpLGgpQ55_HbZzqMarPNzw0TgQuMX_H8wdFP2MjIFyI=.a74045ae-4b9c-4b69-9a67-e4d616f351d4@github.com>

On Wed, 22 Dec 2021 12:42:30 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> 8278612: test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on macOS

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/65


From serb at openjdk.java.net  Wed Dec 22 22:08:11 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 22 Dec 2021 22:08:11 GMT
Subject: RFR: 8276266: Clean up incorrect client-libs ProblemList.txt
 entries
In-Reply-To: <u32Q5yNSHj0bo8IQHpzQ7OAVZ5b_fqlkKJvZoQEDOME=.a5840cea-7383-4950-b9c1-e91eadb5ffeb@github.com>
References: <-gLIqdVcPOaZgxCVSkMNQ6FzygLGTk7O710l-Mwc4zc=.8b8a3124-9d44-4893-af45-89c22d49b589@github.com>
 <ZtQfaBZJjucLrzsLY9g7GHJayRM45RaNd9GuIC0hOoY=.7e71aa86-5339-4d5c-b6fc-c83d4cad909a@github.com>
 <u32Q5yNSHj0bo8IQHpzQ7OAVZ5b_fqlkKJvZoQEDOME=.a5840cea-7383-4950-b9c1-e91eadb5ffeb@github.com>
Message-ID: <ZlXCx2D0Xf9jt09P8Y40q1JGFAGW-h-1GOtymqn-1Sk=.f68f6f0f-0f2c-4f50-8ad8-fea96d888552@github.com>

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

>> I am not sure why the macOS-specific JDK-8203047 was closed as a duplicate of x11 specific JDK-8072110?
>> The HandleExceptionOnEDT from the JDK-8203047 is not even mentioned in the JDK-8072110.
>
>> I am not sure why the macOS-specific JDK-8203047 was closed as a duplicate of x11 specific JDK-8072110?
>> The HandleExceptionOnEDT from the JDK-8203047 is not even mentioned in the JDK-8072110.
> 
> I don't know. This was done by @prsadhuk - Prasanta can you explain that ?

Any updates on that @prrace @prsadhuk?

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

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


From serb at openjdk.java.net  Thu Dec 23 01:44:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 23 Dec 2021 01:44:14 GMT
Subject: RFR: 8278908: [macOS] Unexpected text normalization on pasting
 from clipboard
In-Reply-To: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
References: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
Message-ID: <SDAojSwZxDO1uiBAYEbZ8HFqDv1g8j6JvMvxZA6Jju4=.1375c5c9-c92d-4e49-8e5e-9bd82cd535e6@github.com>

On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The fix just removes the explicit normalization of text obtained from system clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS version.
> The same fix was performed in JetBrains Runtime by a user's request more than 4 years ago, and we didn't receive any
> related complaints from our users ever since.

This code was added by changeset in the macosx-port project and never changed since then, probably the goal was to align behavior with jdk6? See the changeset below , take a look to the usage of CFStringNormalize/Normalizer.normalize, is it possible that both is used for some other reason?
https://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/dfe77a31519f

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

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


From myano at openjdk.java.net  Thu Dec 23 09:39:59 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 23 Dec 2021 09:39:59 GMT
Subject: RFR: 8277463: JFileChooser with Metal L&F doesn't show
 non-canonical UNC path in - Look in [v3]
In-Reply-To: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
References: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
Message-ID: <XnwVVItT5RLvjQ2RCOd7AKyy1cBcKYT8AUzrcBjJ71M=.b47b5e43-4b36-4962-bce6-6a487168d9b9@github.com>

> I would like to fix the bug reported in JDK-8277463.
> 
> As reporter's investigation, ShellFolder.getNormalizedFile() returns incorrect value for non-canonical Windows UNC path. getNormalizedFile() is used for symbolic link path, but Windows environment does not handle symbolic link. And, getCanonicalFile() returns correct path for a directory link in Windows which is made with `mklink` command. So getNormalizedFile() should perform to return getCanonicalFile() like WindowsFileChooserUI.addItem() at Windows environment.

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

  8277463: JFileChooser with Metal L&F doesn't show non-canonical UNC path in - Look in

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6796/files
  - new: https://git.openjdk.java.net/jdk/pull/6796/files/3e163ff9..5a164033

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

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

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


From myano at openjdk.java.net  Thu Dec 23 09:40:01 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 23 Dec 2021 09:40:01 GMT
Subject: RFR: 8277463: JFileChooser with Metal L&F doesn't show
 non-canonical UNC path in - Look in [v3]
In-Reply-To: <EzgzwF2UBALTquK53lMx3zFJ5WAjr6aVdVmknJzto5k=.5808613e-7df4-4483-b364-18102b7ce285@github.com>
References: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
 <1APEWt6EfSMXZSLa9JNxgLwQpdtfpOBE1VBgXCUntxM=.83285e41-fd61-452d-b3bf-7da6ce4f432b@github.com>
 <T6_ck6kgpSKNJA2rgB-GtP5dnTpV02QWh7r583Sf-R8=.5fff3497-d130-450c-8c20-ba0a902396cc@github.com>
 <EzgzwF2UBALTquK53lMx3zFJ5WAjr6aVdVmknJzto5k=.5808613e-7df4-4483-b364-18102b7ce285@github.com>
Message-ID: <fET09WOmLF0WhTZuzaJBiV2-GTgDGpdu-e_75-BTjyk=.66ef891d-c1f1-4c29-a069-6fdc3b1ece8c@github.com>

On Tue, 21 Dec 2021 05:28:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I fixed the test as it was pointed out to me.
>
> Now it cannot be compiled due to "unreported exception java.lang.ClassNotFoundException; must be caught or declared to be thrown" from the setLookAndFeel(); Note that the new version still has a race, the invokeLater/setLookAndFeel can be executed later than the code in the showOpenDialog(), so the code in showOpenDialog may use the wrong L&F properties, can we move the showOpenDialog to the EDT as well?

Sorry, I've modified the test case. If showOpenDialog() is called on EDT, this test does not exit at judge button pressing. So I would to change createInstructionUI() to call on main thread. This method sets properties and event handlers before showing UI, so does not need call on EDT.

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

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


From dbatrak at openjdk.java.net  Thu Dec 23 10:44:11 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Thu, 23 Dec 2021 10:44:11 GMT
Subject: RFR: 8278908: [macOS] Unexpected text normalization on pasting
 from clipboard
In-Reply-To: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
References: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
Message-ID: <61H8Rel0r2RtClQn7w91mzovorOlGG0rG8oBYT8zcvs=.a5ddd4dd-0d09-450a-bbab-d1839af3039e@github.com>

On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The fix just removes the explicit normalization of text obtained from system clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS version.
> The same fix was performed in JetBrains Runtime by a user's request more than 4 years ago, and we didn't receive any
> related complaints from our users ever since.

Thanks, I didn't know about that repo being available.
`CFStringNormalize` in the code is applied to filenames. Removing that explicit normalization doesn't seem to make any existing jtreg test fail (checked `dnd` and `datatransfer` ones), but I wouldn't touch it without a reason (e.g. a user reporting a problem with it). It can be related to file access API implementation, which, AFAIU, is expected to ignore the normalization form when referring to a file by its name on macOS.
After the proposed fix, filename can have a different representation in 'plain-text' and 'file-list'/'uri-list' flavors, as seen by a Java app, for a file 'copied' to clipboard e.g. from Finder, but I see no apparent problems with that.

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

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


From ant at openjdk.java.net  Thu Dec 23 17:59:21 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Thu, 23 Dec 2021 17:59:21 GMT
Subject: [jdk18] RFR: 8278612: [macos]
 test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on
 macOS
In-Reply-To: <H3iBh16sydeJH-75Mc7F1g_V9Q8b6fqffVirO0ICMLc=.2b160644-f689-48f6-b28e-8b42c567ae19@github.com>
References: <H3iBh16sydeJH-75Mc7F1g_V9Q8b6fqffVirO0ICMLc=.2b160644-f689-48f6-b28e-8b42c567ae19@github.com>
Message-ID: <3FoYq5FdrHGh-ixz1sYyIEIDj6S9lhvDIjNVlWukPvo=.36ec821d-2a53-48a7-a3ba-364368018fbd@github.com>

On Wed, 22 Dec 2021 12:42:30 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> 8278612: [macos] test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on macOS

@azuev-java please review.

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

PR: https://git.openjdk.java.net/jdk18/pull/65


From duke at openjdk.java.net  Fri Dec 24 02:06:18 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 24 Dec 2021 02:06:18 GMT
Subject: Integrated: 8274893: Update java.desktop classes to use
 try-with-resources
In-Reply-To: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
Message-ID: <JL4t9fjYx65gUMm9OPILuDc6RrzQ7Xwxs6LEMcmg1zU=.2e61061a-212e-45d9-b61b-a8dc21fd94b6@github.com>

On Tue, 5 Oct 2021 08:13:53 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> 8274893: Update java.desktop classes to use try-with-resources

This pull request has now been integrated.

Changeset: 70c6df6b
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/70c6df6be431fe11c5441986ed04040f9ec3b750
Stats:     227 lines in 24 files changed: 27 ins; 98 del; 102 mod

8274893: Update java.desktop classes to use try-with-resources

Reviewed-by: serb

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

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


From serb at openjdk.java.net  Fri Dec 24 07:18:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 24 Dec 2021 07:18:16 GMT
Subject: RFR: 8278908: [macOS] Unexpected text normalization on pasting
 from clipboard
In-Reply-To: <61H8Rel0r2RtClQn7w91mzovorOlGG0rG8oBYT8zcvs=.a5ddd4dd-0d09-450a-bbab-d1839af3039e@github.com>
References: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
 <61H8Rel0r2RtClQn7w91mzovorOlGG0rG8oBYT8zcvs=.a5ddd4dd-0d09-450a-bbab-d1839af3039e@github.com>
Message-ID: <qBH4yo_Sdj-veohlOnyv8eDTVRD08cacOTjJtCMUqyA=.39cdc890-5138-4eb3-804f-163a04468585@github.com>

On Thu, 23 Dec 2021 10:41:24 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> After the proposed fix, filename can have a different representation in 'plain-text' and 'file-list'/'uri-list' flavors, as seen by a Java app, for a file 'copied' to clipboard e.g. from Finder, but I see no apparent problems with that.

Since we looking at this code, can you please check if this filenames normalization differs from the native application, it will be useful for the future work.

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

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


From duke at openjdk.java.net  Fri Dec 24 09:59:39 2021
From: duke at openjdk.java.net (Aleksandr Veselov)
Date: Fri, 24 Dec 2021 09:59:39 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit test
 result on HiDPI display
Message-ID: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>

Perform scaling while converting sizes and coordinates to provide correct positions of accessible elements on HiDPI screen and make hit-test work properly. It uses FontRenderContext to receive display scale without API changes.

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

Commit messages:
 - 8279227: Access Bridge: Wrong frame position and hit test result on HiDPI display

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From duke at openjdk.java.net  Fri Dec 24 12:00:52 2021
From: duke at openjdk.java.net (Aleksandr Veselov)
Date: Fri, 24 Dec 2021 12:00:52 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v2]
In-Reply-To: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
Message-ID: <DmBvi3TdQy-87HCtfjpogr5js0EXF_ovl_9FiRZGwPM=.ea2052dd-96cc-4d1e-9f00-d5d281acca61@github.com>

> Perform scaling while converting sizes and coordinates to provide correct positions of accessible elements on HiDPI screen and make hit-test work properly. It uses FontRenderContext to receive display scale without API changes.

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

  Fix missing import

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

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/72/files
  - new: https://git.openjdk.java.net/jdk18/pull/72/files/b8a20812..4ad508fe

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

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From dbatrak at openjdk.java.net  Fri Dec 24 12:36:15 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Fri, 24 Dec 2021 12:36:15 GMT
Subject: RFR: 8278908: [macOS] Unexpected text normalization on pasting
 from clipboard
In-Reply-To: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
References: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
Message-ID: <JmyjpFVUGHHowy_TWywUce-9IrZIiB2NtBJLaxwFryw=.2103cdbf-3f68-4aac-a6d8-635bb84c764b@github.com>

On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The fix just removes the explicit normalization of text obtained from system clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS version.
> The same fix was performed in JetBrains Runtime by a user's request more than 4 years ago, and we didn't receive any
> related complaints from our users ever since.

Sure, I just don't know a 'functional' enough approach to check it, like I've done it for text copy/paste.
If you mean checking the normalization macOS APIs use when returning filenames, it definitely not NFC. At least, after I rename a file using Finder, its filename is returned in NFD (decomposed) form by both file access APIs (e.g. `readdir` from C library or `NSFileManager` from Foundation framework) and when read from clipboard (for `NSFilenamesPboardType` data type).

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

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


From ant at openjdk.java.net  Fri Dec 24 14:25:11 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Fri, 24 Dec 2021 14:25:11 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v2]
In-Reply-To: <DmBvi3TdQy-87HCtfjpogr5js0EXF_ovl_9FiRZGwPM=.ea2052dd-96cc-4d1e-9f00-d5d281acca61@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <DmBvi3TdQy-87HCtfjpogr5js0EXF_ovl_9FiRZGwPM=.ea2052dd-96cc-4d1e-9f00-d5d281acca61@github.com>
Message-ID: <8i6mUXhmJE9MnSIhvPMcXAFf7QzDZRfj1iErqjMt2BQ=.0a22b0e1-65fc-4aec-867b-a36135ad9304@github.com>

On Fri, 24 Dec 2021 12:00:52 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

>> Perform scaling while converting sizes and coordinates to provide correct positions of accessible elements on HiDPI screen and make hit-test work properly. It uses FontRenderContext to receive display scale without API changes.
>
> Aleksandr Veselov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing import

Marked as reviewed by ant (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From aivanov at openjdk.java.net  Fri Dec 24 16:23:11 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 24 Dec 2021 16:23:11 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v2]
In-Reply-To: <DmBvi3TdQy-87HCtfjpogr5js0EXF_ovl_9FiRZGwPM=.ea2052dd-96cc-4d1e-9f00-d5d281acca61@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <DmBvi3TdQy-87HCtfjpogr5js0EXF_ovl_9FiRZGwPM=.ea2052dd-96cc-4d1e-9f00-d5d281acca61@github.com>
Message-ID: <cVv8pASTZz5_zMA2ICfjB8xzaegJBMZ_h1S3A0GSlA0=.7920748c-6b7e-4ec1-bbc0-93043701e3ce@github.com>

On Fri, 24 Dec 2021 12:00:52 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

>> Perform scaling while converting sizes and coordinates to provide correct positions of accessible elements on HiDPI screen and make hit-test work properly. It uses FontRenderContext to receive display scale without API changes.
>
> Aleksandr Veselov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing import

@mrserb take a look

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From serb at openjdk.java.net  Sat Dec 25 00:03:19 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 25 Dec 2021 00:03:19 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v2]
In-Reply-To: <DmBvi3TdQy-87HCtfjpogr5js0EXF_ovl_9FiRZGwPM=.ea2052dd-96cc-4d1e-9f00-d5d281acca61@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <DmBvi3TdQy-87HCtfjpogr5js0EXF_ovl_9FiRZGwPM=.ea2052dd-96cc-4d1e-9f00-d5d281acca61@github.com>
Message-ID: <JdW0OfkrVp8xYCZppwTuBjo5dAROcSVEGRqbN18Gm-Q=.c09b9076-81d9-46f7-95ef-b64ca341c55f@github.com>

On Fri, 24 Dec 2021 12:00:52 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

>> Perform scaling while converting sizes and coordinates to provide correct positions of accessible elements on HiDPI screen and make hit-test work properly. It uses FontRenderContext to receive display scale without API changes.
>
> Aleksandr Veselov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing import

src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 1617:

> 1615:                                     r.width = (int) Math.ceil(r.width * at.getScaleX());
> 1616:                                     r.height = (int) Math.ceil(r.height * at.getScaleY());
> 1617:                                 }

This logic will not work on the multiscreen configs when the monitors have different DPI, the logic should be similar to the SunGraphicsEnvironment.toDeviceSpace().
and probably the round logic should use Region.clipRound as well.

src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 1768:

> 1766:             FontMetrics fm = acomp.getFontMetrics(acomp.getFont());
> 1767:             if (fm != null) {
> 1768:                 return fm.getFontRenderContext().getTransform();

I am not sure do we really update the FRC for the component when the DPI is changed?

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From serb at openjdk.java.net  Sat Dec 25 03:57:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 25 Dec 2021 03:57:16 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v2]
In-Reply-To: <JdW0OfkrVp8xYCZppwTuBjo5dAROcSVEGRqbN18Gm-Q=.c09b9076-81d9-46f7-95ef-b64ca341c55f@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <DmBvi3TdQy-87HCtfjpogr5js0EXF_ovl_9FiRZGwPM=.ea2052dd-96cc-4d1e-9f00-d5d281acca61@github.com>
 <JdW0OfkrVp8xYCZppwTuBjo5dAROcSVEGRqbN18Gm-Q=.c09b9076-81d9-46f7-95ef-b64ca341c55f@github.com>
Message-ID: <IibCuAD54W1vjZtDLBLh7mzIqYZbFHNFAW-HHC8E64c=.e16babe9-5be7-4a3c-a62f-3ee1649bb8c9@github.com>

On Fri, 24 Dec 2021 23:57:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Aleksandr Veselov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix missing import
>
> src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 1617:
> 
>> 1615:                                     r.width = (int) Math.ceil(r.width * at.getScaleX());
>> 1616:                                     r.height = (int) Math.ceil(r.height * at.getScaleY());
>> 1617:                                 }
> 
> This logic will not work on the multiscreen configs when the monitors have different DPI, the logic should be similar to the SunGraphicsEnvironment.toDeviceSpace().
> and probably the round logic should use Region.clipRound as well.

If this data will be used in native then we can try to use device->ScaleDownAbsX/Y, etc methods.

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From duke at openjdk.java.net  Sat Dec 25 17:38:49 2021
From: duke at openjdk.java.net (Aleksandr Veselov)
Date: Sat, 25 Dec 2021 17:38:49 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v3]
In-Reply-To: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
Message-ID: <L5-HpQm1jk4R-gbbPVrXISuIwed_jG2SeGx3oK0KC-s=.5f658d03-1890-4de4-8d6b-429aa4a7ec91@github.com>

> Perform scaling while converting sizes and coordinates to provide correct positions of accessible elements on HiDPI screen and make hit-test work properly. It uses FontRenderContext to receive display scale without API changes.

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

  Pick graphics configuration from env instead of using FRC

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

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/72/files
  - new: https://git.openjdk.java.net/jdk18/pull/72/files/4ad508fe..52327942

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

  Stats: 159 lines in 1 file changed: 118 ins; 35 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/72.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/72/head:pull/72

PR: https://git.openjdk.java.net/jdk18/pull/72


From duke at openjdk.java.net  Sat Dec 25 17:45:15 2021
From: duke at openjdk.java.net (Aleksandr Veselov)
Date: Sat, 25 Dec 2021 17:45:15 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v3]
In-Reply-To: <L5-HpQm1jk4R-gbbPVrXISuIwed_jG2SeGx3oK0KC-s=.5f658d03-1890-4de4-8d6b-429aa4a7ec91@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <L5-HpQm1jk4R-gbbPVrXISuIwed_jG2SeGx3oK0KC-s=.5f658d03-1890-4de4-8d6b-429aa4a7ec91@github.com>
Message-ID: <NZgV0JjSrVb2FiXj2GfL7NYjB7aeOc0N4KvBSzQEso4=.0d4b47af-d82a-4d7c-a820-7426edb8701e@github.com>

On Sat, 25 Dec 2021 17:38:49 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

>> Perform scaling while converting sizes and coordinates to provide correct positions of accessible elements on HiDPI screen and make hit-test work properly. It uses FontRenderContext to receive display scale without API changes.
>
> Aleksandr Veselov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pick graphics configuration from env instead of using FRC

Hi, @mrserb, thanks for the review. Your idea is awesome and I've tried to implement it. It contains some copied code from `sun.java2d` but I can't import necessary methods without adding it to dependencies. 

But the issue with different scale factors on multi-display configuration is still present, frame size scaling seems to be stuck at primary display's scale factor. `jaccesibilityinspector` shows correctly scaled bounds, may it be an issue with NVDA?

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From ant at openjdk.java.net  Mon Dec 27 15:00:20 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Mon, 27 Dec 2021 15:00:20 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v3]
In-Reply-To: <L5-HpQm1jk4R-gbbPVrXISuIwed_jG2SeGx3oK0KC-s=.5f658d03-1890-4de4-8d6b-429aa4a7ec91@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <L5-HpQm1jk4R-gbbPVrXISuIwed_jG2SeGx3oK0KC-s=.5f658d03-1890-4de4-8d6b-429aa4a7ec91@github.com>
Message-ID: <gMUdEK8z7A6aCJXljFWdqWowpYaWkyz564GMGNdg8Ek=.9ac591ce-e080-451a-a50b-3c1c995e4f67@github.com>

On Sat, 25 Dec 2021 17:38:49 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

>> Perform scaling while converting sizes and coordinates to provide correct positions of accessible elements on HiDPI screen and make hit-test work properly. It uses FontRenderContext to receive display scale without API changes.
>
> Aleksandr Veselov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pick graphics configuration from env instead of using FRC

src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 7363:

> 7361:          * @param  current the default configuration which is checked in the first
> 7362:          *         place
> 7363:          * @param  x the x coordinate of the given point

Please specify in which space the coordinates are expected.

src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 7369:

> 7367:         public static GraphicsConfiguration getGraphicsConfigurationAtPoint(
> 7368:                 GraphicsConfiguration current, double x, double y) {
> 7369:             if (current.getBounds().contains(x, y)) {

Here you do not translate the bounds to device space. Actually, I'd remove this check at all, as below you duplicate it. Also, when you call the method you pass the default GC, so it seems it does not bring much profit...

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From ant at openjdk.java.net  Mon Dec 27 15:12:17 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Mon, 27 Dec 2021 15:12:17 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v2]
In-Reply-To: <JdW0OfkrVp8xYCZppwTuBjo5dAROcSVEGRqbN18Gm-Q=.c09b9076-81d9-46f7-95ef-b64ca341c55f@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <DmBvi3TdQy-87HCtfjpogr5js0EXF_ovl_9FiRZGwPM=.ea2052dd-96cc-4d1e-9f00-d5d281acca61@github.com>
 <JdW0OfkrVp8xYCZppwTuBjo5dAROcSVEGRqbN18Gm-Q=.c09b9076-81d9-46f7-95ef-b64ca341c55f@github.com>
Message-ID: <U7nfT9hvoWrQvPxwMQHY2kNSMEddmiilRFq6YJhEvag=.0c7cbc46-0bff-425c-ac07-72b7e9d2b6f3@github.com>

On Sat, 25 Dec 2021 00:00:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Aleksandr Veselov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix missing import
>
> src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 1768:
> 
>> 1766:             FontMetrics fm = acomp.getFontMetrics(acomp.getFont());
>> 1767:             if (fm != null) {
>> 1768:                 return fm.getFontRenderContext().getTransform();
> 
> I am not sure do we really update the FRC for the component when the DPI is changed?

I've checked it - it does not change, which is unexpected... Doesn't it seem like a bug?

Actually, the problem is that AccessibleComponent does not provide the component's GC, which is a missing. Ideally would be to add it to the API and then use - because it already contains actual scales for the component. It's a pity to do all that calculations just because we lack API calls...

Is it worth trying to fix the font metrics update instead and use it until the new API is ready and available?

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From serb at openjdk.java.net  Mon Dec 27 21:02:17 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 27 Dec 2021 21:02:17 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails [v2]
In-Reply-To: <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>
Message-ID: <oN3535K2egKXu30j01jgkbvNyCr1FebFtyMZYo9WkP4=.40c36c3d-09f1-488b-ba97-92fc81d59187@github.com>

On Fri, 15 Oct 2021 11:09:26 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 7001973 fixes?
>> 
>> On Windows, CopyAreaOOB.java fails with a blank window. The cause of this problem is that paint() works one time only. Painting area is not guaranteed when showing a window.
>> 
>> I think this behavior should be removed for purpose of this test (`@summary: Verifies that copyArea() works properly`). Also, this program uses a Robot, but implements waiting logic by itself. This logic should be replaced to Robot API.
>> 
>> This fix works fine in Windows, so this test can be removed from ProblemList.txt. I don't have a Mac environment, so can someone please confirm that this fix will work on Mac?
>
> Masanori Yano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>  - Merge branch 'master' of https://github.com/masyano/jdk into 7001973
>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails

Marked as reviewed by serb (Reviewer).

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

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


From duke at openjdk.java.net  Mon Dec 27 22:20:19 2021
From: duke at openjdk.java.net (duke)
Date: Mon, 27 Dec 2021 22:20:19 GMT
Subject: Withdrawn: 8159451: [TEST_BUG]
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java
In-Reply-To: <spn83vBFx_i1HAc9XDeWfwu2EozpYl4eMGHnX3WXhqM=.ef1ba9ba-1605-4d96-bdec-f41bf702686f@github.com>
References: <spn83vBFx_i1HAc9XDeWfwu2EozpYl4eMGHnX3WXhqM=.ef1ba9ba-1605-4d96-bdec-f41bf702686f@github.com>
Message-ID: <h5BDNrvHIZsgzeFHw51DJYJyGdnns7OXNWu5uw6icZk=.c212c2ef-ec3a-44ba-b40b-a7596299583d@github.com>

On Fri, 29 Oct 2021 19:54:47 GMT, Alisen Chung <achung at openjdk.org> wrote:

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

This pull request has been closed without being integrated.

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

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


From serb at openjdk.java.net  Tue Dec 28 08:19:23 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 28 Dec 2021 08:19:23 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v2]
In-Reply-To: <U7nfT9hvoWrQvPxwMQHY2kNSMEddmiilRFq6YJhEvag=.0c7cbc46-0bff-425c-ac07-72b7e9d2b6f3@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <DmBvi3TdQy-87HCtfjpogr5js0EXF_ovl_9FiRZGwPM=.ea2052dd-96cc-4d1e-9f00-d5d281acca61@github.com>
 <JdW0OfkrVp8xYCZppwTuBjo5dAROcSVEGRqbN18Gm-Q=.c09b9076-81d9-46f7-95ef-b64ca341c55f@github.com>
 <U7nfT9hvoWrQvPxwMQHY2kNSMEddmiilRFq6YJhEvag=.0c7cbc46-0bff-425c-ac07-72b7e9d2b6f3@github.com>
Message-ID: <MAZCFVifGw4pbfFMdMJpqcqYC5PD5-TbFP3jJgUSfLk=.94662d33-a10f-4259-9d5c-986924fb135a@github.com>

On Mon, 27 Dec 2021 15:08:34 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> I've checked it - it does not change, which is unexpected... Doesn't it seem like a bug?

Yes, I think this is a bug.

> Actually, the problem is that AccessibleComponent does not provide the component's GC, which is a missing. Ideally would be to add it to the API and then use - because it already contains actual scales for the component. It's a pity to do all that calculations just because we lack API calls...

But do we actually need the GC where the component is located, or do we need a GC where the a11y frame should be placed? I am not sure that both are always the same. Note that you can find the screen where the "virtual coordinates are located" and then convert them to the device space.

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From serb at openjdk.java.net  Tue Dec 28 08:25:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 28 Dec 2021 08:25:10 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v3]
In-Reply-To: <gMUdEK8z7A6aCJXljFWdqWowpYaWkyz564GMGNdg8Ek=.9ac591ce-e080-451a-a50b-3c1c995e4f67@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <L5-HpQm1jk4R-gbbPVrXISuIwed_jG2SeGx3oK0KC-s=.5f658d03-1890-4de4-8d6b-429aa4a7ec91@github.com>
 <gMUdEK8z7A6aCJXljFWdqWowpYaWkyz564GMGNdg8Ek=.9ac591ce-e080-451a-a50b-3c1c995e4f67@github.com>
Message-ID: <yk3VeDya6JYarcSGyqeupr5VDoBmMFcPH4Yn0AFRV_c=.6027f2ec-1ab0-4e15-b15d-a0e57e739042@github.com>

On Mon, 27 Dec 2021 14:55:10 GMT, Anton Tarasov <ant at openjdk.org> wrote:

>> Aleksandr Veselov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pick graphics configuration from env instead of using FRC
>
> src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 7363:
> 
>> 7361:          * @param  current the default configuration which is checked in the first
>> 7362:          *         place
>> 7363:          * @param  x the x coordinate of the given point
> 
> Please specify in which space the coordinates are expected.

> Hi, @mrserb, thanks for the review. Your idea is awesome and I've tried to implement it. It contains some copied code from `sun.java2d` but I can't import necessary methods without adding it to dependencies.

Probably we can export that to the "jdk.accessibility" module? We already export "sun.awt" the same way. @prrace any thoughts?
But it will be good to make sure that it will work on a multiscreen config before doing that. At least need to understand the root cause of that.

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From ant at openjdk.java.net  Tue Dec 28 12:31:26 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Tue, 28 Dec 2021 12:31:26 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v2]
In-Reply-To: <MAZCFVifGw4pbfFMdMJpqcqYC5PD5-TbFP3jJgUSfLk=.94662d33-a10f-4259-9d5c-986924fb135a@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <DmBvi3TdQy-87HCtfjpogr5js0EXF_ovl_9FiRZGwPM=.ea2052dd-96cc-4d1e-9f00-d5d281acca61@github.com>
 <JdW0OfkrVp8xYCZppwTuBjo5dAROcSVEGRqbN18Gm-Q=.c09b9076-81d9-46f7-95ef-b64ca341c55f@github.com>
 <U7nfT9hvoWrQvPxwMQHY2kNSMEddmiilRFq6YJhEvag=.0c7cbc46-0bff-425c-ac07-72b7e9d2b6f3@github.com>
 <MAZCFVifGw4pbfFMdMJpqcqYC5PD5-TbFP3jJgUSfLk=.94662d33-a10f-4259-9d5c-986924fb135a@github.com>
Message-ID: <Z0CqtnLqfSyBiBzuKcugJnuGtHymPjw9JMK6nJs4Imw=.6d40ad89-dc53-480b-89a6-15d842e7f7c5@github.com>

On Tue, 28 Dec 2021 08:15:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> But do we actually need the GC where the component is located, or do we need a GC where the a11y frame should be placed? I am not sure that both are always the same. Note that you can find the screen where the "virtual coordinates are located" and then convert them to the device space.

Well, in `AccessBridge.getAccessibleContextAt_1(int x, int y, AccessibleContext parent)` we expect [x, y] within the parent bounds and so we can assume [x, y] has the same scaling. However, `AccessBridge.getAccessibleContextAt_2` works with generic [x, y] and there we have to perform generic transformation, indeed...

Ok, if we can't avoid it, then I'm ok with the latest version (taking into account my inline comments). Thanks!

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From duke at openjdk.java.net  Wed Dec 29 15:42:13 2021
From: duke at openjdk.java.net (Nikita Gubarkov)
Date: Wed, 29 Dec 2021 15:42:13 GMT
Subject: RFR: 8269806: Emoji rendering on Linux
In-Reply-To: <POqrJCtqfzFUsi8QJu7FLSc1JFhuSS0WmGMYnDpwLHQ=.a6beca24-90ba-43b3-a69c-e4326efb74a6@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <qcjJ6wJ4El89VZNwzIU8LywwPW7r5D5u62u3hy7HsbI=.edc043f7-011f-4996-a083-28c21e7a36ce@github.com>
 <POqrJCtqfzFUsi8QJu7FLSc1JFhuSS0WmGMYnDpwLHQ=.a6beca24-90ba-43b3-a69c-e4326efb74a6@github.com>
Message-ID: <7-Ouq-Oc_pghY1tWwWWd2awhpitBT2RsPVzf7oL-__c=.d158d642-6ccc-4d1c-86de-b7cee319adca@github.com>

On Sat, 30 Oct 2021 20:12:00 GMT, Phil Race <prr at openjdk.org> wrote:

>> @prrace could you take a look, please?
>
> @YaaZ nothing has really happened here in > 2 months. When can we expect an update ?

Hi @prrace! By X11 pipeline, do you mean `-Dsun.java2d.xrender=false`? Because I wasn't able to reproduce this on Ubuntu 20.04

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

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


From duke at openjdk.java.net  Wed Dec 29 19:29:21 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 29 Dec 2021 19:29:21 GMT
Subject: Withdrawn: JDK-8274977: Remove expandPacked and extendEdge from
 awt_ImagingLib.c
In-Reply-To: <1tSvf8JjhHG7crHsLOqHpNOsCcBziywqBBG6Q4SgYZk=.fec63717-09a4-4812-8e30-bdf86536cf4c@github.com>
References: <1tSvf8JjhHG7crHsLOqHpNOsCcBziywqBBG6Q4SgYZk=.fec63717-09a4-4812-8e30-bdf86536cf4c@github.com>
Message-ID: <-eVKEHI8j0vLzmsxLjUMEJ4rnYn7vQYuq6W_2Xshrhg=.5e2b5397-40c6-4ec3-b860-b94c8dc3fe7c@github.com>

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

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

This pull request has been closed without being integrated.

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

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


From serb at openjdk.java.net  Wed Dec 29 23:54:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 29 Dec 2021 23:54:15 GMT
Subject: RFR: 8264666: Reuse Math.multiplyExact/addExact in the
 LCMSImageLayout class
In-Reply-To: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
Message-ID: <c1aUU8CPVrRLoecpUaMZHGP_u3adm-gye2lGnSGIUX4=.e9cf1eee-f668-4198-9d12-af2d0b45757c@github.com>

On Fri, 2 Apr 2021 23:02:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions.
> - Cleanup: the usage of do/while(false) is removed

not now

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

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


From duke at openjdk.java.net  Thu Dec 30 00:54:19 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 30 Dec 2021 00:54:19 GMT
Subject: Withdrawn: 8185429: [macos] After the dialog is closed,
 there is no window become active.
In-Reply-To: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
References: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
Message-ID: <GE9W5FlHE7mJ1cXa0D12o0MX1M3BpRvGFnIubj901DY=.b74a4897-d11a-4b8b-bcbd-e5d6460acc2e@github.com>

On Sun, 10 Oct 2021 21:26:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

> After a modal dialog is closed, its parent window should be pushed to the front and made key.

This pull request has been closed without being integrated.

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

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


From serb at openjdk.java.net  Thu Dec 30 10:21:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 30 Dec 2021 10:21:25 GMT
Subject: RFR: 8279337: The MToolkit is still referenced in a few places
Message-ID: <heEyKqD8sBvioy4iVKHSq1u2IXq89AuPGfJijzM_8_s=.7561bce4-dbd0-4f78-9118-64369066fd69@github.com>

The MToolkit (motif toolkit) was removed in jdk7, but it is still referenced in a few places.

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

Commit messages:
 - more cases
 - Delete the mtoolkit

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

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


From duke at openjdk.java.net  Fri Dec 31 04:25:14 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 31 Dec 2021 04:25:14 GMT
Subject: Withdrawn: 8169474: KeyCharTest: Wrong number of key events: 0
In-Reply-To: <1fyY3RSMw8l0Xjcq3JFZ88qM7ert_bmJcnXPuW9qmNw=.09e8d110-40bd-4654-a268-40033ab93340@github.com>
References: <1fyY3RSMw8l0Xjcq3JFZ88qM7ert_bmJcnXPuW9qmNw=.09e8d110-40bd-4654-a268-40033ab93340@github.com>
Message-ID: <9A1MXiYrLs3Y44CJQQweV7pXwNPv39qZ9drxRVV37cY=.aeb34872-9e3a-42c5-8c93-a5d0e64a2e8a@github.com>

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

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

This pull request has been closed without being integrated.

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

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


From duke at openjdk.java.net  Fri Dec 31 20:14:12 2021
From: duke at openjdk.java.net (Jeremy)
Date: Fri, 31 Dec 2021 20:14:12 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v12]
In-Reply-To: <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
Message-ID: <BTv7geAN9SJIFuALt1iiMUj8uCJNON_iiJPXA0jR8Cc=.126eaa56-ddd4-4101-8d26-991a2937d460@github.com>

On Thu, 16 Dec 2021 18:33:37 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   This is a second follow-up response to prrace's code review feedback about method modifiers.
>   
>   This commit more carefully preserves the getBounds2D() method modifiers for all 3 classes: the Path2D.Double, the Path2D.Float, and the Path2D itself.
>   
>   It is possible (if unlikely) that someone previously extended the Path2D class and overrode getBounds2D(), because the Path2D#getBounds2D() method was *not* final. So with this commit: any such existing code will not break. Meanwhile the subclasses (Double and Float) preserve their previous modifiers (final, synchronized).
>   
>   This is in response to prrace's code review:
>   
>   >    You are changing the signature of public API
>   >    src/java.desktop/share/classes/java/awt/geom/Path2D.java
>   >    public final synchronized Rectangle2D getBounds2D() => public Rectangle2D getBounds2D() {
>   >
>   > So no longer final, and no longer synchronized.
>   > This means a CSR is required and we need to think about it ..
>   > the intention was that the subclass not over-ride.
>   > And why remove synchronized ? I am fairly sure it was there to
>   > make sure no one was mutating the Path whilst
>   > bounds are being calculated.
>   > And you are using getPathIterator(AffineTransform) and the docs
>   > for that say it isn't thread safe.
>   > So I think this implementation needs to be thought about very carefully.

Philip requested a CSR, but (as I understand it) I'm not authorized to initiate a CSR.

If Philip still thinks a CSR is appropriate (see previous comment): can someone on this mailing list help us initiate that?

And/or: if this PR doesn't make it out of review, it might be nice to at least add some comments to the openjdk bug detailing this solution for future reference. (That is: if we can't update Path2D.java, then we can give a work-around in the openjdk bug so developers can copy and paste it as needed.)

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

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


From cushon at google.com  Fri Dec 10 16:25:23 2021
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 10 Dec 2021 16:25:23 -0000
Subject: Adding uninstallColors and uninstallColorsAndFont LookAndFeel
Message-ID: <CAL4QsguPhe2aJ847yQMLPDgKa-k0-Q9u7g3ObofuJVWspg4s6Q@mail.gmail.com>

Hello,

While investigating JDK-8277817 [1], it was discovered that many of the
existing callers of LookAndFeel.{installColors,installColorsAndFont} fail
to correctly uninstall the installed properties.

[1] https://bugs.openjdk.java.net/browse/JDK-8277817

As part of the fix for that bug, I would like to add
corresponding uninstallColors and uninstallColorsAndFont methods to
LookAndFeel, to make it easier for the affected callers to
correctly uninstall properties installed by the existing methods.

The draft CSR is available at
https://bugs.openjdk.java.net/browse/JDK-8278555

The review showing the fix for JDK-8277817 using the proposed methods is
here: https://git.openjdk.java.net/jdk/pull/6603

I'd appreciate any feedback.

Liam