はじめに
かなり遅れている感はあるのですが、
Javaコンパイルしたモジュールをexe化してみるところに挑戦してみようと思います。
合わせてJavaFXを含めてexe化してみようと思います。
そこには、いろいろな歴史や葛藤みたいなものを学ぶこともできました。
余すことなく記事にできればと思っています。
Javaがexe化するにいたった経緯
１．【JARの限界】「どこでも動く」の理想と現実
初期の仕組み：
Javaは「JARファイル」を配布し、
ユーザー側のPCにあるJava（共通JRE）で動かすのが標準だった。
Write once, run anywhereという言葉を聞いたことがあるであろうか。
一度書いてしまえば、どこでも動く。の言葉が飛び交っていた。
（著者はほんとかしら？とも思ってたけど）
ところが…：
Javaバージョンの差で動かない／そもそもJavaが入っていないといった
「環境差異」で動かないことは普通だった（たしかにそう言われるとそうか・・・）
２．【セキュリティの危機】「共有Java」からの脱却
リスクの露呈：
2010年代、ブラウザ上で動くJavaの脆弱性が社会問題化。
PC全体で一つのJavaを共有する仕組みが「攻撃の標的」になった。
JavaAppletも衰退。（個人的には残念・・・かな）
考え方が変わる：
OSからJavaをアンインストールさせ、
代わりに「そのアプリ専用のJava」を内蔵させる
「独立型（サンドボックス）」の考え方が主流となった。
３．【jpackageの回答】「ポータブルなJava環境」としてのEXE
現在の標準：
Java 14以降導入された jpackage は、
アプリ本体と、削ぎ落とした最小限のJava実行環境（Runtime）をセットでパッケージングする。
EXEの役割：
生成されるEXEは「プログラムそのもの」ではなく、
Javaをインストールしていなくても、
同梱されたJavaを呼び出すための「専用の起動スイッチ」のイメージとなった。
最終結論:
Javaが入っていないPCでも
「100%確実に、かつ安全に動かす」という「実利」を優先した形が今の姿である。
きんの所見、もろもろ
開発者から見ると、結局は、
動く環境を手軽に提供しよう。
というのが答えだったような気はしますが、
試してみると、大変でした。。。
次は実践編
次に、実際のexe化の手順を書いていきます。
ですが、ただコマンドを叩けばいいというわけではありませんでした……。
次回、（２）実践編。
JINPUTの認識やモジュールの罠との格闘をお届けします。
参考文献
JEP 261: Module System (Project Jigsaw)
Java 9で導入されたモジュールシステムの考え方です。
「必要な部品だけを切り出す」という歴史の転換点を確認できます。
JEP 343: Packaging Tool (Incubator)
jpackageが導入された際の公式な提案文書です。
「インストール不要の自己完結型アプリを作る」という設計思想が書かれています。
Packaging Tool User’s Guide (Oracle)
https://docs.oracle.com/en/java/javase/25/jpackage/packaging-overview.html
（2026/01現在、Java25としてのマニュアル）
jpackage ユーザー・ガイド
シリーズリンク
Javaコンパイルしたモジュールをexe化してみる（１）Javaがexe化するに至った経緯を振り返る。
Javaコンパイルしたモジュールをexe化してみる（２）EXE化への「５段構え」の工程
Javaをexe化してみる（３）環境構築とJMODSを追加する
Javaをexe化してみる（４）バッチファイルで自動化しパッケージングする