JavaFXとは (ジャバエフエックスとは) [単語記事]

【注意】
この項目は、JavaFX 2.0以降の情報が書かれています。
JavaFX 1.x系以前の情報はこちら。

JavaFXとは、Javaの標準GUI ライブラリである(Java 8以降)。お金が溶けるFXとは何の関係もない。

概要(歴史)

ver. 1.x

JavaFXはサン・マイクロシステムズ社がプログラミング言語として開発した。同社の買収したForm Follows Function (F3)とSavaJeと呼ばれるJava関連技術を発展させて2008年 12月にパージョン1.0がリリースとなった。

ver. 2.x 〜 ver. 8

2009年 8月にサン・マイクロシステムズはOracleに買収され、Java及びJavaFXはOracleが引き継ぐところとなったが、2010年 9月 OracleはJavaFX 2でJavaFX Sc riptを廃止することを発表^[1]。これによりJavaFXは全く別物のGUI ライブラリへと生まれ変わることとなる。

これまでJavaの標準GUI ライブラリはSwingであったが、今後はJavaFXを標準GUI ライブラリとしていくことも発表された。

JavaFX 2.0は2011年 10月10日にリリースされたので、一口にJavaFXといってもこの2011年 10月の前と後では全く別物を指している。Web上で情報を探したり、書店で書籍を探したりするときは日付に注意されたい。

JavaFX 2.2の次のバージョンは3.0となる予定だったが、2014年 3月18日にリリースされたJava 8以降では標準ライブラリとしてJava仮想マシンに組み込まれることに(Java 7 Update2以降であれば標準搭載されてはいる)なったため、JavaのバージョンにあわせてJavaFX 8になり大きくバージョン番号が飛ぶことになった。

ver. 11 〜

2018年 3月にOracleは、Java 8でJava仮想マシンに組み込んだJavaFXを、再びJava仮想マシンから切り離す方針であることを発表した。2018年 9月リリースのJava 11(バージョン番号についてはJavaの記事を参照)から実施された。標準とは何だったのか。

JavaFXはOpen JFXとしてオープンソースプロジェクトとなり、Java 11リリース後はGluonという企業が実質的にJavaFXの開発を引き継いでいる。Java本体とは独立した開発なのでバージョン番号もJava本体とは一致するとは限らないはずだが、実際はJavaのバージョンに一致したJavaFXを用いる形で配布されている。

Java 11以降Oracle以外からもJava仮想マシンが配布されるケースが増えてきたが、BellSoftが配布するLibericaJDKにはJavaFXが同梱されているバージョンもある。

Oracleの言い分

Oracleは、JavaFXの分離により「Open JFXはJava本体の開発ペースに左右されずに開発が進む」というメリットがありそうな表現をしているが、Java7の時代からJavaのリファレンス実装になったOpen JDKでは、もともとJavaFXはJava仮想マシンに統合されておらず、Java バージョンが7のままでもJavaFXは2.0から2.2までアップデートしていたし、Java8リリース後もJava 8u40の時に機能追加が行われており、これまでもOpen JFXはJava本体の開発ペースに縛られてはいなかった。

むしろ、最新のJava仮想マシンのリリース時に対応するJavaFXが同時リリースされる保証がなくなる上に、ひっそりと開発中止になる可能性すら否定できなくなるという深刻なデメリットがあるのだが、その点についてOracleは一切触れていない。

JavaFXを切り離す一方で、Oracleは旧来のGUI ライブラリであるAWTやSwingはJava内に残すとしている。しかし、AWTやSwingについてもJavaFXともどもサポート企業を探すとしており、それらの地位も未来永劫安泰というわけではなさそうである。将来、Javaは標準GUI ライブラリを持たなくなるということかもしれない。

仕様等

MVC(モデル・ビュー・コントローラー)モデルでGUIを作成する。

モデルはユーザー(プログラマー)が各自でクラスを作成する。コントローラーについてもユーザーがクラスを作成するが、書き方についてはJavaFX独自の作法がある。

ビューの部分はJavaのソースコードに記述することも可能だが、FXMLというXMLで分離して記述できることが特徴^[2]。このFXMLをGUIを通じて作成するScene Bui lderというオープンソース・ソフトウェアがあり^[3]、これによって視覚的にGUIを設計することが可能になった。

フォントや色などの外観はFXMLにCSSを組み合わせることでも変更することができ、さらにこのCSSを外部ファイルとして独立させることも可能である。

黙示のマルチスレッド

Swingなどで既にGUIをマスターしている人には当然なのかもしれないが、JavaFXのGUIを使用すると、GUIに変更を行うためのスレッド(Application Thread: SwingでいうEvent Dis patch Thread)が自動的に生成される。(動画処理などを除き)すべてのGUI変更命令はこのスレッドに集められ、一本化されてから実行される。

ユーザーが明示的に作ったものでないにもかかわらず、このスレッドの存在を意識してコードを書かないと、マルチスレッドの罠にはまって理解できない動作に悩まされることになる。

Swingとの相互運用

JavaFX 2.x系では、Swingの中にJavaFXの部品を入れることはできたが、逆は出来なかった。しかし、JavaFX 8以降では、SwingNodeの導入により相互運用することが可能になっている。

プラットフォーム

プラットフォームはJava仮想マシンが動作する環境、すなわちWindows、Mac、Linuxだが、実用性や安定性を別にすればiOSやAndroidについても以下のようなプロジェクトが存在する。

RoboVM: VMとついているが、仮想マシンではなくバイトコードをx86やARMのネイティブコードに変換するクロスコンパイラのようなもの。iOS(及びAndroid)向けのアプリ作成が可能だとか。2016年 4月に開発中止。
javafxports: JavaFXは2013年以降オープンソース化が進められているので、入手したソースコードをAndroidのDalvik VM向けにコンパイルし直すという力業。しかし、コンパイル済のファイルが入手可能なレベルになっている。
Gluon VM: OracleからScene Bui lderの開発を引き継いだGluon社が開発するiOSとAndroid向けのJava仮想マシン。2017年 8月現在開発中。

2015年 5月現在、Java自体がWindows8以降で追加されたModern UI(旧称Metro)に対応していないため、現時点ではデスクトップアプリケーションの開発が主体になると思われるが、JavaFX自体にはタッチやスワイプなどのタッチパネル操作を前提にした項目も存在しているので、将来的にはJavaFXでモバイルアプリを開発できる日が来るのかもしれない。

Linux 環境のJava仮想マシンとしては、ハードウェアの違いにより通常のIntel系CPU用以外にARM用のJava仮想マシンが存在するが、2015年 1月 OracleはARM系プロセッサ向けのJava仮想マシンからJavaFXを省くという決定をした。

Oracle以外の実装であるOpen JDKでは引き続きJavaFXのサポートが続けられているが、コア機能に限定されているようである。浮動小数点演算がハードウェア実行かソフトウェア実行かにより制約を受けるらしい。

Open JFXはオープンソースなので、それをコンパイルしてOracleのARM用のJava仮想マシンに組み込むという荒業もあるらしいが、かなり複雑な工程を要する。

前述のLibericaJDKにはARM用のJavaFXを同梱したバージョンが存在する。

外部リンク

JavaFX テクノロジーの概要
Client Technologies
OpenJFX
Comment 11 for bug 1721852: JavaFXがJDKから切り離されることに関するリンク集あり

コラム: 早すぎた?JavaFX

JavaFXはFlashなどのWeb コンテンツ向けGUI 開発環境に対抗して投入された経緯があるが、この分野ではHTML5などに大きく後れを取ってしまい、一般的には遅すぎる投入であったと考えられている。

これに対し私見ではあるが、別の観点からするとJavaFXの投入が早すぎたのではないかといえる一面があることについて述べようと思う。

未熟な機能

たとえば印刷機能ですら、JavaFX 2.0の時点では不十分で、JavaFX8になってからようやく本格的にサポートされた。2015年 2月の時点で、タスクトレイのアイコン(SwingですらなくAWTのクラスを使用しなければならない)やダイアログボックス(2015年 3月のJavaFX 8 update 40で遅ればせながら導入)など、かゆいところに手が届かない未熟な一面が見てとれる。

すでにかなり遅れをとっていたので投入を急がざるを得なかったのはわかるが、時間が解決してくれる可能性もあるので今後に期待ということになるのであろうか。

Optional

もう一点、より深刻なのが、Java8から導入されたnull対策であるOptionalクラスが活用されていない点である。

JavaFXでは、リストボックスの未選択状態などを表現するのにnullを多用している。もし導入がJava6でなくJava8からであったなら、Optionalクラスのとてもよい活用例になっただろうと思われる。

しかし、JavaFX 2.0はJava6上でも利用できるように設計されているので、当然Optionalは使用されていない。その結果、互換性の関係からJavaFX 8になってもやはり使用されていない。もし今から導入しようとすると、各部品に設定されている選択状態などの値を格納する変数のクラスを変更しないといけなくなるので、互換性のことを考えると現段階から導入するのは絶望的なのではないだろうか。

Integer Pro pe rty(あるいはObje ct Pro pe rty<Integer>にnullを格納)の代わりにObje ct Pro pe rty<OptionalInt>やObje ct Pro pe rty<Optional<Integer>> 、Obje ct Pro pe rty<T>の代わりにObje ct Pro pe rty<Optional<T>>とすると利用できないこともないが、bindする部分を自力で用意せねばならず、かなり不格好である。ちなみにObje ct Pro pe rty<Optional<Integer>>とObje ct Pro pe rty<OptionalInt>ではそれほどbindするときの手間が変わらないように見えるが、Optional<Integer>では使えるのにOptionalIntでは使えないメソッドがあったりするので、後者の方がまだシンプルそうに見えるが、前者のほうがいくらか扱いやすい可能性はある。