The reason: Incompatibility of JavaFX and the glass.dll it tries to load when there are multiple Java versions available.
A simple solution: Add -Djava.library.path= in the app4mc.ini after or before --add-modules=ALL-SYSTEM. This will avoid that Eclipse generates the value. As a result the java.library.path will be empty and JavaFX will load from the Java installation that was used to start APP4MC.
This issue mainly applies to older versions. It is already addressed in the product definition (since 2.1) and in the update site (since 3.0)
The longer explanation:
When Eclipse launches it automatically generates an entry for java.library.path that contains the path to the Java installation that is used to start Eclipse, and the PATH (on Windows it is the PATH system environment variable, not sure about the Linux equivalent). If additional Java installations are in the PATH, the java.library.path environment variable contains paths to multiple Java versions. It can then happen that JavaFX loads the glass.dll from the not matching Java installation (probably the one from Java 8 if APP4MC was started with Java 11), which then leads to NoSuchMethodErrors or similar that causes a crash.
There is already a bug entry in Eclipse for that issue.
java.library.path is a Java environment variable that is used to add additional native libraries to the runtime. Typically only used in case native libraries should be added to an application that are loaded inside Java via System.loadLibrary(). As no additional external native libraries are required by APP4MC, setting java.library.path to an empty value should not have any effect on other functionalities. In Eclipse/OSGi development native libraries are typically included inside a plug-in project and do not reside external, as this would make the installation dependent on locally installed native libraries on the consumer side.