JavaOne は iOS と Andoroid 向けの公式アプリがあるのですが、私の iPhone ではまったく動いてくれません >< 動いていても、Web から登録したセッション情報を同期できないなど、できが悪すぎ。
よっぽど、Gluon が JavaFX で作ったアプリの方がサクサク動いてます。セッションの登録情報を表示できれば、Oracle のアプリは使わないんだけどなぁ。
というわけで、今日聴講したセッションです。
- Adventures with Extreme Types in a Purely Functional Language [TUT1288]
- JDK 9 Language, Tooling, and Library Features [CON2497]
- JavaFX: New and Noteworthy [CON2483]
- A Survey of Memory Footprint Optimizations in Java SE and Java HotSpot VM [CON1938]
- Introduction to Troubleshooting in JDK 9: Serviceability Tools Are Your Friends [CON3733]
- Building JavaFX UI Controls [CON2476]
- Tools for High-Performance Polyglot Programming on the JVM [BOF4837]
今日はかなりマジメにセッション出てました。マジメにセッション出ると、ランチが食べられないというジレンマがあるわけですが、朝ご飯いっぱい食べたので大丈夫です。
Adventures with Extreme Types in a Purely Functional Language [TUT1288]
型の話といいつつ、関数型プログラミングの話。スピーカーは Canoo の Dierk Koenig。
この人、話し方も柔らかいし、発音がはっきりしているので、とても聞きやすい。まだ英語慣れしていないので、聞くのが楽でした。
Extream Type というのは特殊な方ではなくて、immutable value とか pure function とか constraint context などを加えた型についてだそうです。なんで型でを考えるかというと、No Silly Error とか Safe Refactoring とか Less Tricky Error とか Abstraction などの理由から。
Extream Type を使うと、暗黙的な制約を明示的にできます。コードで制約を書くのではなく、型で制約を与える方がいいということなのでしょう。型であれば、まちがいがあってもコンパイル時に分かりますからね。
現在の Java であれば、Stream や JavaFX の一部で Extream Type が使われています。
さて、はじめのサンプルとして、以下のプログラムが示されました。
import java.util.Optional; import java.util.concurrent.atomic.AtomicInteger; import java.util.function.Supplier; import java.util.stream.Stream; public class RNG { static Supplier<Integer> countGen(AtomicInteger i) { return (() -> i.getAndIncrement()); } public static void main(String... args) { final Supplier<Integer> numbers = countGen(new AtomicInteger(1)); final Optional<Integer> sum = Stream.generate(numbers) .limit(100) // .parallel() .map(a -> a^2) .reduce((a, b) -> a + b); System.out.println("sum = " + sum); } }
このプログラム、parallel メソッドのコメントを外すと正しい値になりません。問題は countGen メソッドで作成している Supplier オブジェクトです。Supplier インタフェースは関数型インタフェースなので、あたかも関数のように扱えます。しかし、ここでは countGen メソッドの引数になっている AtomicInteger オブジェクトに依存してしまっています。
つまり、Supplier オブジェクトは純粋関数としては扱えません。純粋な関数だけでプログラミングをしましょというのが、Koenig さんの主張。
そこで、例として取り上げられたのが、Online REPL の try.frege-lang.org です。frege では、ブラウザ上で Haskell の REPL を実行することができます。
その後、関数合成などの関数を用いたプログラミングの説明がされました。
ちなみに、frege は Haskell のコードを Java のコードに変換して、コンパイルしているようです。これもなかなかおもしろそう。
最後に Fizzbuzz を frege で書くのを紹介されたのですが、なかなかおもしろい。でも、Java の Stream には zip がないから難しいなぁ... と思っていたら、隣に座っていた @bitter_fox さんがさっそく Java で書き直してました。もちろん、zip も作ってあります。それが、こちら。
さすが、OpenJDK コミッタともなると、やることが早い!
JDK 9 Language, Tooling, and Library Features [CON2497]
Java SE 9 の言語仕様の変更や、ツール類の説明セッション。スピーカーは Joe Darcy です。
Joe はいつもの赤シャツ。Joe は Project Coin のリードだったことからも分かるように、言語仕様の取りまとめを行っている重鎮です。
Joe のセッションではおなじみなのですが、最初に言語仕様を変えるのは大変という話。Java 9 でもバイナリーコンパチが崩れる部分があるようです。
たとえば、AWT の peer が使えなくなるようなのですが、これは AWT 使っている人には結構いたいのじゃないかなぁ。
ツール関係でまず紹介したのが、jshell。Java の REPL です。昨日のキーノートでもやってましたね。
そして、Javadoc 関連。HMLT 5 に対応したり、検索が使えるようになるなど、いろいろ変更されてます。ちなみに、検索はクライアントだけで実行しているので、サーバーはいらいようです。
次に紹介したのが、javac で違うバージョンのソースをコンパイルすること。今までは -target -source そして -bootclasspath を指定しなくてはいけなかったのですが、新たに -release というオプションが導入されました。
-release N と記述した場合、-target N -source N -bootclasspath rtN.jar に相当するそうです。
そして、言語仕様。
まずは Project Coin。Java 7 で導入された Coin ですが、Java 9 でも言語仕様の変更を Coin で行っています。
@SafeVarargs の変更や、try with resources で final もしくは effectively final であれば、try ブロックの外側で記述できるようになったりしています。
また、ダイヤモンド演算子がやっと匿名クラスでも使えるようになりました!
さらに Java 8 で予告されていた、_ を 1 文字でメソッド引数に使用できないようになっています。Java 8 ではラムダ式では使えなかったのですが、Java 9 ではすべてのメソッドでコンパイルエラーになります。
@Deprecated もいろいろ変化しています。@Deprecated に関しては Dr. Deprecator こと Stuart Marks のセッションもありますが、とってないんですよね ^ ^;;; 後で資料をチェックしないと。
その他に、ダイヤモンド演算子やラムダ式で使う型推論を入れ子で使用するとコンパイル時間が長くなる問題があったのですが、それもかなり解消されたようです。
また、コレクションにファクトリメソッドの of が追加されています。Arrays.asList メソッドと同じように変更不可のコレクションを作成できます。
Java 9 は大きい変更は Project Jigsaw だけですが、細かい部分はいろいろと変わっているので、ぜひ資料をチェックしてみてください。
JavaFX: New and Noteworthy [CON2483]
JavaFX のロードマップ的なセッション。今年も、Kevin Rushforth と Jonathan Giles がスピーカー。
このセッション、去年と内容があまり変わっていないのです。なんか、残念。
JavaFX 9 での一番の変更は Jigsaw 対応。特に今まで公開していなかった skin 関連の API を公開するように変更することによって、いろいろ変わっていると (JEP 253)。
ちなみに、Jigsaw 対応の中で exports private というキーワードが出ていたけど、後で Jigsaw のセッションで確認します。
それと、今まで使用できていた impl_* のメソッドは全部使えなくなります。まぁ、しかたないか。ハックするときは impl_* から辿ることが多かったので、ちょっと残念なのですが ^ ^;;
それ以外の機能としては Hi DPI 対応。Mac はすでに対応済み、Windows では部分的に対応されていましたが、Linux でも Hi DPI をサポートします。これ以外にも小さな変更があるようですが、小さいんですよね。
去年のセッションでは Java 9 のリリース時期が伸びたからもうちょっと機能を追加できるかもといっていたのですが、あまり追加できなかったようです。
さて、Java 9 以降の話をちょっとだけ。
まだ計画段階なので、実際にどうなるかわからないですけど、たとえば AWT を必要としなくなるなどの変更を計画しているようです。でも、大きな変更はあまりないような気が... シェーダーはやっぱり入れてくれないのかなぁ....
A Survey of Memory Footprint Optimizations in Java SE and Java HotSpot VM [CON1938]
JVM のメモリ関連のまとめ的なセッション。でも、GC については触れないのです。スピーカーは Charlie Hunt。
Charlie は Salesforth に転職していたのですが、また Oracle に復職していました。全然知りませんでしたよ。
ちなみに、最近 Charlie は共著で Java Perfomance Companion という本を出しています。G1GC のチューニングに関してかなり書かれているので、G1GC を使うのであれば、必読ではないかと思います。
さて、なぜメモリのフットプリントが大事なのかということからセッションは始まりました。メモリは CPU に比べるとパフォーマンスが向上していません。このため、CPU やネットワークとのギャップがどんどん開いてしまっているわけです。
このため、キャッシュやメインメモリのフットプリントがダイレクトにパフォーマンスに直結することになっているわけです。
さて、メモリを調べるには、いくつかの方法があります。Java のヒープであれば、jmap や Mission Control のプラグインである JOverflow が使用できます。
次に、Java のヒープを削減するために取り入れられた手法の紹介。
たとえば、Java 6 で導入された Compressed Ordinary Object Pointer。多くのオブジェクトに対するポインターを効率よく表すために、64bit を使用せずに、もっと少ないビット数で表す手法です。
また、Java 8 で導入された Metadata やアプリケーションのクラスデータの共有なども。
Java 9 ではアスキー文字を 16bit を使わずに 7 bit で表す Compact String が導入されます。
最後に WebLogic のリソースマネージメントの説明があったのですが、よくわかりません。メモリ使用量がかなり減るらしいですよ。
Introduction to Troubleshooting in JDK 9: Serviceability Tools Are Your Friends [CON3733]
久保田さん、末永さん、髙雄さんのセッション。去年は BOF だったのですが、今年はカンファレンスセッションに格上げです。
この 3 人のセッションなのですから HeapStats の紹介セッションなのかと思ったら、それほど HeapStats には触れず。なんかもったいない。
jcmd と jhsdb と HeapStats の 3 本立て。でも、トピックがありすぎて、焦点がちょっとぼけちゃったかな。単にコマンドの紹介だけのようになってしまった感じです。
とはいえ、久保田さんは去年に比べればかなり落ち着いてしゃべってましたね。
Building JavaFX UI Controls [CON2476]
JavaFX で部品を作る話。スピーカーは Jonathan Giles。
開口一番、このセッションは 2014 年にやったけど、Java 8 や 9 のアップデートを加えてあるよと。でも、あまり変わらなかった。そりゃそうか。
このセッションでは JavaOne ボタンを以下の 4 種類の方法で作成していきます。ソースコードは Bitbucket で公開されてます。
- 既存のコントロールを CSS でカスタマイズ
- 既存のコントロールのスキンを置き換え
- 既存のコントロールを組み合わせて新しいコントロールを作成
- Control クラスを派生させて新しいコントロールを作成
数字の若い方が簡便な方法です。
でも、作るとしたら、結局は 3 か 4 だろうな。
Tools for High-Performance Polyglot Programming on the JVM [BOF4837]
複数の言語を Java プラットフォームで扱いやすくする Graal VM のセッション。スピーカーは OpenJDK の Graal Project のリードの Michael Van de Vanter。
Graal VM は JVM Compiler Interface 上に Graal コンパイラを作成し、動的にコンパイルすることができます。
このセッションでは NetBeans 上で Graal 使ってデモしてました。デモでは、NetBeans 上で Java のコードと Ruby のコードを示し、Ruby のコードでもデバッガでトレースできることを示してました。デバッガは Truffle とよばれているものです。
パフォーマンスも Ruby ではかなり向上しているようす。Scala などはあまり変わらないようでしたが。
Graal コンパイラでは Instrumentation を使用して、AST を操作して最適化や部分評価を行っているようです。なかなかおもしろい。こういう話が効けるのが、JavaOne の醍醐味の 1 つですね。
おまけ
去年の JavaOne では、セッションのアンケートの代わりに、赤黄青を入力できる JavaFX のアンケートマシンが使われていました。
今年はそのアンケートマシンがパワーアップ。画面が大きくなってます。でも、裏を見ると、やっぱり Raspberry Pi。でも、去年のむき出し状態とはことなり、ちゃんとケースに入ってましたよ。
というか、画面が大きくなったことと、ケースに入ったことぐらいしか違いはないわけです。
やるんだったら、もうちょっと新しいことをやればいいのに。
0 件のコメント:
コメントを投稿