RFR: 8353950: Clipboard interaction on Windows is unstable [v5]
Abhishek Kumar
abhiscxk at openjdk.org
Wed Jun 4 04:31:19 UTC 2025
On Tue, 3 Jun 2025 20:35:37 GMT, Matthias Bläsing <mblaesing at openjdk.org> wrote:
>> - Introduce a lock into WClipboard that protects the code between
>> openClipboard/closeClipboard invocations.
>> The native side does not allow to open the clipboard multiple
>> times or share the opened clipboard between multiple threads.
>>
>> - Remove of need to call openClipboard/closeClipboard from
>> getClipboardFormats by using the win32 call
>> GetUpdatedClipboardFormats
>>
>> - Prevent a race-condition by not registering the connection
>> between java and native side of clipboard multiple time, but
>> just at construction time.
>
> Matthias Bläsing has updated the pull request incrementally with one additional commit since the last revision:
>
> Address review comments:
>
> - reduce log level in WClipboard#handleContentsChanged to DEBUG, so that
> in normal operation it will not be visible
> - restore comment on WClipboard#closeClipboard
> - adjust comment on WClipboard#openClipboard
> - Ensure ConcurrentClipboardAccessTest shutsdown on its own when not
> run in an environment with an external timeout handling.
> - Added finishing message to ConcurrentClipboardAccessTest, so that
> correct termination can be determined visually if run manually
test/jdk/java/awt/Clipboard/ConcurrentClipboardAccessTest.java line 1:
> 1: /*
Test passed even without the fix on macOS.
Is the fix applicable only on Windows ?
If yes, then I think you should restrict the test to run only on required platforms.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2125609656
More information about the client-libs-dev
mailing list