Cryptic error when running JavaFX modular application from command line without maven or IDE

That error is (what I consider) a bug¹ in the implementation of JEP 330: Launch Single-File Source-Code Programs (and the JEP 458: Launch Multi-File Source-Code Programs enhancement). It can be reproduced with the following:

import javafx.application.Application;
import javafx.stage.Stage;

public class Main extends Application {

    @Override
    public void start(Stage primaryStage) {
        throw new RuntimeException("test");
    }

    public static void main(String[] args) {
        launch(Main.class, args);
    }
}

Command line:

java -p <path-to-javafx> --add-modules javafx.graphics Main.java

Output:

Exception in Application start method
Exception in thread "main" java.lang.IllegalArgumentException: 0 > -2
        at java.base/java.util.Arrays.copyOfRange(Arrays.java:3807)
        at java.base/java.util.Arrays.copyOfRange(Arrays.java:3767)
        at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:273)
        at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:153)
        at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:78)

The source of this crytpic error seems to be the handling of InvocationTargetException (link to Java 22 source code) by JEP 330/458. My understanding of that code is that it is trying to hide the SourceLauncher methods from the stack trace when main throws an exception. For the most part this seems to work just fine. But it fails if the exception thrown out of main has a stack trace of less than approximately 5 elements. And from what I can gather, this is the case above because the exception thrown out of launch was created in a different thread than the one that called main, and that other thread does not have that deep of a call stack at the time.

Regardless, you are compiling your program first, so you should not be using the JEP 330 feature to begin with. Which means you should be passing a class name to java, not a source file. Based on the information you provided in your question, your command should be:

java --module-path lib \
     --add-modules javafx.controls,javafx.media \
     --class-path bin:lib/sqlite-jdbc-3.45.3.0.jar:lib/sl4j-api-1.7.36.jar \
     com.example.tetris.Main

Note a few things:

1. The last bit is the fully qualified name of the main class (instead of a path to a source file). This class will be located on the class-path.

2. Only javafx.controls and javafx.media need to be included in --add-modules, because the other required JavaFX modules will be implicitly pulled in by those two requiring them. Though adding each individual JavaFX module explicitly is not wrong, just unnecessary.

3. You can use -cp instead of --class-path and -p instead of --module-path.

That said, your application is still likely to throw an exception. But now you should be able to see the real exception instead of that cryptic IllegalArgumentException.

You mention in your title you are running a "modular application". If what you mean by that is your own code is modular (i.e., you have a module-info.java file), then your command should actually be:

java --module-path lib:bin --module app/com.example.tetris.Main

^{Note: You can use -p instead of --module-path and -m instead of --module.}

Assuming your module descriptor looks something like:

module app {
    requires java.sql;
    requires javafx.controls;
    requires javafx.media;

    exports com.example.tetris to
        javafx.graphics;
}

^{Note: Include requires org.slf4j if your own code uses it. Otherwise, the sqlite-jdbc driver requires it already. Similarly, you can requires org.xerial.sqlitejdbc if you use it directly, otherwise you should let it be found via the service-provider mechanism (the java.sql module uses a service that the org.xerial.sqlitejdbc module provides).}

^{1. I submitted a bug for this once, but it was rejected as "not reproducible". The comment explained what they did to try to reproduce it and they failed to use JEP 330. My follow up received no response. So, as far as I know, the OpenJDK developers remain unaware of this issue.}