RFR: 8353950: Clipboard interaction on Windows is unstable [v5]

Damon Nguyen dnguyen at openjdk.org
Tue Jun 3 22:23:20 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

I think this looks fair to me now. But, you still need a Reviewer to look at this. Maybe @kumarabhi006 ?

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24614#pullrequestreview-2894267992


More information about the client-libs-dev mailing list