JavaOne 2017 4日目レポート

遅くなろうが順番がめちゃくちゃだろうが、とにかく書くことが大事なんだ、と教わった。
JavaOne 2017の4日目です。この日はキーノート的なものは一切なかったので、ずっと個別セッションに出ていました。

Streams in JDK 8: The Good, the Bad, and the Ugly

スピーカーが、Simon RitterとStuart Marksというちょっと変わった組み合わせ。余談だけど、Simon Ritterの英語は早口なのにすごく聞き取りやすかった。
Stream APIを使った(あるいは使うべき)コードを見て、何がいけないのか、どう直すべきなのかを説明していくセッションです。Good/Bad/Uglyのセッションは、説明が明確で分かりやすいから好きです。

たとえば、

action=validate&key=10&key=22&key=10&key=30

みたいなURLパラメータをパースして、

action,validate
key,[10,22,10,33]

みたいな結果を取り出すコードを考えてみよう、という感じ。それで、UglyとかBadなコードを見せて、何がいけないのかを指摘する。

で、だいたい最初に悪いコード例が出される。

f:id:zinbe:20171004083350j:plain

基本的な指摘としては

  • Functionalに考える
    • 1つの中間操作とか末端操作の中に普通に複雑なロジック入れるのはStreamの意味がない
    • stateによって処理を分けるようなののも避けよう
    • 中間処理でprintlnで出力結果出して利用するのは良くない
  • Internal IterationとExternal Iterationをちゃんと使い分ける
  • 処理速度に注意する

みたいな感じ。

あと、Parallel Streamについては、以下のような感じの指摘でした。

  • Parallelにしたからといって、必ずしも速くなるわけではない
  • Parallel Streamsはcommon fork-join poolを利用しているので、その挙動を把握しよう
  • デフォルトのスレッド数=CPUのコア数。コンテナ環境とかは特に注意
  • ネストすると遅くなることが多い

Modules and Services

Java9のモジュールについて、サービスプロバイダの仕組みを解説。要するに、SPIの仕組みがモジュールが導入されてどうなったか的な感じの話でした。
モジュール定義にはrequiresとexportsの他にusesとprovideっていうキーワードがあって、使いたいサービスプロバイダを指定する場合(利用側)にはusesを、サービスの実装を提供する場合(提供側)にはprovideを使う。
f:id:zinbe:20171004093652j:plain

この場合だと、java.desktop側からは直接FirstPrintにはアクセスできなくて、必ずPrintServiceLookup経由で使うことになる。コード上はインタフェースが指定されていて、使う実装は実行時に決まる、いままでのSPIと同じ動き。
f:id:zinbe:20171004095148j:plain

java.desktopモジュールではこのサービスタイプをたくさん使ってる。
f:id:zinbe:20171004095306j:plain

あと、Optionalとかも使えるっていう話がありました。

55 New Features In JDK 9

ふたたびSimon Ritter。JDK 9の新機能をズラーっと説明していくセッション。ほぼ既知の内容でした。
というか、久保田さん(@sugarlife)が去年のJJUG CCCでやったセッションでほぼカバーされてる。さすがです。

www.slideshare.net

G1GC Concepts and Performance Tuning

G1GCの基本的な動きと、それをどうやってチューニングしていくかといったポイントの解説。
基本的には、GCのオプションつけて、ダンプして、Flight Recorderで見て、それを元にチューニングするという話。
ちょっとすぐにはまとめきれないので後回し。

The G1 GC in JDK 9

上のセッションと同じスピーカー。やる順番が逆のような気がした。
前半は、G1GCの基本的な仕組みをもっと詳しく解説、後半はJDK8からJDK9までに何が変わったかという話。
大きな変更点は以下の5つ。

  1. String deduplication (8u20)
  2. Class unloading with concurrent mark (8u40)
  3. Eagerly reclaim humongous regions (8u60)
  4. Adaptive start of concurrent mark (JDK9)
  5. More efficient collections (JDK9)

実質1つじゃんってツッコミは置いといて。
1は、2つの同値(equals()の結果がtrue)のStringオブジェクトがある場合に、その中身の参照先を同じchar[]にする。メモリは大幅に節約できる反面、CPU使用率は少し上がってYoungGCは少しだけ伸びる。

2は、オブジェクトが不要になったかどうかのマーク処理を並列で実行するというもの。fall-back full GCよりも処理は複雑でトリッキーだけど高速。

3は、1つの領域の半分を超えるようなでかいオブジェクトがあった場合、humongous領域に独立して格納する。これによって参照が無くなった段階で簡単に解放できるようになる。humongous領域は他の領域とは独立しているから、並列マークが完全に終わるのを待たなくても解放できる。

4は、Old領域の並列マークの開始タイミングを最適化する仕組みの導入。Old regionの並列マークは領域がフルになる前に完了しないといけないので、フルにならないようにするための安全なマージンが必要。一方でフルGCはギリギリまでやりたくない。そのマージンをどれくらい取るのかを実行時のデータを元にして最適化する。

5は、上記の他にもいろいろ改善されていて、実に250以上のenhancementsと180以上のbug fixesがあったよ、というお話。

あと、次のJDKに向けて開発中の機能として、パラレルfall-back full GC(JEP 307)とか、card scanningの高速化なんかが進められているらしい。

Troubleshooting Memory Problems in Java Applications

Javaアプリケーションのメモリエラーに関するトラブルシューティングのセッション。
OutOfMemoryErrorが起こったときに、その原因を探って、解消するための方法を解説。基本的には、GCのログとヒープダンプをとってちゃんとツールで追っていけば、怪しい箇所が見つかるよ、という話。あと、どういうときにメモリリークが起こりやすいか、何を見ればそれがわかるかなどが詳しく紹介されました。

Javaのメモリの問題は、おもに次の原因で起こる。

  • Memory Poolの設定ミス
    • Memory Poolのサイズ設定は適切に
  • Finelizerの過度な使用
  • 明示的なGC呼び出し
  • メモリリーク

メモリリークの解析や解消を手助けするツールやオプションは以下のようなものがある。

  • JVMオプション - HeapDumpOutOfMemoryError / PrintClassHistogram
  • JConsole
  • jcmd
  • jmap
  • GCログ
  • Eclipse MAT
  • NMT
  • メモリリーク検出ツール - dbx / libumen / valgrind / purify

Oracle Cloud Fest.17

この日は夜にAT&T ParkでOpenWorldとJavaOne参加者向けの特別ライブがありました。
出演したのはThe ChainsmokersとEllie Goulding。私はもともとそれほど興味が無いのと、疲れていたのとで、後ろの方で人と話しながらのんびり聞いてました。でもさすがに本番のライブのサウンドは迫力があっていいですね。

f:id:zinbe:20171004201342j:plain

JavaOne 2017 3日目レポート

2日目の分書いてないですが、Gihyo.jpにキーノートのレポートを書かせていただいたので、ひとまずそれで。
第1回 JavaOne 2017開幕,キーノート速報~Project Jigsawついにリリース!女性コミュニティ活性化,データが創る未来:Java 9のその先へ~JavaOne Conference 2017レポート|gihyo.jp … 技術評論社

Monitoring and Troubleshooting Tools Available in Your Java 9 “bin” Folder

JDK 9に含まれるモニタリングおよびトラブルシューティング・ツールの話。
主なものは以下の5つ。

jconsole

Javaアプリの監視と管理のためのグラフィカルツール。プロダクション環境でローカルで使うのは推奨しない。
リモートで使うには「com.sun.management.jmxremote.port=ポート番号」で起動。

jps

試験的ツール。対象のシステム上で動いているJVMを一覧表示する。ローカルでもリモートでも使えるけど、リモートで使うには対象のシステムでjstatdが動いている必要がある。

jstat

試験的ツール。JVMの状態を監視する。HotSpot VMのパフォーマンスを計測できる。リモートで使うには対象のシステムでjstatdが動いている必要がある。

jstatd

試験的ツール。JVMの状態をリモートで監視するためのデーモン。jpsやjstatなどをリモートで使うために必要。

JMC

Javaのミッションコントロールツール。JMXコンソールとJava Flight Recorder(JFR)を含む。
JFR APIJava 9でサポートされたので、カスタムのJFRイベントを作れる。新しいイベントもサポート(safepoint/codecache/compiler/G1/moduler)

その他、次のようなものもある。jhsdbって知らなかったのであとでチェックしよう。

  • jcmd
  • jdb
  • jinfo
  • jmap
  • jstack
  • jhsdb - Java HotSpot Debugger

以下のものはJDKには同梱されなくなった。

  • Java VisualVM
  • jhat
  • jsadebugd

Immutable Collections

immutableなcollectionって、本当はこういうものが欲しいけど、今のJava9でもまだちょっと足りないよね。じゃあどうしようか、という話。
まず、Immutable collectionに求めたい要件の提案。

  1. Manifest immutability
  2. Sealed
  3. Provide a bridge to mutable collections
  4. Efficient construction, updates, and copying

Java 9だとunmodifiable collectionsが使えるけど、上の要件は満たしてない。他のフレームワークはどうだろうか。

  • Guava - 1と2はOK。3は無し。4はconstructionとcopyingは一部OKだけどupdatesは無し。
  • Eclipse Collections - 1と3はOK。2と4は無し。
  • Vavr, Clojire, Scala - 全部OK。

Immutable collectionの実装はMapやSet、VectorのPersistent data structureにつながる。Hash Array Mapped Tries(HAMTs)がEfficient persistentのベースになる。ということで、ここから先はこのHAMTsベースのCollectionsを実際に自前で実装してみよう、という話でした。

Modules in One Lesson / Migrating to Modules

Mark ReinholdによるJigsawのセッション。2つとも満席。
MarkがJava 9のModulerの使い方について実際に目の前でデモ。emacsでその場でプログラム書いて、コマンドラインコンパイルしたりjlinkしたりする。目の前でどんどんコード書いて動いていくのは分かりやすくていいんだけど、新しい話はほとんど無かったのは残念。突然SwingSet2を起動して見せたのはちょっと笑った。

JDK 9 Language, Tooling, and Library Features

JDK 9のおさらい。あとで書くかも。

OpenJ9: Under the Hood of the Next Open Source JVM

IBMが開発してEclipse Foundationに寄贈したJavaVM「OpenJ9」の話。
http://www.eclipse.org/openj9/

ランタイム技術はEclipse OMR(とOpenJDK)ベース。つまりJITとかGCなんかの基礎部分はOMRをベースに作られていて、その上に起動の高速化とかメモリ使用量の削減みたいな拡張を加えている感じ。
ちょっと面白そうなので、余力があったら別途まとめたい。

最初の勢いで書いてたら体力がもたないことに気づいたので、尻すぼみですみません。

【JavaOne 2017 初日】Geek Bike Rideに参加してきました

JavaOne 2017に参加するためにサンフランシスコに来ています。

今日はJavaOne Geek Bike Rideという、JavaOneに来てるみんなで自転車でゴールデンゲートブリッジを走ろうぜ、というようなイベントに参加してきました。
JavaOne Geek Bike Ride 2017 - Silicon Valley Java User Group (Mountain View, CA) | Meetup

3つほど丘を登りますが、レンタサイクルでのんびり走る非常にゆるい感じのイベントです。

ちなみに自転車はここで借りました。
マウンテンバイク1dayで40ドル弱。今回のコースくらいなら余裕でした。

自転車を借りたら、こんな感じでゆるゆると集合。
f:id:zinbe:20171001091036j:plain

超快晴。絶好のサイクリング日和。でも風邪がちょっと冷たいです。
f:id:zinbe:20171002014252j:plain

私は例によってJJUG CCCスタッフTシャツを着ていきました着ていきました。右の後ろのが私。
f:id:zinbe:20171002155713j:plain

ゴールデンゲートブリッジの下をくぐって。
f:id:zinbe:20171002020226j:plain

上まで登って、橋を渡って対岸まで行きます。
f:id:zinbe:20171002025010j:plain

対岸から。かなり参加者が多かったので、途中で自然に何グループかに別れて走りました。私は最後のグループ。
f:id:zinbe:20171001111544j:plain

最後にメキシカンレストレンで軽く昼食を食べてから、フェリーに自転車を乗っけて帰りました。
f:id:zinbe:20171002051702j:plain

ものすごい快晴だったので気持ち良かったです。
他の参加者とも、どこから来たの?何回めなの?どんな仕事してるの?みたいなお決まりの会話で交流をしました。
相変わらずのつたない英語でも話に入れてもらえたし、みんなフレンドリーで楽しかったです。

意外と戻るまでに時間がかかって、予定してたセッションのいくつかを見逃したのは誤算でしたが、まあそれでも思い切って参加して良かったです。

バルセロナのJavaコミュニティイベントに参加しました

JBCN Conf 2017という、バルセロナJavaユーザグループが主催しているコミュニティカンファレンスに来ています。
www.jbcnconf.com

参加のきっかけ

バルセロナに来ることになったのは完全に私的な事情で、たまたま妻が長期旅行でスペインに滞在していたので、このタイミングで何かカンファレンスが無いかなと探したら、JBCN Confを見つけたのでした。毎年やっている結構大きなイベントのようだし、発表は英語と書いてあったので、いい機会だから様子を見てこようと思って参加を決めました。

JBCN Confとは

Barcelona JUGが中心となって主催しているJava言語やJVM関連技術のためのユーザカンファレンスです。2017年は最大4トラックで54セッション、トークセッション2日とワークショップ1日という計3日間にわたるイベントでした。参加者数は450人以上とのことです。
どんなセッションがあったかは、公式サイトで公表されているのでそちらを参照してください。ラインナップは日本のJJUG CCCなどと似たような感じだと思います。Java Championによるセッションもあります。

ハッシュタグ#jbcn17」をチェックしてみてください。

参加費

参加費はノーマルで199€、Eary Birdだと少し安く(値段失念)、Late Birdだと299€。この中にランチやレセプションパーティなどの費用も含まれています。あと、カンファレンスTシャツとかのアメニティも。


言葉について

発表や公式のアナウンスはすべて英語です。参加者はスペイン語カタルーニャ語バルセロナを含むカタルーニャ地方の言葉)を話している人が多いですが、ほぼ英語も通じました。英語ネイティブでない人が多いので、日本人にとってはかえって聞き取りやすいように思います。こちらの拙い英語も丁寧に聞こうとしてくれます。

ただ、公式ハッシュタグを付けてツイートすると会場のSocial Wallに表示されるのですが、これがマルチバイト文字に対応していないようで、日本語でのツイートは見事に文字化けしてしまってちょっと恥ずかしかったです。

こんな感じで呟いたんですね。


そしたら
こんな風になっちゃって、ホワイトボードの内容を合わせるとなんとも滑稽な感じに。

会場

トークセッションは、郊外の大きなショッピングモールに入っているシネコンで行われました。シアター4つを貸切にして4トラック分。スクリーンは格段に大きいし、椅子のクッションもいいので、セッションを聞く分にはこの上なく快適でした。1部屋の席数が十分にあるので、完全に満席だったのは基調講演だけで、あとは余裕を持って座れました。非常に贅沢な席の使い方で、これは有料イベントでないと難しいでしょうね。

ランチとおやつ

ランチとして軽食がついています。ピンチョス程度のものが中心ですが、量は余るくらいにありました。それとは別に、午前と午後にコーヒーブレイクとして長めの休憩があり、ケーキなどのおやつとドリンクが出されます。コーヒーとジュースは常に用意されていて自由に飲めます。

さすがにスペイン。料理はおいしかったです。


レセプションパーティ

初日の夜にレセプションパーティがありました。会場は市街に近いビーチにある店で、カンファレンス終了後にシャトルバスで移動したようです。私は妻を待たせていたため参加しなかったのですが、楽しそうな写真がツイッターに上がっていました。

JJUG Tシャツ

せっかくなので、JJUG CCCのスタッフTシャツを着て行きました。でっかいDukeが目立つので、こを見て声をかけてくれる人もいました。自分から話しかけるのは勇気がいるので、持ってて良かったJJUG Tシャツ。


ついでに勝手にJOnsenの宣伝もしてきた。


受講したセッション

(後日書く)

現地からはひとまず以上です。

f:id:zinbe:20170619212121j:plain

Javaの生みの親であるJames GoslingがAWSに移籍したそうです

James GoslingがBoeing Defense(元Liquid Robotics)を辞めてAWSに移籍したそうです。
www.facebook.com

このニュースで、去年の12月にLiquid Roboticsがボーイングに買収されていたことを知りました。
Boeing to Acquire Liquid Robotics to Enhance Autonomous Seabed-to-Space Information Services | Liquid Robotics Liquid Robotics

Goslingが所属していたLiquid Roboticsは水上ロボットを使った海洋データ処理を事業としているベンチャー企業です。たしか以前JavaMagazineで紹介されてたとはず思って探したらありました。2012年だから5年も前か。
http://www.oracle.com/webfolder/technetwork/jp/javamagazine/JAVA-SO12-LiquidRobotics.pdf

Liquid Roboticsを立ち上げたBill Vassは元Sun MicrosystemsのVice Presidentで、Goslingとは古巣の同僚になります。Wikipediaによると、Bill Vassも2014年にAWSに移籍していたみたいです。
Bill Vass - Wikipedia

GoslingはAWSのようなクラウドベンダによるベンダロックインを批判したりしていたこともあるので、AWSへの移籍は正直驚きでした。これから何を始めようというのか、ちょっと楽しみです。re:Inventにも出たりするのかなあ。

まだSun時代のJavaOneのときに、Goslingと一緒に撮ってもらった写真はちょっとした宝物です。手に持っているのは自作のDukeネクタイ。
f:id:zinbe:20170523122008p:plain

JJUG CCCボランティアスタッフのススメ

日本JavaユーザグループによるJJUG CCC 2017 Springに、ボランティアスタッフとして参加してきました。
JJUG CCC 2017 Spring

会場で話を聞いていると、意外とボランティアスタッフを募集していたこと自体を知らない人もいたようなので、個人的な感想も含めて振り返ってみます。なお、参加方法や仕事の内容などはあくまでも今回の話なので、次回以降ではまた変わる可能性もあります。

ボランティアスタッフとは

JJUGのイベントの運営は幹事の方々(ちなみにこの人たちも無報酬のボランティアです)によって行われているのですが、CCCは特に参加人数が多い巨大イベントなため、当日手伝いができるスタッフを募集しています。

どうやったらなれるか

DoorkeeperのJJUGグループで、JJUG CCC本体の参加申し込みがオープンするのと同じくらいの時期に、ボランティアスタッフの募集ページが開設されます。
【東京】JJUG CCC 2017 Spring ボランティアスタッフ募集!! - 日本Javaユーザーグループ/Japan Java User Group | Doorkeeper

DoorkeeperやTwitterなどでのアナウンスがあるので、見かけたら躊躇せずに参加申し込みボタンをポチッと押すだけです。今回の募集人数は30人で、募集が始まって比較的早い時期に埋まったような気がします。前回(2016 Fall)はなかなか埋まらなかったり、前々回(2016 Spring)は一瞬で定員になったりと、人気には波があるみたいです。

どんな仕事があるの?

下記募集サイトに書いてある通りですが、次のような仕事のお手伝いをします。

  • 各セッション部屋の案内とタイムキーパー - 聴講者を案内したり、スピーカーに「10分前」とかの札を出す係。
  • 聴講者用椅子の追加などの部屋運営 - 聴講者が多い部屋に椅子を移動しいて設置したりする。
  • ブース部屋でのドリンク配布 - コーヒーの補充とかゴミ袋の交換など。
  • 懇親会会場設営・他諸準備 - 懇親会会場の机や椅子の準備、片付け。

1日中ずっと仕事があるわけではなくて、作業分担を決めて交代でお手伝いをします。担当セッションなどにもよりますが、実働はだいたい2〜3時間程度。それ以外の時間は好きなセッションを見たりできます。

ボランティアスタッフの特典

ボランティアスタッフとして参加すると、こんな嬉しいことがあります。

  • JJUGのTシャツ(スタッフが着ていた緑のやつ)をもらえる
  • スタッフの打ち上げに参加できる
  • 幹事や他のスタッフと交流しやすい
  • 運営に貢献できる

なぜやろうと思ったか

実はボランティアスタッフとしての参加は今回で4回目です。ボランティアスタッフを募集するようになったのが2015 Fallのときからなので、なんとそれ以来の皆勤です。
最初のときは、募集の案内を見つけて瞬速で申し込みボタンを押しました。Javaコミュニティにはこれまでも散々お世話になってきたので、どんな形でもいいから貢献したいと思っていたところでした。
とは言いつつも、このところ仕事ではめっきりJavaを使っていないし、記事もあまり書いていないということで、正直言ってちょっと気後れしている部分がありました。そこにきて、誰でもOKという募集。飛びつかないわけにはいきませんでした。

参加してみての感想

参加して良かったかどうかということに関しては、4回連続で瞬速で申し込んでいるという事実から察してもらえると思います。お手伝いとはいえ、スタッフとして参加することで、自分の中でのモチベーションはグッと上がります。

その一方で、担当の時間以外で自分の見たいセッションにもちゃんと参加することができたので、参加者としても十分に楽しむことができました。

今回特に良かったと思うこと

前述の通り、今回で4回目ですが、スタッフ間で何をどこまで手伝っていいのかなどの感覚がつかめてきたこともあって、回を重ねるごとにボランティアスタッフも動きやすくなっているように感じます。今回は特にボランティアスタッフ同士で気付いたことを指摘し合って、自主的に動くことができていたかと思います。椅子の移動など、最初の頃に比べるとかなりスムーズになったと思うのですが、これは自画自賛でしょうか。

また、前回まではボランティアスタッフ同士の交流というのはそれほど無かったのですが、今回は打合せの後に飲みに行く機会などもあり、それなりに交流を持つことができました。とてもいい傾向だと思います。

あと、個人的にはスタッフ打ち上げでSteavenやSebastianとちゃんと話ができたのも嬉しかったです。英語をもっと頑張らないといけないと実感させられました。

最後に

運営に対する不満の声も耳にしますが、参加者1000人を超えるの規模のイベントなので多少の不手際は仕方ないかと思います。本当に、幹事の方々の奮闘には頭が下がるばかりです。

もちろんまだ改善できる点はあるかと思いますが、コミュニティイベントなので、ただ不満の声をあげるのではなく、参加者も一緒になって解決していくべきところだと思います。そういう意味でもボランティアスタッフとしての参加は非常にオススメです。きっと得るものは大きいし、運営にも貢献できるしで、お互いに幸せになれると思いますよ。

f:id:zinbe:20170520204223j:plain

f:id:zinbe:20170523003842j:plain

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権限とレビュー権限がもらえる。