岡山 Java ユーザ会
先週、岡山 Java ユーザ会 (okajug) で話をしてきました。
JavaFX については、去年 11 月の JavaFX User Group の勉強会以来。わずか数ヶ月なのですが、ずいぶん状況が変化しています。
その中でも大きく、そしてうれしい変化が Linux 用のベータが公開されたことです。Mac 版に加え、Linux 版が手に入るということで、興味を持っていただけている人がかなり増えてきているようです。
Twitter で JavaFX を検索すると、かなり日本語のツィートが増えてきています。中には学生の人たちが授業の中で使っているなどが分かります。
この変化はずっと JavaFX をやってきた櫻庭にとってはうれしい反面、悲しい部分もあります。一番悲しいのが JavaFX のプレゼンで自虐的なギャグをいえなくなってきてしまったこと ^ ^;;
それはさておき、多くの人に興味を持っていただけるのはうれしいことです。
岡山では JavaFX の導入編ということで、JavaFX の Stracture, Contents, Design の 3 つのポイントについて話をしました。
Structure は GUI の構造をどうやって表すかという話です。JavaFX の場合、この構造をシーングラフと呼びます。
普通に考えたら、Java のプログラムなので、シーングラフも Java で書くと思うわけですが、これが面倒くさい。しかも、Java だとシーングラフのツリー構造が非常にわかりにくい。
そこで、出てきたのが FXML です。FXML は XML なので、ツリー構造を非常に表しやすい。しかも、ツールでも扱いやすいです。
でも、構造は FXML で表したとしても、MVC でいうところの C や M は Java で書かなくてはなりません。 FXML で書いた要素と Java をリンクづけなくてはいけないということです。
具体的には FXML に対応するクラスを作成し、FXML の要素にリンクづけたいフィールドに @FXML アノテーションを付加するだけです。簡単ですね。
というようなことを話しました。
Contents に関しては、FXML で構造を表せるようになりましたが、FXML に書ける要素、つまり画面上でどのようなものを表示できるのかということです。
JavaFX では画面に表示するオブジェクトはすべて Node クラスのサブクラスで表されます。
Swing のコンポーネントに対応するコントロールはもちろん、コンテナ、そして丸や四角などのシェイプも一緒に表すことができます。
プレゼンでは Node の特徴的な例として HTML を表示するブラウザコントロールである WebView と、ムービーなどのメディアについて紹介しました。
最後の Design は、CSS です。
JavaFX ではやっと表示要素を CSS で修飾することができるようになりました。CSS で外だしにすることにより、デザイナとの協業もやりやすくなるはずです。
当初はここで終わらせるつもりだったのですが、おまけとして Tool の話を少しだけしました。
GUI を含んだアプリケーションを作るには Tool が不可欠です。
プログラムを作るための IDE はもちろんですが、デザイナが使えるツールが絶対に必要です。Oracle なので、IDE は NetBeans ですが、デザイナが使えるツールがありませんでした。
そこで、去年の JavaOne で発表されたのが Scene Builder です。このScene Builder は MS の Blend のようなツールといえば理解しやすいのではないでしょうか。
Scene Builder が出てくると、本格的に JavaFX が使えるようになってくると思います。
さて、他のセッション。
id:tech-kazuhisa さんの JRuby セッションの間、必死にデバッグしてました ^ ^;; ちょっと変更を加えたら、NullPointerException が出るようになってしまって。とりあえず、バグはつぶせたのでよかったですが、セッションは全然聞けませんでした。スイマセン。
Andoroid の LT はちょっと残念でしたね。
id:cero-t の Kotlin のプレゼンはいつも通りのクオリティ。
そして、 id:zephiransas さんの Java 7 はもう少しがんばってほしいなぁと思いました。
変わった部分の羅列は誰でもできるんです。でも、羅列だけでは、セッションを聞いた人の記憶に残らないのです。
じゃあ、どうすればいいのかというと、ある機能が導入された背景にはどういうことがあったのか、この機能を使うと何がうれしいのかなど、機能以外の部分の情報をいかに聞いている人に与えられるかということだと思います。
たとえば、 try-with-resources で表記が簡単になったというのは、問題の一側面からしか見ていないのだと思います。じゃあ、もっと重要な問題というのは何か?
それは、リソースのクローズ忘れによるメモリリークです。
たとえば、JDBC のコネクションやストリームのクローズを忘れていて、いつのまにかリソースを食いつぶしていたというのはよくある話です。いちおうファイナライザでクローズは呼ばれますが、ファイナライザはコールされないこともあるので、ファイナライザに依存したコードは書くべきではないのです。
try-with-resoucrs を使えば、そういう問題を未然に防ぐことができるのだということが重要なんです。
そして、そこを触れない限り、聞いている人に対する訴求はなかなかできないのではないかと思っています。
でも、こういうスタイルのプレゼンをやるためには、事前の準備、というか勉強がとてもたいへんになります。でも、それをしないとやっぱりダメなんですよ。 id:zephiransas さんにはそこらへん、ぜひがんばっていってほしいなぁと思います。