この記事は JavaFX Advent Calendar 2017 - Qiita の 21 日目です。昨日は @Yucchi_jp さんの ゆっちのBlog » JavaFX 9 で FontMetrics を取得する でした。明日はまだ空いてますのでどなたか・・・。
趣味では何年か前からちょくちょく JavaFX で遊んでたんですが、仕事では .NET メインなこともあり、 JavaFX の出番は全然ありませんでした。最近になって実案件で（ほんのちょっとだけ） JavaFX を投入する場面があったので、動機などを書いてみようと思います。
投入の動機
JavaFX の利点は「ランタイムのインストール不要で動かせる」という点です。
JavaFX で作ったのは DB アクセス含むちょっとしたデータ移行ツールだったのですが、クライアント・サーバー含め複数の環境で動かす必要がありました。
複数の環境とはいえ実は全部 Windows OS だったので .NET という手もあったのですが、 .NET だとどうしてもランタイムとして .NET Framework をインストールする必要があります。サーバーならある程度環境をコントロールできますが、クライアント環境って何が入っているかわからない*1ので、下手にランタイム入れて既存の環境が壊れてしまったりするのは避けたいというのがありました。また、 RDBMS によっては DB 接続用のコンポーネントもインストールする必要があったりして、 .NET は環境を汚しやすいのです。ということで「これは JavaFX の出番じゃね」ということで使ってみることにしました。
JavaFX ではネイティブパッケージングを使えばランタイムを同梱した状態でアプリを配布できるので、ランタイムのインストールが不要です。ビルドした実行ファイル一式を配布すればそのまま動かせます。すばらしいですね。
ネイティブパッケージング
ネイティブパッケージングについては手前味噌ですが以下にまとめてます。
ただ上記で紹介している JavaFX-Maven-Plugin は JavaFX-Maven-Plugin の現状について - notepad の通り Java9 環境はサポートしていないようですね。残念。 Java9 以降は今のところ javapackager コマンドを叩くのが良いのでしょうか？
導入してみて
実行ファイル群を配布（コピー）するだけなので実際導入は非常に楽でした。環境要因の問題も特に無く、順調に動いてくれました。ランタイムが同梱されてるので実行ファイル群のサイズが大きくなるのが難点ですかね*2。
それなりの規模のアプリ開発に導入する場合はもっと色々考慮することがあると思いますが、ちょっとしたツールなんかに JavaFX を使うのは悪い選択肢ではないと思います。ランタイムの導入って結構お願いしづらかったりしますし。
JavaFX はどうにも影が薄くて、クロスプラットフォームなデスクトップアプリでは Electron やらの影に完全に隠れてる感じになっちゃってますが、もうちょっと広まってほしいですね。 Java で書けるのって、膨大な Java のライブラリも使えるし結構強みだと思うんですけどね。
*1:業務環境では特に変な制約があったりする
*2:Jigsaw でだいぶサイズを削減できるようですが： JDK9でのjavapackagerについて - AOEの日記
