File dialog opening can cause a crash, at least on Windows

[apocalyptech]

System Info Operating System: Windows (unsure of exact version)

Describe the bug Opening a file dialog, under some circumstances (such as File -> Open) can lead to a crash with a relatively-unhelpful traceback like so:

2024-02-16 15:37:03 blcmm.Startup$MyExceptionHandler.logError(Startup.java:388) -> class java.lang.InternalError: Could not bind shell folder to interface
    org.graalvm.nativeimage.builder/com.oracle.svm.core.jni.functions.JNIFunctions$NewObjectWithObjectArrayArgFunctionPointer.invoke(JNIFunctions.java)
    org.graalvm.nativeimage.builder/com.oracle.svm.core.jni.functions.JNIFunctions.ThrowNew(JNIFunctions.java:889)
    [email protected]/sun.awt.shell.Win32ShellFolder2.initSpecial(Native Method)
    [email protected]/sun.awt.shell.Win32ShellFolder2$1.call(Win32ShellFolder2.java:297)
    [email protected]/sun.awt.shell.Win32ShellFolder2$1.call(Win32ShellFolder2.java:292)
    [email protected]/sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Win32ShellFolderManager2.java:630)
    [email protected]/sun.awt.shell.ShellFolder.invoke(ShellFolder.java:540)
    [email protected]/sun.awt.shell.Win32ShellFolder2.<init>(Win32ShellFolder2.java:292)
    [email protected]/sun.awt.shell.Win32ShellFolderManager2.getNetwork(Win32ShellFolderManager2.java:222)
    [email protected]/sun.awt.shell.Win32ShellFolder2.getFileSystemPath(Win32ShellFolder2.java:631)
    [email protected]/sun.awt.shell.Win32ShellFolder2$10.call(Win32ShellFolder2.java:839)
    [email protected]/sun.awt.shell.Win32ShellFolder2$10.call(Win32ShellFolder2.java:830)
    [email protected]/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    [email protected]/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
    [email protected]/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    [email protected]/sun.awt.shell.Win32ShellFolderManager2$ComInvoker$1.run(Win32ShellFolderManager2.java:599)
    [email protected]/java.lang.Thread.run(Thread.java:833)
    org.graalvm.nativeimage.builder/com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine(PlatformThreads.java:838)
    org.graalvm.nativeimage.builder/com.oracle.svm.core.windows.WindowsPlatformThreads.osThreadStartRoutine(WindowsPlatformThreads.java:210)

It seems likely to somehow have something to do with network accessibility. Also in the user's logfile above was this line:

2024-02-16 15:37:01 blcmm.gui.MainGUI$7.doInBackground(MainGUI.java:543) -> class java.net.SocketException: Permission denied: connect

Some random searching around has yielded a couple of hits for this, both seemingly relating to network permissions, though both are pretty old. Here's a JDK bug from way back in the early 2000s talking about a Windows NT machine: https://bugs.openjdk.org/browse/JDK-4879395 -- And here's a StackOverflow post: https://stackoverflow.com/questions/17644390/what-causes-an-internalerror-to-be-thrown-by-sun-awt-shell-win32shellfolder2-ini (note the "Edit 2" specifically, which calls out a Win32ShellFolder2.NETWORK argument).

Also from the reporting user (in Discord):

BCMM worked beforehand, then I ran a few network tweaks to get Windows File Sharing working over LAN, and that's around the time that BCMM would throw this error.

So it does seem awfully likely that JFileChooser must have some problems when certain network attempts are made, which can result in a crash. It's rather vexing because I do intend OpenBLCMM to be fully functional without any network. The only intended network call is to check for a new version, which should fail gracefully (and can be toggled off by the user).

This happened for the user both on the EXE version (still Liberica NIK's Java 17), and on Pure Java on (I believe) Java 8.

So anyway, I'll have to see if I can reproduce this in a VM and then see what can be done about it. If I can't fix JFileChooser (which, honestly, seems like a pretty likely case), perhaps I could at least fall back to a more basic file-chooser dialog instead? The SO post mentions trying FileDialog instead... We'll have to see.