JJUG CCC 2016 Spring 聴講セッションのまとめ

日本Javaユーザグループ主催の「JJUG CCC 2016 Spring」に参加してきました。
JJUG CCC 2016 Spring | 日本Javaユーザーグループ

聴講したセッションのざっくりとしたまとめです。すでにセッション資料が公開されているものも多いので、興味のある人はそっちを読んでください。

公開されているセッション資料の一覧は @YujiSoftware さんがまとめて下さっています。超感謝。
JJUG CCC 2016 Spring ( #jjug_ccc ) - セッション資料の一覧 - 地平線に行く

Type Annotation for Static Program Analysis(櫻庭祐一)

Java SE 8で追加された JSR 308: Annotation on Java Types と、静的コード解析ツール Checker Framework に関するセッションです。

背景

アノテーションの主な役割は次の3つ。

  1. Code Generation - Annotation Processorを使ってコードを自動生成する。Java EEの分野ではこのケースが使われまくっているけど、ツールの裏に隠れてることが多い。
  2. Condition Description - Reflectionで条件を付ける。代表的なのはJUnitの@Testなど。
  3. Syntax Check - Annotation ProcessorやDocletで文法チェックする。

とはいえ、現状ではSyntax Checkにはあまりアノテーションが活用されていなくて、代わりにFindBugsやPMDなどの静的解析ツールが利用されていることが多い。
しかし、静的コードチェッカーは基本的にはコードのパターンマッチングでチェックするものなので、nullチェックのような振る舞いのバグについてはチェックできない。つまり、現在行われているような静的コードチェッカーのチェックだけではチェックが足りていないはず。ベンダー提供のアノテーションもあるけど、標準ではない。

JSR 308: Annotation on Java Types

そこで、振る舞いに関するチェックをアノテーションを使ってできるようにしよう、という考えにもとづいて追加されたのがJSR 308のType Annotation。スペックリードはAlex BuckleyとMichael Ernst。
Type Annotationでは、次の宣言に対してアノテーションが付けられるようになった。

  • TYPE
  • ANNOTATION_TYPE
  • PACKAGE
  • METHOD
  • CONSTRUCTOR
  • PARAMETER
  • FIELD
  • LOCAL_VARIABLE

型に対してアノテーションを書けるのでほぼどこでも使えるけど、使いすぎるとコードの可読性が落ちるので注意。また、次の場所には書けない。

Checker Framework

そして残念ながら、標準のType Annotationは用意されていない。Type Annotationを制定するためのJSR 305が提唱されているけれど、残念ながらこのJSRは休止中となっていて進んでいない。

そこで開発されたのが、コードの振る舞いをチェックするためのフレームワーク「Checker Framework」。Checker Frameworkでは、Type Annotationを利用して振る舞いのチェックができるアノテーションがいろいろと用意されている。
f:id:zinbe:20160521105025j:plain
これを使えばこれまで不十分だったチェックができる。現在、AntやMaven、Grade、EclipseIntelliJでChecker Frameworkがサポートされている。

基調講演2: Raspberry Pi with Java(Stephen Chin)

Raspberry Pi上で、Javaで作ったレトロゲームエミュレータを動かして、自前でゲームコンソールを完成させるまでの話。

NightHacking Tour in Japan

まず、現在Stephen達がやっているNightHacking Tour in Japanの紹介。バイクで旅をしながら各地でイベントやってます。
http://nighthacking.com/

NESエミュレータの開発

最近やっている取り組みは、NESNintendo Entertainment System:いわゆるファミコン)のエミュレータJavaで作って、Raspberry Pi上で動かすということ。で、こんな感じのものを作りました、と言って、実際に会場でスーパーマリオをプレイして見せた。
f:id:zinbe:20160521111950j:plain

ハードウェアはRasPiで、ソフト部分はは全部Javaで書かれていて、筐体は3Dプリンタで作ってある、とのこと。

ハードウェア部分

ディスプレイ出力にはDevice Treeを採用。Device Treeは画質が良くて表示が速く、消費電力も低いので今回の目的に適していた。ボードはAdafruit Kipperを使用した。ただし、これだとGPIOをほとんど使ってしまうので、GPIOピンが5本しか残らないという問題がある。
ファミコンのコントローラはボタンが8個(上/下/左/右/A/B/スタート/セレクト)あるので、ピンが3本足りない。そこで、左/右のボタンとスタートボタンを同じピンに割り当てることで5ピンで済むようにした(左/右が同時に押されることはない、という前提で)。

完成したゲームコンソールがこれ。
f:id:zinbe:20160521113345j:plain

ソフトウェア部分のチューニング

ただし、ここまではデスクトップの開発環境上で開発していたので、RasPiのARMプロセッサでパフォーマンスが上がるようにチューニングする必要があった。具体的には以下のようなことをした。

  • Swing VideoからJavaFXに変更 -> これだけで3〜4倍速くなったとか
  • CPU/PPU/APU間の同期を、ピクセル単位ではなく行単位で行うように変更
  • Bitwise Helper Functionをインラインに
  • Extractiong PPU Operations
  • Double MathをLong Mathに置き換え
  • Array Accessを使わないように修正
  • Replace loops whith System.arraycopy
  • PWM AudioがRasPiで遅くなる問題を修正
ケースの設計

ケースは3Dプリンタ(Ultimaker2)で出力。3Dプリンタは価格が下がってるのでプロトタイプにオススメ。モデリングAutodeskのFusion 360を使用。プロ用ツールなので高いけれど、趣味工作/学生向けの無償スタートアップライセンスもある。

ケースデザインで特に苦労したのはヒンジ部分。任天堂とかは金属パーツを使ってるけど、部品の種類を増やしたくないので全てプラスチックで作ることにした。でもプラスチックだとシャープなエッジは削れてすぐに丸くなっちゃう。試行錯誤の結果、六芒星型にしたら耐久性のあるヒンジができた。

Raspberry Pi with Javaという本にこの事例を書いたので参考にしてほしいとのこと。

Javaエンジニアに知ってほしい、Springの教科書「TERASOLUNA」 (倉元貴一)

NTTデータが提供しているSpringベースの「TERASOLUNA Framework」に関するセッション。

TERASOLUNAとは?

NTTデータシステム開発を支えるオープン系システムのための総合ソリューション。標準手順や開発環境、サポートなど、様々なものが含まれる。その中で使われているフレームワークが「TERASOLUNA Framework」。
terasoluna.org

TERASOLUNA Frameworkのコンセプト

昨今のJava開発ではフレームワークの活用は当たり前。最近ではSpringとJava EEの2強時代に突入している。この流れはこれからも続いて、どんどん標準化という方向に進んで行くと思われる。
現在のTERASOLUNA FrameworkはOSSを最大限に活用した上で、サポート提供と合わせてエンプラ適用に必要なガイドラインを充実させる、というもの。これまではOSSの上に独自の拡張機能を追加して、その拡張機能に価値の重点を置いていた。しかし標準化に進む現状では、極端な独自拡張が歓迎される時代ではないので、価値の重点をシフトとした。

フレームワーク本体だけではなくて、ガイドラインの充実に重点を置いていることが大きなポイントのひとつ。ここにはNTTデータのこれまでのノウハウが詰まっている。これを活用してもらいたい。

エンタープライズシステム開発におけるケーススタディ

課題1: 膨大なJarや設定ファイルの組み合わせがツライ。
大量の設定ファイル、バージョン依存、環境依存、etc...
ガイドライン
4.1. Webアプリケーション向け開発プロジェクトの作成 — TERASOLUNA Server Framework for Java (5.x) Development Guideline 5.1.0.RELEASE documentation

課題2: プロジェクト構成・アプリケーションのレイヤー化が難しい。
プロジェクトが進んでくるとアプリケーションのレイヤリングが複雑になってきてツライ。
ガイドライン
2.4. アプリケーションのレイヤ化 — TERASOLUNA Server Framework for Java (5.x) Development Guideline 5.1.0.RELEASE documentation

課題3: ソースの品質向上・品質維持が難しい。
DBアクセスや入力チェックのノウハウが統一されていなかったり、誰が書いたかわからない&なぜ動いているのか分からないコードが混ざっていたり、ひどいときはWebからそのままコピペされたコードあったりして怖すぎる。
ガイドライン
5.5. 入力チェック — TERASOLUNA Server Framework for Java (5.x) Development Guideline 5.1.0.RELEASE documentation

課題4: セキュリティ対策が大変。
セキュリティ機能をどう作ればいいのかが分からない。非機能要件も含めてちゃんと対策ができているのかが不安。
ガイドライン
6. TERASOLUNA Server Framework for Java (5.x)によるセキュリティ対策 — TERASOLUNA Server Framework for Java (5.x) Development Guideline 5.1.0.RELEASE documentation

ガイドラインの品質保持

ガイドラインそのものの品質を確保し続けることも重要。ガイドラインを更新しながら、いろんな環境でテストしている。その結果として、テストに使用したOSSのバグを見つけることも多い。そういう情報は積極的に開発チームにフィードバックしている。

セットアップをスマートにすればJava開発はもっと速くなる!(桑原雄一)

SIに必要な道具一式を揃えた「SIToolkit」に関するセッションです。

継続的デリバリーやりたい

現場の人は継続的デリバリーをやりたいと思ってる。でも現実には実践している現場はほとんどない。道のりは長そう。東京とシリコンバレーくらいの距離がありそう。8000キロくらい。
そもそも、自動テストやCIができるような環境をセットアップするまでが結構しんどい。セットアップが簡単になるだけでも、もっと速い開発ができるようになるのではないか?

SI-Toolkit for Application Development

そこで、SIToolkitというものを作っている。その中の、Java EEアプリケーションの開発環境を提供するのが「SI-Toolkit for Application Development」。
実体はMavenアーキタイプDBMSやAPサーバー、DBマイグレーションツール、自動テストツールなどがセットアップされていて、Mavenコマンド一発で実行できる。CIツール上でも簡単に動作させられる。デプロイメントパイプラインも簡単に構築可能。

SI-Toolkit for Application Development = すぐに&どこでも動かせるビルドパック。この環境さえできてしまえば、あとはプログラムを早く作ることに集中できる。

継続的デリバリーの頑張り所

継続的デリバリーをうまくやるには、プログラミングステージからパイプラインを意識しておくことが大切。そして、ビルドパックごとパイプラインに乗せるようにする。ミドルウェアについても、諦めずにビルドパック化する。

Javaが提供した「Write one, run anywhere」という思想は正しいと思っている。ビルドパックもここを目指すといいのではないか。

OpenJDK コミュニティに参加してみよう(KUBOTA Yuji)

OpenJDKの開発に貢献するための方法を紹介するセッションです。

OpenJDKの流れ

JDK 7がOSS化されたのがそもそものはじまり(OpenJDK 7)

  • OpenJDK 6 - OpenJDK 7から派生
  • OpenJDK 8 - OpenJDK 7から派生
  • OpenJDK 9 - OpenJDK 8から派生

JDK 7以降は、コードベースはOpenJDK 7。したがってOracle JDKも元はOpenJDK。

OpenJDKの貢献するモチベーション
  • バグを直したい
    • その結果はOracle JDKにもフィードバックされる
  • 便利な機能を追加したい

それに、30億のデバイスで自分のコードが走るなんて素敵やん?

困ったらどこを読めばいいか?
  • OpenJDKのContributingページとDeveloper's Guide

OpenJDK: How to contribute
The OpenJDK Developers' Guide

Main - Adoption - OpenJDK Wiki

改善案の出し方

MLにパッチを投稿するか、JEPとして機能提案する。まずはMLにパッチを投稿してみるのがおすすめ。
パッチはOracle Contributor Agreementにサインすれば誰でも投稿できる(締結していないと受理されない)。個人でも参加可能で、PDFを印刷・サインして指定のアドレスにメールで送れば、2週間後くらいに

パッチは最新版に対して書くこと。以前のバージョンへはバックポートされる。リポジトリはここ。
http://hg.openjdk.java.net/

全部で51プロジェクトある。基本はjdkX(今はjdk9)。jdkXはGAリリース前の開発リポジトリで、リリース後のアップデートはjdkXuになる。

パッチを書いたら、MLを選んで投稿する。MLはプロジェクトやコンポーネントごとに100個近くあるので説明をよく読んで選ぶこと。間違ったMLに投げると基本的には無視される。
パッチはメール本文に貼り付けて送ること。添付ファイルや外部サービスではダメ。

パッチが採用さるまでの手続き。

  1. JIRAへの登録
  2. レビュー
  3. リポジトリへのコミット

これらは自分ではできないので、手伝ってくれるスポンサー=権限を持ったコミッタ以上の人の協力が必要。

コミュニティでの役割

最初は役割無しの一般メンバー。貢献(Contributed-byに名前が付く)を重ねると権限がもらえるようになる。

  • Author - 2件の貢献で昇格。JIRAへの書込み権限やコードレビューサーバへのアクセス権限がもらえる。
  • Committer - 8件の貢献+投票で決まる。Auther権限と、コミット権限、スポンサー権限がもらえる。
  • Reviewer - 32件(推奨40件)の貢献+投票で決まる。Committer権限とレビュー権限がもらえる。