Backport Candidate: JDK-8332271/ JDK-8353950 (PR #24614)

[Philip Race]

I've looked at the code and I think overall it is an improvement in a 
few ways such as fewer calls to open/close
and getting the formats not requiring that.

I didn't spot anything that looks suspicious and we've been running it 
in CI since it was pushed,
and given that it fixes crashes (etc) it seems like a reasonable RDP 1 fix.

-phil.


On 6/11/25 8:59 AM, Matthias Bläsing wrote:
> Hi,
>
> Am Dienstag, dem 10.06.2025 um 21:43 -0700 schrieb Philip Race:
>> It seems to me like a candidate based on being a recent 'regression' and
>> the use case and potential impact.
>> I just have not looked at or tested the code myself, and clipboard tests
>> are at least in some part manual,
>> so I don't know how well it has been tested.
>>
>> Did anyone run at least the automated jtreg tests for you on our CI system ?
> to my knowledge this was not yet done.
>
> I ran the jtreg tests from `test/jdk/java/awt/Clipboard` locally
> including the new crash reproducer. In addition I used the application
> level reproducer to verify that the issue also covers that. That test
> copy-and-pastes text between NetBeans and notepad in a loop, while
> adding the loop index on each invocation. That looked sane for 20-100
> iterations.
>
>> On 6/10/25 12:54 PM, Matthias Bläsing wrote:
>>> [Backport proposal https://github.com/openjdk/jdk/pull/24614]
>>>
>>> JDK-8332271: Reading data from the clipboard from multiple threads crashes the JVM (P3)
>>> JDK-8353950: Clipboard interaction on Windows is unstable (P4)
> Thanks for considering
>
> Matthias