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