这些是打包/分发（非模块化）JavaFX 11 最终应用程序的几个选项。其中大部分在官方 OpenJFX文档中进行了解释。
我将使用此示例作为参考。我也会使用 Gradle。使用 Maven（不同的插件）可以完成类似的操作，甚至没有构建工具（但不推荐这样做......）。构建工具是当今必须的。
脂肪罐
这仍然是一个有效的选项，但不是首选选项，因为它打破了模块化设计并将所有内容捆绑在一起，除非您注意这一点，否则它不是跨平台的。
对于给定的示例，您有一个 build.gradle 文件，如下所示：
plugins {
id 'application'
id 'org.openjfx.javafxplugin' version '0.0.5'
}
repositories {
mavenCentral()
}
dependencies {
}
javafx {
modules = [ 'javafx.controls' ]
}
mainClassName = 'hellofx.HelloFX'
jar {
manifest {
attributes 'Main-Class': 'hellofx.Launcher'
}
from {
configurations.compile.collect { it.isDirectory() ? it : zipTree(it) }
}
}
注意Launcher类的使用。正如 OP 所提到的或在此处Application解释的那样，现在需要一个不扩展自的启动器类来创建一个胖 jar。
运行./gradlew jar会生成一个胖 jar (~8 MB)，其中包含 JavaFX 类和当前平台的本机库。
您可以java -jar build/libs/hellofx.jar照常运行，但只能在同一平台上运行。
如 OpenJFX 文档或此处所述，您仍然可以创建跨平台 jar。
在这种情况下，我们可以包含三个图形 jar，因为它们具有平台相关的代码和库。Base、controls 和 fxml 模块是平台无关的。
dependencies {
compile "org.openjfx:javafx-graphics:11.0.1:win"
compile "org.openjfx:javafx-graphics:11.0.1:linux"
compile "org.openjfx:javafx-graphics:11.0.1:mac"
}
./gradlew jar现在将生成一个可以分发到这三个平台的 fat jar (19 MB)。
（注意媒体和网络也有平台相关的代码/本地库）。
所以这和过去在 Java 8 上的工作方式一样。但正如我之前所说，它破坏了模块的工作方式，并且与当今库和应用程序的分布方式不一致。
并且不要忘记这些 jar 的用户仍然需要安装 JRE。
链接
那么如何在您的项目中分发自定义图像，其中已经包含本机 JRE 和启动器？
你会说如果你有一个非模块化的项目，那是行不通的。真的。但是，在讨论 jpackage 之前，让我们在这里检查两个选项。
运行时插件
badass-runtime-plugin是一个 Gradle 插件，可以从非模块化项目创建运行时映像。
有了这个 build.gradle：
plugins {
id 'org.openjfx.javafxplugin' version '0.0.5'
id 'org.beryx.runtime' version '1.0.0'
id "com.github.johnrengelman.shadow" version "4.0.3"
}
repositories {
mavenCentral()
}
dependencies {
}
javafx {
modules = [ 'javafx.controls' ]
}
mainClassName = 'hellofx.Launcher'
runtime {
options = ['--strip-debug', '--compress', '2', '--no-header-files', '--no-man-pages']
}
当您运行./gradlew runtime时，它将创建一个运行时及其启动器，因此您可以运行：
cd build/image/hellofx/bin
./hellofx
请注意，它依赖于影子插件，并且还需要一个 Launcher 类。
如果你运行./gradlew runtimeZip，你可以获得一个大约 32.5 MB 的自定义图像的 zip。
同样，您可以将此 zip 分发给具有相同平台的任何用户，但现在不需要安装 JRE。
参见targetPlatform为其他平台构建图像。
走向模块化
我们一直认为我们有非模块化项目，并且无法更改……但是如果我们确实更改了呢？
模块化并不是什么大的改变：添加一个module-info.java描述符，并在其上包含所需的模块，即使这些是非模块化 jars（基于自动名称）。
基于相同的示例，我将添加一个描述符：
module hellofx {
requires javafx.controls;
exports hellofx;
}
现在我可以jlink在命令行上使用，或者使用插件。badass-gradle-plugin是一个 gradle 插件，与前面提到的作者来自同一作者，它允许创建自定义运行时。
使用此构建文件：
plugins {
id 'org.openjfx.javafxplugin' version '0.0.5'
id 'org.beryx.jlink' version '2.3.0'
}
repositories {
mavenCentral()
}
dependencies {
}
javafx {
modules = [ 'javafx.controls' ]
}
mainClassName = 'hellofx/hellofx.HelloFX'
你现在可以运行：
./gradlew jlink
cd build/image/bin/hellofx
./hellofx
或者./gradlew jlinkZip对于可以在同一平台的机器上分发和运行的压缩版本 (31 MB)，即使没有安装 JRE。
如您所见，不需要影子插件或 Launcher 类。您还可以针对其他平台，或包括非模块化依赖项，例如在这个问题中。
jpackage
最后，有一个新工具可以创建可执行安装程序，您可以使用它来分发您的应用程序。
到目前为止还没有 GA 版本（可能我们将不得不等待 Java 13），但是现在有两个选项可以将它与 Java 11 或 12 一起使用：
对于 Java/JavaFX 11，您可以在此处找到 Java 12 上 JPackager 的初始工作的后向端口。有一篇关于在此处使用它的好文章，以及在此处使用它的 gradle 项目。
在 Java/JavaFX 12 中，已经有一个build 0 版本的jpackage工具，将在 Java 13 中可用。
这是该工具的一个非常初步的使用：
plugins {
id 'org.openjfx.javafxplugin' version '0.0.5'
}
repositories {
mavenCentral()
}
dependencies {
}
javafx {
version = "12-ea+5"
modules = [ 'javafx.controls' ]
}
mainClassName = 'hellofx/hellofx.HelloFX'
def java_home = '/Users/<user>/Downloads/jdk-12.jdk/Contents/Home'
def installer = 'build/installer'
def appName = 'HelloFXApp'
task copyDependencies(type: Copy) {
dependsOn 'build'
from configurations.runtime
into "${buildDir}/libs"
}
task jpackage(type: Exec) {
dependsOn 'clean'
dependsOn 'copyDependencies'
commandLine "${java_home}/bin/jpackage", 'create-installer', "dmg",
'--output', "${installer}", "--name", "${appName}",
'--verbose', '--echo-mode', '--module-path', 'build/libs',
'--add-modules', "${moduleName}", '--input', 'builds/libraries',
'--class', "${mainClassName}", '--module', "${mainClassName}"
}
现在运行./gradlew jpackage会生成一个 dmg (65 MB)，我可以分发它来安装：
结论
虽然您可以坚持使用经典的 fat jar，但在迁移到 Java 11 及更高版本时，一切都应该是模块化的。新的（即将推出的）可用工具和插件，包括 IDE 支持，在此过渡期间提供帮助。
我知道我在这里介绍了最简单的用例，当尝试更复杂的实际案例时，会出现几个问题……但我们应该更好地解决这些问题，而不是继续使用过时的解决方案。