Maybe try to change TestChooser to a modal window and see if it makes any difference.
Edit:
By the way, searched GitHub for “BUG IN CLIENT OF LIBDISPATCH…” error and found this: gdx-lwjgl3-glfw-awt-macos extensions to add support for mixing GLFW and AWT on macOS by badlogic · Pull Request #6772 · libgdx/libgdx · GitHub
Hahah… we come full circle. 
In order to do that, I’ll need more detailed instructions.
Afaik you just need to replace extends JFrame to extends JDialog in TestChooser class and call setModal(true) in the constructor.
JDialog doesn’t have the right constructor.
> Task :jme3-examples:compileJava FAILED
/Users/administrator/Git/jmonkeyengine/jme3-examples/src/main/java/jme3test/TestChooser.java:98: error: no suitable constructor found for JDialog(String)
super("TestChooser");
^
constructor JDialog.JDialog(Frame) is not applicable
(argument mismatch; String cannot be converted to Frame)
constructor JDialog.JDialog(Dialog) is not applicable
(argument mismatch; String cannot be converted to Dialog)
constructor JDialog.JDialog(Window) is not applicable
(argument mismatch; String cannot be converted to Window)
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
1 error
Replace it with setTitle("TestChooser");.
And use which constructor?
Maybe:
JDialog()… the no-arg constructor, ie: super()
Or:
JDialog(Frame owner, String title, boolean modal)
like this: super((Frame) null, "TestChooser", true)
then you wont need to call setTitle() and setModal() anymore.
@sgold, any news? Was the suggested change helpful?
I was able to compile TestChooser as you suggested, however, I’m still getting java.awt.HeadlessException.
Frankly, I grow discouraged with “glfw_async”.
I suspect our best course is to rewrite the test chooser and the settings dialog so that they don’t use AWT/Swing.
Just in case, if you are interested to give it a try with Java 17, there is a new render pipeline added for Java Swing that uses macOS Metal API. Which may not have these issues with GLFW (I hope!).
By default, JVM will use the OpenGL backend, for switching to the Metal backend you need to specify the -Dsun.java2d.metal=true argument.
For more info see: JEP 382: New macOS Rendering Pipeline
I fear you overestimate my abilities. If you write something, I’ll build it and run it and send you the results.
Ok, will do.
Here you go:
Requires Java 17 to run.
administrator@26674 Git % git clone https://github.com/Ali-RS/JmeMacTest.git
Cloning into 'JmeMacTest'...
remote: Enumerating objects: 29, done.
remote: Counting objects: 100% (29/29), done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 29 (delta 4), reused 29 (delta 4), pack-reused 0
Receiving objects: 100% (29/29), 61.64 KiB | 595.00 KiB/s, done.
Resolving deltas: 100% (4/4), done.
administrator@26674 Git % cd JmeMacTest
administrator@26674 JmeMacTest % ls
README.txt gradle gradlew.bat src
build.gradle gradlew settings.gradle
administrator@26674 JmeMacTest % java17
administrator@26674 JmeMacTest % echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
administrator@26674 JmeMacTest % $JAVA_HOME/bin/java -version
openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment Temurin-17.0.2+8 (build 17.0.2+8)
OpenJDK 64-Bit Server VM Temurin-17.0.2+8 (build 17.0.2+8, mixed mode)
administrator@26674 JmeMacTest % ./gradlew run
zsh: permission denied: ./gradlew
administrator@26674 JmeMacTest % chmod +x run
chmod: run: No such file or directory
administrator@26674 JmeMacTest % chmod +x gradlew
administrator@26674 JmeMacTest % ./gradlew run
Downloading https://services.gradle.org/distributions/gradle-7.2-bin.zip
..........10%...........20%...........30%...........40%...........50%...........60%...........70%...........80%...........90%...........100%
Welcome to Gradle 7.2!
Here are the highlights of this release:
- Toolchain support for Scala
- More cache hits when Java source files have platform-specific line endings
- More resilient remote HTTP build cache behavior
For more details see https://docs.gradle.org/7.2/release-notes.html
Starting a Gradle Daemon (subsequent builds will be faster)
> Task :run FAILED
Exception in thread "main" java.lang.IllegalStateException: Cannot show dialog in headless environment
at com.jme3.system.JmeDesktopSystem.showSettingsDialog(JmeDesktopSystem.java:139)
at com.jme3.system.JmeSystem.showSettingsDialog(JmeSystem.java:158)
at com.jme3.app.SimpleApplication.start(SimpleApplication.java:120)
at jmetest.JmeMacTest.main(JmeMacTest.java:19)
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':run'.
> Process 'command '/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/java'' finished with non-zero exit value 1
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.
You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
See https://docs.gradle.org/7.2/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 6s
2 actionable tasks: 2 executed
administrator@26674 JmeMacTest %
Love that all of the preliminaries are included. To check if the environment is indeed behaving as headless, can you compile and launch Oracle’s basic HelloWorldSwing demo?
Note that the JmeMacTest above was run from an ssh session.
The first time I ran HelloWorldSwing, I ran it from an ssh session. It crashed with a HeadlessException, so a re-ran it on the console:
Then I re-ran JmeMacTest on the console, but it crashed just as it did from ssh:
Can you please check out JmeMacTest from the master. I have made a few changes.
Do not run from ssh session.
