將 Java 程序編譯為 Windows .exe 可執行文件，看似能免去 JRE 依賴，實則得不償失。本文分析利弊、介紹工具並給出更好的替代方案。
Java 編譯機制回顧
javac 將 .java → .class（字節碼）- 字節碼需 JVM（JRE）解釋/即時編譯執行，實現「一次編寫，到處運行」
- 生成 .exe 實質是將 JVM 嵌入或將字節碼轉為機器碼，喪失跨平台性
常見工具（僅供了解）
- Launch4j：將 JAR 包裝為 EXE，啟動時檢查/下載 JRE
- Excelsior JET（商業、已停止更新）：AOT 編譯字節碼為原生機器碼
- GraalVM Native Image：現代 AOT 編譯方案，支持 Spring Boot 等框架，啟動極快、體積小
- jpackage (JDK 14+)：官方打包工具，生成平台專用安裝包（含 JRE）
為什麼不推薦傳統「Java 轉 EXE」
- 失去跨平台優勢，鎖定 Windows
- 嵌入 JRE 導致體積膨脹（通常 50MB+）
- GC、JIT 優化受限，性能不一定比 JVM 好
- 維護成本高：JDK 升級需重新打包測試
更好的替代方案
| 場景 | 推薦方案 |
|---|
| 僅在 Windows 運行桌面應用 | C# / .NET (WPF, WinForms, MAUI) — 原生體驗、工具鏈成熟 |
| 需要跨平台桌面應用 | Electron / Tauri / Flutter / Compose Multiplatform |
| 微服務/後端服務 | Docker 容器化部署（含 JRE），或 GraalVM Native Image |
| 必須單文件分發 | jpackage 生成安裝包，或 GraalVM Native Image |
參考資源
選擇技術棧時，以「業務場景、團隊技能、長期維護」為準，而非單純追求「生成 EXE」。
