本文旨在澄清javafx sdk中原生库（如.dll文件）的位置变化，并提供在现代javafx版本中构建和打包应用程序的策略。我们将探讨sdk下载包的结构、maven依赖的处理方式，以及非模块化和模块化应用下包含原生库的推荐方法，旨在帮助开发者高效地创建可执行jar或原生安装包。
JavaFX SDK 原生库的存放位置
在早期JavaFX版本中，开发者习惯于在SDK的bin/目录下寻找原生库文件（如Windows上的.dll、macOS上的.dylib或Linux上的.so），以在构建可执行JAR时将其包含进去。然而，自JavaFX 19及更高版本起，这一文件结构发生了变化。
实际上，原生库文件并未消失，而是被重新安置到了SDK的lib/目录下。例如，如果您从Gluon等官方渠道下载并解压JavaFX SDK（如openjfx-20-ea+11_osx-x64_bin-sdk.zip），您会发现所有平台特定的原生库文件都位于lib/子目录中。
示例目录结构 (以macOS为例):
javafx-sdk-20/ ├── lib/ │ ├── javafx.base.jar │ ├── javafx.controls.jar │ ├── ... │ ├── libjavafx_iio.dylib (原生库) │ ├── libprism_common.dylib (原生库) │ ├── ... └── legal/
对于Windows系统，您会在lib/目录下找到对应的.dll文件；对于Linux系统，则是.so文件。这一变化是JavaFX SDK结构演进的一部分，旨在提供更清晰、更符合现代Java生态系统规范的组织方式。
立即学习“Java免费学习笔记（深入）”；
Maven/Gradle 项目中的原生库处理
当通过Maven或Gradle等构建工具管理JavaFX项目时，原生库的引入方式与直接使用SDK下载包略有不同。Maven Central等仓库中的JavaFX依赖通常是平台特定的。
JavaFX的Maven依赖被设计为包含平台特定的原生库。例如，javafx-graphics模块会根据目标平台提供不同的JAR包：
- javafx-graphics-20-ea+11-mac.jar (macOS)
- javafx-graphics-20-ea+11-win.jar (Windows)
- javafx-graphics-20-ea+11-linux.jar (Linux)
这些平台特定的JAR文件在它们的顶层目录中已经包含了相应的原生库。这意味着当您在pom.xml或build.gradle中正确声明了带有平台分类器（classifier）的JavaFX依赖时，构建工具会自动处理原生库的引入。
Maven 示例配置：
org.openjfx javafx-controls 20 org.openjfx javafx-fxml 20 org.openjfx javafx-maven-plugin 0.0.8 com.example.App default-cli jlink jlink windows windows org.openjfx javafx-controls 20 win org.openjfx javafx-fxml 20 win mac mac org.openjfx javafx-controls 20 mac org.openjfx javafx-fxml 20 mac
在上述Maven配置中，通过定义不同平台的profile，可以确保在特定操作系统上构建时，引入正确的平台特定JavaFX依赖，从而自动包含相应的原生库。
构建与打包 JavaFX 应用
现代JavaFX应用程序的打包方式更加多样化和强大，尤其是在Java模块系统（JPMS）的推动下。
1. 传统JAR打包方法 (非模块化或部分模块化)
如果您仍希望构建一个包含所有依赖的“胖JAR”（Fat JAR），并确保其在没有预装JavaFX运行时的机器上运行，您需要：
-
使用--module-path: 在运行或打包时，将JavaFX SDK的lib目录添加到模块路径中。
java --module-path /path/to/javafx-sdk-20/lib --add-modules javafx.controls,javafx.fxml -jar YourApp.jar
这种方式要求目标机器上JavaFX SDK的lib目录是可访问的。
- 手动复制原生库 (不推荐): 尽管过去可以通过将.dll文件直接复制到项目或JAR中，但这种做法在现代JavaFX中不再推荐，因为它可能导致兼容性问题和管理复杂性。更好的方法是利用模块系统或专用打包工具。
2. 模块化应用与 jpackage (推荐方法)
JavaFX与Java模块系统（JPMS）紧密集成，这为构建自包含的应用程序提供了最佳实践。通过模块化，您可以利用jlink创建自定义运行时镜像，并使用jpackage生成平台特定的原生安装包。
-
jlink 创建自定义运行时:jlink工具允许您将应用程序及其所有依赖（包括JavaFX模块和原生库）打包到一个最小化的运行时镜像中。这个镜像只包含应用程序运行所需的JRE组件，从而大大减小了部署包的大小。
jlink --module-path /path/to/javafx-sdk-20/lib:/path/to/your/app/mods --add-modules com.your.app.module,javafx.controls,javafx.fxml --output myapp-runtime
这里/path/to/your/app/mods是您的应用程序模块JAR所在的目录。
-
jpackage 生成原生安装包:jpackage是Java 14引入的工具，用于从jlink生成的运行时镜像或直接从模块化的JAR文件创建平台特定的原生安装包（如Windows的.msi/.exe、macOS的.pkg/.dmg、Linux的.deb/.rpm）。这些安装包包含所有必要的运行时组件和应用程序代码，用户无需预装Java即可直接安装和运行。
示例命令 (简化版):
jpackage --input /path/to/your/app/jars \ --name YourApp \ --main-class com.example.App \ --main-jar YourApp.jar \ --type msi \ # 或 dmg, deb 等 --module-path /path/to/javafx-sdk-20/lib \ --add-modules javafx.controls,javafx.fxml对于Maven或Gradle项目，可以使用javafx-maven-plugin或badass-jlink-plugin等插件来自动化jlink和jpackage的流程，极大简化了打包工作。
关键注意事项
- 平台差异性: 始终注意原生库是平台特定的。Windows需要.dll，macOS需要.dylib，Linux需要.so。在跨平台部署时，确保为每个目标平台构建相应的包。
- SDK来源: 从Gluon官网下载的JavaFX SDK通常包含完整的原生库。如果您使用的是其他OpenJFX发行版，请确认其包含的文件结构。
- 构建工具配置: 无论是Maven还是Gradle，正确配置JavaFX插件和依赖分类器是确保原生库被正确引入的关键。查阅相关插件的官方文档以获取最新和最准确的配置指南。
- 模块化优势: 拥抱Java模块系统是现代JavaFX开发的趋势。它不仅简化了依赖管理，还通过jlink和jpackage提供了强大的部署能力。
总结
JavaFX SDK在最新版本中将原生库从bin/目录迁移到了lib/目录，这并非原生库的缺失，而是其内部结构调整。对于通过Maven或Gradle构建的项目，平台特定的JavaFX依赖已包含了这些原生库。为了高效且可靠地打包JavaFX应用程序，强烈推荐采用模块化开发，并利用jlink和jpackage工具创建自包含的运行时镜像和原生安装包，这将极大地简化应用程序的部署和分发。理解这些变化和最佳实践，将帮助开发者更顺畅地进行JavaFX应用的开发和交付。
