在树莓派 5 上运行 JavaFX 27 Native Image
JavaFX 27 Native Image on a Raspberry Pi 5

原始链接: https://ennerf.github.io/2026/09/18/JavaFX-27-Native-Image-on-a-Raspberry-Pi-5.html

在最初将 GraalVM Native Image 用于移动端部署后,作者将他们的 JavaFX 桌面和命令行(CLI)应用程序迁移到了预先编译(AOT)。他们发现,由于图形界面(GUI)很少达到即时编译(JIT)的触发阈值,因此能从 AOT 中显著受益;迁移到 Native Image 后,启动速度最高提升了 90%,内存占用也大幅降低。 在树莓派(Raspberry Pi)5 上的基准测试表明,经过 AOT 编译的 JavaFX 性能远超标准的 JIT 构建(jlink + CDS),甚至超过了高端台式机的性能表现。 尽管 JavaFX 与 Native Image 高度兼容,但其初始配置过程非常复杂,这导致人们普遍认为 Java 桌面应用与 AOT“不兼容”。作者将这种挫败感归因于那些掩盖了原生层并导致调试困难的“魔法”工具。为了解决这一问题,他们开发了自定义工具,旨在简化最新版 JavaFX 与 Oracle GraalVM 的集成,消除过程中的神秘感,从而让高性能的原生 Java 桌面应用更易于开发。

Hacker News 最新 | 往期 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 在树莓派 5 上运行 JavaFX 27 原生镜像 ( ennerf.github.io ) 4 点 由 0x54MUR41 发布 2 小时前 | 隐藏 | 往期 | 收藏 | 讨论 帮助 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系 搜索:
相关文章

原文

We initially used GraalVM Native Image as a way to deploy JavaFX to mobile targets. However, after seeing our mobile apps feel snappier than our desktop apps, we gradually migrated all of our GUI and CLI applications over to ahead-of-time (AOT) compilation. GUIs mostly run in interpreted mode (users would have to click thousands of times to reach the JIT threshold), and with AOT we see up to 90% reductions in startup and first visit times, which results in a noticeably better user experience.

Table 1. AtlantaFX sampler comparison on a Raspberry Pi 5
AtlantaFX Sampler (RPi5)jlink (JIT)jlink + CDS (JIT)Native Image (AOT)

Distribution size

139 MB

155 MB (+12%)

124 MB (-11%)

Time to first window

3.6 s

2.7 s (-26%)

0.5 s (-86%)

First visit: HTMLEditor (WebView)

2.39 s

2.31 s (-3%)

0.22 s (-91%)

First visit: Overview (FXML)

1.90 s

1.50 s (-21%)

0.32 s (-83%)

Private memory after startup

224 MB

244 MB (+9%)

164 MB (-27%)

Private memory after all pages

1424 MB

1396 MB (-2%)

634 MB (-55%)

In fact, starting the AtlantaFX sampler on a high-end Ryzen 9 9950X desktop with jlink + CDS takes more than 2.5 times as long (1.3 s) as the same application running AOT-compiled on a tiny Raspberry Pi 5 (0.5 s, see benchmarks). The whole run is captured in a short video walkthrough of all pages, including FXML, WebView, MediaPlayer, and AWT integration.

JavaFX actually works very well in Native Image once everything is configured, but getting a complex application running for the first time is typically not a straightforward experience. This steep initial hurdle has unfortunately earned JavaFX, and desktop Java in general, a reputation of being incompatible or working poorly with Native Image. I think a big part of this stems from complex, specialized tooling that performs a lot of "magic" behind the scenes to hide the native layers. Whenever anything breaks, it produces errors that many Java developers don’t know how to debug.

In this post I want to demystify the internals of these tools, and show why we built our own tooling to run the latest JavaFX 27 release with the latest enterprise Oracle GraalVM on desktop targets.

联系我们 contact @ memedata.com