<AWT Dev> deadlock between AppKit main thread and AWT event thread in JDK 17
Alan Snyder
javalists at cbfiddle.com
Mon Jun 28 14:03:53 UTC 2021
You can call performSelectorOnMainThread directly, but you have to know the name of the AWT/Java run loop to avoid the deadlock situations that I have encountered.
The name of the run loop needs to be part of the public API.
By the way, upcalls from AppKit to get accessibility information has been a source of problems for a long time. I don’t suppose there is any way that Java can respond to these requests without running code on the AWT event thread?
> On Jun 28, 2021, at 6:29 AM, Michael Hall <mik3hall at gmail.com> wrote:
>
>
>
>> On Jun 28, 2021, at 7:51 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
>>
>> Hmm… it appears that in removing JavaNativeFoundation from the JDK the name of the run loop was changed from AWTRunLoopMode to javaRunLoopMode.
>>
>> If that is correct, it is an incompatible change that breaks third party use of JavaNativeFoundation for running code on the main thread.
>>
>> It also sounds like a gratuitous change.
>
> Since AWT stopped using it, how supported is JavaNativeFoundation going forward for the JDK? Not that this means it’s ok to break other code using it without some reason.
>
> There is directly?
> performSelectorOnMainThread
> You can even do a java callback from the selector to do java on the main thread. I had some code going back to Apple Java to do that.
More information about the awt-dev
mailing list