How can dynamic JVM command line flags be passed to a self-contained JavaFX application?

Question

EDIT: Oracle accept my bug report requesting an enhancement as JDK-8138944 : Support command line arguments to the JVM passed to self-contained app launchers.

The problem

My team is working on an open source Java SE project, ImageJ, that currently has a custom native launcher written in cross-platform C. We would like to move away from this launcher, switching to a more modern, industry standard and maintainable deployment mechanism. JavaFX self-contained applications are the most promising solution we have found so far.

One great feature of ImageJ's current native launcher is its ability to customize how the JVM is launched. For example, you can write:

ImageJ --debugger=8000 myFile.png

And the launcher will invoke the JVM with flag:

-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=localhost:8000

while keeping the myFile.png as an argument to the Java main class.

But from the docs, we cannot see a way to accomplish something similar with the JavaFX packaging tool.

Considerations

I know that the UserJvmOptionsService provides a means to configure how the JVM is started (via Java Preferences API internally, which the JavaFX launcher reads before JVM startup). This is nice for providing the user with a friendly dialog box where they can tweak maximum heap size and other common parameters. Certainly we could add a remote debugging toggle and port settings to such a dialog box, and/or support JVM configuration via the CLI—but it would then require a restart of the application.

Ideally we would not need to support this scenario at all, and instead would handle all command line arguments after the JVM starts up, in Java. For example, in most cases, system properties of the form -Dfoo=bar can be supported by simply parsing the arg and setting the system property at runtime, as long as it is done early enough in the application's startup cycle. But there are clearly many cases where doing it after JVM startup is too late:

• The debugging example above (you can't enable remote debugging after startup).
• Heap size tuning
• Garbage collection tuning
• Verbose class loading (-verbose)
• Interpreted mode (-Xint)
• Lots of other examples

Our users expect to be able to pass these settings on the CLI, and have the Java runtime operate accordingly—and in the case of ImageJ, it is particularly important for backward compatibility.

Possible solutions

• We could retain the native C launcher, replacing the native executable that the Java packaging tool installs. But this strikes me as highly fragile, and largely defeats the purpose of switching to JavaFX deployment, since we would still need to maintain, build and test the custom native launcher across several different platforms.

• Alternately, we could have the application main class be a very thin CLI option parser, which then spawns a second instance of the JVM. This would keep the bootstrapping logic in pure Java, which would be far more maintainable than the current native C code, while fully leveraging the JavaFX deployment scheme's cross-platform bundling capabilities. But that seems like a big hack with potentially challenging side effects.

Finally, the question

Has anyone achieved support for JVM CLI arguments with JavaFX self-contained application deployment? If so, how did you accomplish it? If not, any alternative suggestions?

Answer 1

You can modify the launch arguments to the JVM by modifying the jvm user overrides config file that the API writes to:

• Mac ~/Library/Application Support/[app.preferences.id]/packager/jvmuserargs.cfg • Windows C:\Users[username]\AppData\Roaming[app.preferences.id]\packager\jvmuserargs.cfg • Linux ~/.local/[app.preferences.id]/packager/jvmuserargs.cfg

NOTE: This is an internal implementation detail and subject to change.