jpackage to the rescue (follow-up)
This serves as a short follow-up to the previous post. Since then, Java 14 was released and includes jpackage, improving on the previously suboptimal situation surrounding packaging java applications. In short, jpackage builds on top of jlink and automatically creates self-containing app bundles for each platform according to configuration. Previously, the bash launcher script generated by jlink was not capable of catching the native FILE_OPEN events emitted by macOS. The earlier post laid out a strategy of using an additional native launcher to solve that issue. While that solution worked, it came with its own caveats. Luckily, jpackage renders these steps obsolete and solves almost all problems. The boilerplate was migrated to use jpackage and serves as a quick starting point for creating applications with custom file types.
One issue is still remaining. If a javafx.application.Application’s main method is used as the entry point of the application, the very first FILE_OPEN event on macOS can not be caught in time, defeating its purpose. As a workaround, the boilerplate introduces a minimal Launcher class triggering the JavaFX applicaiton. While this allows to catch initial FILE_OPEN events, using it and launching JavaFX over the Main method means that AWT is the main GUI toolkit, and not JavaFX. The system menu bar can no longer be used on macOS as a consequence (setUseSystemMenuBar is ignored). So with the caveat of having to incorporate the menu bar in the stage window, all other operations surrounding custom file types work properly.