More than 5 years have passed since last update.

JavaOne 2016

Last updated at 2018-05-27Posted at 2016-09-25

JavaOneにはじめて参加させていただいた。

keynote

keynoteでは火星探索の話（とマシントラブル）で時間がなくなり、JavaEEの紹介が一瞬でスライドだけ流して終わる一幕もありつつ、めぼしい発表は、Oracle JDKをDockerで配布する（Comming Soon?）予定とのこと。

community keynoteでは、IBMが"Make Java Great Again"をかぶって登場、IBM JDKのオープンソース化が発表された。その他、ロボットと会話するCognitiveのデモなど。

Java 9 comming soon??

Java9は、当初の今年のJavaOneに合わせたリリース予定から2017/3に延期されており、JavaOne直前で2017/7への更なる延期が発表された。

keynoteでは、jshellとProject Jigsaw、jlinkでmoduleを指定して小さなカスタムJREを生成するデモが紹介された（カスタムJREもDocker Imageとして配布できるようになるのか良くわからなかった）。

Java 10以降に向けては、

public class Point(int x, int y){}

と書けるようになるとか、var hogeと書けるようになるというのが紹介され、「JavaをJavaScriptにするつもりか」「いやちゃんと型はある」なんてやり取りが繰り広げられた。

Modules and Services

module間のrequires/exportsの関係、uses/providesの関係が理解できた。

provides側のmoduleは必須ではなく、必要な依存性が解決ができなかったmoduleはスキップされる。呼び出し元ではmoduleの区別は基本的にできないため、どのmoduleを優先して使うかの工夫が必要。

jlinkでmoduleの依存性を解決してbindできるらしい（デフォルトではoff??）。

Java EE

Java EE 8 Update

"the world has changed"として、cloudへのdeployとmicroserviceへのシフトを打ち出された。

MVC1.0などを仕様からdropし、代わりにConfigurationとhealth checkの仕様策定が提案された。これからコミュニティに調査してフィードバックを得つつ、2017年中にJava EE8をリリース、2018年にJava EE9をリリースするとのこと。OAuth/opneIDやReactiveへの本格対応はJava EE9で。

このセッションに限らず、microprofile（Java EEの仕様の一部、現状ではCDI, JAX-RS, JSON-Pのみに対応する軽量版）についてあちこちで議論されていた。

Cloud-Native Java EE

Payaraのtutorial session。microprofile + JCacheでのデモが紹介された。

MicroProfile 1.0 Released!: http://blog.payara.fish/payara-micro-profile-1.0-released

https://github.com/microprofile/microprofile-conference

"Fat JAR or skinny WAR?"という話が印象的だった。組み込みWebアプリケーションサーバを含むFat JARもいいけれど、軽量アプリケーションサーバを含んだDocker Imageを用意しておくことを前提に考えると、build成果物はskinny warの方が取り扱いやすいケースもある。デモで見せていたサンプルでは、payara microを組み込んだjarが39MBに対して、warだと6.2MB。

その他、Vagrant AWS plugin + Vagrant ENV pluginでAWSにdeployするデモと、Payara microのofficial imageを利用して、Dockerにdeployするデモを紹介していた。

DevOps

あらゆるsessionで、当たり前のようにNetBeans上にDockerが並んでいた。

DevOpsは、考え方やツールの紹介のフェーズはすぎ、実際にどう運用していくかが話されているように感じた。

Microservices Evolution: Breaking Your Monolithic Database

１回のdeployでの変更（batch size）を小さくすること、Maintenance Window(定期リリース)のリズムを決めておくこと（それが毎日なのか毎週なのか毎月なのかはビジネス要件による）、モジュールの切り戻しが簡単にできることが重要。

それに際して、codeはstatelessなので難しくないがDBをどう扱うかは難しい。例えばカラム名を変更するのであれば、下記のようなステップを踏んで切り戻せるように進めて、最終的に変更前のカラムを削除するのは半年後とかでいいという話。

add column
copy data using small shards
code reads from the old column and writes to both
code reads from the new and write both
code reads and write from the new
delete the old column

microservice化のためのDB分割時のデータの共有についても、まずはViewを使うなどの現実的な手段もあることが話されていた。

View
Materialized View
Mirror Table using Trigger
Mirror Table using Transactional Code
Mirror Table using ETL
Event Sourcing

Keeping Your CI/CD Pipeline as Fast as It Needs to Be

Big One Buildでbuildに１時間かかる⇒他の作業が止まってしまう。
jarやwarを分割して、Networkのpipelineを組んでbuild⇒依存関係が長くなると結局buildは長くなってしまう
メトリックスを取って可視化して改善しよう

下記のような例が紹介されていた。

モジュールの変更頻度とbuildに要する時間を組み合わせて可視化したtemperature map
impact time: total time to run a build and all the builds that will be triggered as a result
weighted impact time: WIT = IT(A) * CR(A)

network buildが複雑化していったときって、branch運用はどうするんだろう。feature flagで管理してbranchなんて分けるなという話なのかな。

Dockerized System Testing, with a Dash of Chaos

arquillianというunit testとintegration testのgapを埋めるテストツールの紹介。

arquillian
- JUnitベースで@RunWith(Arquillian.class)を使って、一部のclassだけを含めた仮想的なDeployをつくってテストするツール
arquillian cube
- dockerを使って同様にテストするツール
arquillian cube q
- dockerを使ってChaosテストをするツール
- os/network(latencyなど)を含めた異常をランダムに起こしてテストできる

The Deploy Master: From Basic to Zero Downtime, Blue/Green, A/B, and Canary

kubernetes & openshiftのデモ。多くのDevOpsツールはfeature branchをうまく扱えないため、常にmasterにcommitするのが推奨されるが、A/Bテストをするときなどは工夫が必要という話がされていた。
https://htmlpreview.github.io/?https://github.com/redhat-helloworld-msa/helloworld-msa/blob/master/readme.html

Microservices

Microservicesというワードはとてもよく聞き、こちらはデータ管理方法、テストや耐障害性など実際導入するに当たっての課題について話されていた。

Microservicesとは、完璧であろうとする（"complete"）マインドセットから、manageable（管理可能？）マインドセットへの転換という言葉が印象的だった。

Introduction to Microservices in Java

非同期通信について、決済処理など失敗が許されない処理はどうするのか？という質問に対し、必要なものは同期通信すればいい、でも本当に同期でないといけないのかは考える余地があるのでは、という回答が印象に残った。たとえば、Amazonであれば注文を完了した後に決済が処理できず後からお知らせがくることもある。

Event SourcingとCQRSがいくつかのセッションで話題に挙がっており、このセッションでのEvent Sourcingの説明は分かりやすかった。

reasons for event-sourcing
- high write performance
- potential for command/query separation(CQRS)
- auditable
- replayable
- undo-able
- monitable
control over the versions of your state change / data (like git)

Bundling Microservices to Optimize Consumption for Devices with Spring Cloud and Netflix OSS

Spring Initializrでconfig server, service registry, backend, frontend(backendが落ちていた時の代替実装含む)用のプロジェクトを落としてきて組み合わせるデモ。Pivotalの方によるSpring Cloudのデモはあちこちでやられているのだろうけどはじめて見て、これが30分間のライブコーディングでできてしまうのはすごい・・・