JVM hang with Swing and macOS

[Michael Hall]

> On Mar 20, 2023, at 2:12 PM, Sergey Bylokhov <bylokhov at amazon.com> wrote:
> 
> On 3/16/23 12:15, Alan Snyder wrote:
>> The test for already being on the main thread should be performed in one place, in this method:
>>> On Mar 16, 2023, at 6:07 AM, Michael Hall <mik3hall at gmail.com> wrote:
>>> 
>>>    [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
> 
> That check is already there:
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m#L103
> 
> -- 
> Best regards, Sergey.
> 

Yes I had found that. That is still where it hangs. Without the -XrunOnFirstThread the block runs. With it the code hangs. I put NSLog’s into the code.
SHIFT+CTRL+\ for stack trace on bug report test case shows where.
After seeing this (java_md_macosx.m JVMInit  sameThread is true)…

           /*
             * We cannot use dispatch_sync here, because it blocks the main dispatch queue.
             * Using the main NSRunLoop allows the dispatch queue to run properly once
             * SWT (or whatever toolkit this is needed for) kicks off it's own NSRunLoop
             * and starts running.
             */
I would think the problem is that -XrunOnFirstThread is intended for ’toolkit’s that aren’t Swing based but handle the gui and NSRunLoop as indicated themselves - like Eclipse with SWT.

Arbitrary Swing app’s just can’t use this jvm switch.
And weren’t meant to?