<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