Загадочная ошибка при запуске модульного приложения JavaFX из командной строки без maven или IDE

Эта ошибка (что я считаю) ошибкой¹ в реализации JEP 330: Запуск однофайловых программ с исходным кодом (и усовершенствования JEP 458: Запуск многофайловых программ с исходным кодом). Его можно воспроизвести с помощью следующего:

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);
    }
}

Командная строка:

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

Выход:

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)

Источником этой загадочной ошибки, по-видимому, является обработка исключения InvoctionTargetException (ссылка на исходный код Java 22) в JEP 330/458. Насколько я понимаю, этот код пытается скрыть методы SourceLauncher из трассировки стека, когда main выдает исключение. По большей части это работает нормально. Но это терпит неудачу, если исключение, выброшенное из main, имеет трассировку стека менее примерно 5 элементов. И насколько я могу судить, это тот случай, описанный выше, потому что исключение, выброшенное из launch, было создано в другом потоке, отличном от того, который вызвал main, и этот другой поток не имеет такого глубокого стека вызовов в тот момент.

В любом случае, сначала вы компилируете свою программу, поэтому вам не следует использовать функцию JEP 330 с самого начала. Это означает, что вы должны передавать имя класса java, а не исходный файл. На основании информации, которую вы предоставили в своем вопросе, ваша команда должна быть такой:

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

Обратите внимание на несколько вещей:

1. Последний бит — это полное имя основного класса (вместо пути к исходному файлу). Этот класс будет расположен на пути к классам.

2. В javafx.controls необходимо включить только javafx.media и --add-modules, поскольку остальные необходимые модули JavaFX будут неявно подтянуты теми двумя, которые им требуются. Хотя явное добавление каждого отдельного модуля JavaFX не является неправильным, а просто ненужным.

3. Вы можете использовать -cp вместо --class-path и -p вместо --module-path.

Тем не менее, ваше приложение все равно может выдать исключение. Но теперь вы сможете увидеть настоящее исключение, а не загадочное IllegalArgumentException.

В заголовке вы упоминаете, что используете «модульное приложение». Если под этим вы подразумеваете, что ваш собственный код является модульным (т. е. у вас есть файл module-info.java), то ваша команда на самом деле должна быть такой:

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.}

Предположим, что ваш дескриптор модуля выглядит примерно так:

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.}