[ダウンロード推奨]OOW2017 and Javaone2017 report Daisuke Nishino(Sompo Systems)

REPORT2017

Oracle OpenWorld / JavaOne 2017 REPORT | 取材・構成・文：西野大介（SOMPOシステムズ株式会社）

REPORT2017

はじめに：おすすめの読み方

この一枚で今年の話題総ざらい！

JavaOne 2017を知るキーワード10

IBM Special Session #1

IBMが“Java 8”を推奨する理由


IBMの“オープン化戦略”と MicroProfileが成したこと


“IBM × アメリカン航空”の事例で見る

カスタマー・ソリューションの現実解

Oracle Special Session #1

我々はなぜJava EEをEclipse Foundationに移管したか


オープンソースへのコミットと

Oracle Cloudが持つ品質への自信


Some Pieces of Advice

JavaOne Session #1

“偉大なテストケース”に必要な10のシンプル・ルール

JavaOne Session #2

あなたが知りたくて、でも誰にも聞けなかったこと

JavaOne Session #3

“RESTful API” のつくりかた

JavaOne Session #4

Java9、言語とツールはどう進化したか

Oracle OpenWorld Keynote #1

“自律型DB”その威力

Oracle OpenWorld Keynote #2

ビッグデータに価値はない

the Ambience of San Francisco

See You Next Year

5

9

13

14

15

19

20

21

25

27

28

29

33

35

39

41

Oracle OpenWorld / JavaOne 2017 REPORT | 取材・構成・文：西野大介（SOMPOシステムズ株式会社）P.3 P.4Oracle OpenWorld / JavaOne 2017 REPORT | 取材・構成・文：西野大介（SOMPOシステムズ株式会社）

（注：以下は、社内への展開時に、主として当社の非オープン系アプリ開発担当のメンバーに向けたメッセージです）

分量が多いので、全部読まなくてOKです！

難しければ本文は読まず、キーワードだけ拾ってください！

全く興味ない方は、写真だけでもさらっと見てみてください！

開いてくださった皆様が、技術に関する新たな知識をひとつでも獲得してくださったら、それだけで嬉しいです。

また、少しでも読まれたら、ぜひお気軽にご感想をお寄せいただければ幸いです。

それでは、次ページより始まる、年に一度のJavaの祭典をしばしお楽しみください。

SOMPOシステムズ株式会社西野大介（@nishino_chekhov）

はじめに：おすすめの読み方

P.5 P.6Oracle OpenWorld / JavaOne 2017 REPORT | 取材・構成・文：西野大介（SOMPOシステムズ株式会社） Oracle OpenWorld / JavaOne 2017 REPORT | 取材・構成・文：西野大介（SOMPOシステムズ株式会社）

E V E N TOUTLINE


この一枚で今年の話題総ざらい！JavaOne2017を知るキーワード10年に一度、サンフランシスコで行われる世界最大のJavaカンファレンス“JavaOne”。Javaは“世界で最も人気のある言語”とされるだけあり、IT業界全体で注目度を集めるHOTなワードをイベントの各所で頻繁に耳にしました。ここでは、今のJava、そして今のIT業界を知るうえで欠かせない10のキーワードをもとにして、JavaOne 2017の話題を総ざらいします。（初学者の方は、すぐに全てを覚えるのは難しいと思いますので、まずはここで用語に慣れ、少しずつなじんでいきましょう）

#1: “EE4J”今年最も欠かせないキーワードはこれ。Java EEについては、これまで実質的にOracleが仕様策定等の主導権を握っていた。今回、今後はオープンソース団体であるEclipse Foundationに移行されることを発表（つまり、同団体に参画しているRedhatやIBMなどと、Oracleが権利者として同列になることを意味する）。経緯等についての詳細はP.14およびP.19参照。なお、“EE4J”というのは“Eclipse Enterprise for Java”の略称で、移行自体のプロジェクト名称である（これがJava EE という名称にとって代わるのか、また別の名称となるかは不明）。

IBM、Redhat、Tomitribeの開発者が登壇し、これはポジティブな移管であると強調

今後、Java EE の開発主体はOracle から Eclipse Foundation へ

#2: “Java SE 9”9月にリリースされた“Java SE 9”について、キーノートでも大々的に取り上げられた。本バージョンの目玉は“Project Jigsaw”（プロジェクトジグソー）と呼ばれるモジュール化の採用（詳しくはP.29参照）。さらにリリースポリシーも変更され、仕様が固まってから出すというこれまでの方針から、必ず6ヶ月ごとに出すという“時間”ドリブンのリリースサイクルに変更。バージョン名はナンバリング方式をとりやめ、年＋月となる（初回は18.3）。バージョンによりサポート種類が全く異なる点も把握しておきたい（P.13参照）。

会場には巨大な"9"のモニュメントも設置され、Java9のリリースをアピール。なお、JavaSE 9と同時にJava EE 8がリリースされたということも、業界動向としてあわせて押さえておきたい

Java SE 9 遂にリリース！新機能の目玉は「モジュール化」

#3: “Docker”“Docker”とはコンテナ型とよばれる仮想化環境のこと。いわゆる“仮想マシン”（注：Windowsの上でmac OSなど別のシステムを動かすソフトウェアを見たことはありますか？あれのことです）とよく似ているが、仮想マシンが「OSごと仮想化する」のに対し、Dockerは「OSは仮想化せず、その上の部分に“コンテナ”と呼ぶ枠組みを作りそこだけ仮想化する」点が異なる。Oracleは“Kubernetes”（#4参照）と共にDockerサポート強化を強調している。詳しくはMike Lehmann氏への特別インタビュー（P.20）参照。

仮想マシンと比較した場合の最大のメリットは、OSより上だけを仮想化することによるサイズと処理の軽さ。大量のアプリを同一ハードウェア上で動かすクラウド時代だからこそ、そのメリットが最大限に活かされる

Docker とは仮想化環境のこと。Oracle は今後のサポート強化を強調

[関連]P14,19

[関連]P20

[関連]P13,29

#4: “Kubernetes”“Kubernetes ”とは、“Docker ”（#3参照）用の補助ツールのこと。Docker単体ではコンテナの作成や実行の機能などしかなく、コンテナはあくまで単独のマシンの中にしか配置できない。Kubernetesを使うことで、あたかも1台に配置されているかのように見せながら、複数台のマシンにコンテナを配置するということができる。1台のマシンパワーでは足りない状況で簡単に台数を増やしたり、障害時にマシンの切り替えが容易にできたりするというメリットがある。

Docker向けの同様のツールは他にもいくつかあるが、OracleはKubernetesが業界で勝利すると予測し、Kubernetesにコミットすることを宣言している（p.20参照）

Docker の効果を最大化する補助ツール。更なる台頭は確実

[関連]P20

#5: “Microservices”

昨年に引き続きよく耳にしたこのキーワード。これまでのように「一枚岩に固まった巨大なシステム」としてアプリケーションを作るのではなく、「ひとつひとつの小さいシステムを連携させる」ことでアプリケーションを実現させようというシステム構造の考え方のこと。機能変更が容易、障害時に大規模サービス停止を避けやすいなど様々なメリットがあり、大手企業がメインシステム刷新時に適用するケースが増えている。

SoptifyのプリンシパルアーキテクトNiklas Gustavsson氏が登壇。Pythonで構築されていたシステムをMicroservicesの考え方に沿ってJavaで再構築したエピソードを紹介した

有名企業での活用事例が増加中。Microservices は今後もトレンド継続

[関連]P20 #6: “Serverless”

去年と違い、今年は“MicroservIces”（#5参照）と同時に発言されることが非常に多かったこのキーワード。“Serverless”という言葉の通り、「サーバを意識せずにシステム構築できる」という考え方を指し、サーバが存在しないわけではない。やや定義があいまいだが、サーバを意識して管理せず済むよう（そういったことはクラウドに任せる）、DBや認証などの機能がサービスとして事業者から提供されるものが一般的。

Oracle社のバイスプレジデント、 Mike Lehmann氏も、MicroservicesとServerlessについて、必ずセットで言及していた（P.20参照）

使い手がサーバの存在を意識不要に。クラウドは急速にその方向へシフト

[関連]P20

#7: “FaaS”

“FaaS ”とは、“Funct ion as aService”の略称。“Servlerless”（#6参照）の考えをさらに推し進めたもので、機能そのものを事業者（Amazonなど）が公開し、1呼出ごとに課金といったサービス形態で提供される。有名なのはAmazonの“AWS Lambda”。※Serverless = FaaSとして解釈している巷の記事も多い。現時点でそれは拡大解釈であるものの、今後FaaSが隆盛してきた場合、実際にそういう用語として定着する可能性もあるだろう

クラウドサービスは様々種類があるが、アマゾンはそのいずれでもかなりのシェアを誇っている

機能を従量課金する FaaS 。その使い勝手の高さから大人気に

[関連]P20 #8: “Fn Project”

“Fn Project”は“FaaS”（#7参照）を実現するプラットフォームであり、オープンソースとして公開された。構成要素は“FaaS”を実現する“Fn Server”、開発用キットである“Java FDK”、実行を管理する“Fn Flow”の3つ。壇上では画像投稿サイトから画像を取得・処理しSNSに投稿するサンプルコードが公開され、機能の実行を直感的な実装で実現できることがアピールされた。Java以外にGoやPythonなど様々な言語に対応していくという。

ベンダーロックインしないという昨今のOracle Cloudのコンセプトを受け継いでいると言える、オープンソースのプラットフォーム。ServerlessやFaaSが隆盛していく中で、どれだけ支持を得られるかに今後注目していきたい

その実力はまだまだ不明。FaaS の雄になれるかはこれから

[関連]P20

#9:“Open J9” &“Open Liberty”

IBMは、自社のJava VMをEclipseFoundationに寄贈、“Open J9”として公開したことを発表。さらに、アプリケーションサーバである“WebSphere Liberty”の中核部分も同様に“Open Liberty”として寄贈された。「規模の大小を問わず幅広い開発者が活用することで、より多くのイノベーションがもたらされること」を期待しているという。開発者の話から、ロングタームサポートという考え方への適応としての側面も見えてくる（P.13参照）

#1に記載した通り、Java EEも移管されることとなり、Javaに関する多くの資産がEclipse Foundationに収束してきている

Java VM もアプリケーションサーバも全部 Eclipse Foundation へ！

[関連]P13,14 #10: “Future Projects”

今後のJavaの新機能として開発されているものが紹介された。“Pro ject Panama ”、“Pro jec tValhalla”、“Project Amber”、“Project Loom”の4つ。残念ながら時間の都合もあり説明は省略されていたものの、Valhallaは基本データ型を自分で定義できるようにし、Panamaはネイティブコードの最適化を行うものという既存情報あり。どちらも導入されれば、処理速度の向上に貢献するだろう。

キーノートではAmberのみ説明された。varという万能な型を使用できるようにするコンセプトで、一見するとJavaScriptなどに近い印象を受ける。

Java は今後も機能拡充し、簡単実装＆高速処理を追求していく

イーイーフォージェイジャバエスイーナイン

ドッカークーバネティス(*1)

マイクロサービスサーバレス

ファースエフエヌプロジェクト

オープンジェイナイン & オープンリバティ

*1:最も近い発音。現時点で正式日本語名はなく、呼び方は人によりまちまち


S P EC I ALS E S S I O N


at IBM

JavaOneを契機に、IBM社の錚々たるメンバーがサンフランシスコに集結。それにあわせ、我々だけに向けた特別セッションを設定していただきました。EE4JやOpen J9戦略の実態から、詳細なカスタマーソリューション事例まで、壇上を降りたスペシャリストが間近で語る臨場感を、ぜひ想像しながらお読みください。

写真は公開NGとなったため、別のものに差し替えています

IBMが現時点で“Java 8”を推奨する理由

IBM Java Roadmap

[IBM Special Session #1]

Javaのリリースモデルの変更にともない、IBMがどのように対応していくのかを解説。推奨バージョンについても言及され、“8”を推奨するということ、そしてその理由についても説明がなされました。

Open Source団体にJavaEEを移管しようと思っており、それをJavaOneで発表しようと考えていることを切り出しました。我々に対し、その案をどう思う？と。Happyか？それとも、それによりあなたたちのカスタマーに何か問題がありそうか？と。

その場で伝えられたのはわたしの意見ですが、Elicpse FoundationがJava EEプラットフォームとして最高だと言いました。MicroProfileもありますし、イノベーションも起こしやすいでしょう。それも、とても速い、ここ数年のJava EE標準とは比べ物にならない速度で。

Eclipse Foundationへの移管に踏み切った最初のきっかけは、MicroProfileであったでしょう。しかし2番目の理由としては、Javaユーザーにとってそれが最も良い選択であると考えたからだと思います。Oracleだけでなくもっと多くのメンバーたちがJavaのオーナーとなることで、Java EEを守り、そしてより速い速度で拡張していくことができますから。

Libertyをオープン化するということ

我々は先月、Libertyの中核コードをEclipse Foundationの下でオープンソース化するというプロジェクト“Open Liberty”について発表しました。我々は、これによって多くの開発者が自らのアイデアを本格的なアプリとして実現することに役立てることを願っています。そして、この決断により、Eclipse FoundationにはOpen Liberty、Open J9、EE4Jといった多くのJavaのフィーチャーが集結することになりました。

MicroProfileが成したこと

Eclipse Foundationには、MicroProfileがあります。IBMがRedhatやTomitribeなどとコラボしているもののひとつで、Javaを使用したマイクロサービス向けのプロファイル（注：特定の機能を抜き出してまとめるという概念）です。Java EE 7のサブセット（一部仕様の抜粋）から始まり、現在は独自仕様も追加されています。

立ち上げのきっかけは、Java EE 標準のマイクロサービス対応が遅かったからです。過去、我々はかなり長い間、マイクロサービスをJava EEのターゲットのひとつとすることをディレクションしていました。多くの人々がそれについてシリアスでしたが、残念ながらOracleはその中にはいませんでした。それが18ヶ月前に我々がMicroProfileをスタートしたきっかけです。そして、このプロジェクトを説明し、伝える場を設けたのは去年のJavaOne 2016の期間でした。私は、これこそがOracleがJava EEをEclipse Foundationに移行することを決断させたきっかけだと思っています。

Oracleとの話し合い、そして移管へ

実は8月に、話し合いの場を持つためにOracleをIBMに招待し、RedHatを含め3社で対話をしました。Oracleはそこで、

Ian Robinson , DE WebSphere Foundation

Chief Architect

ントチャート参照）。ひとつは6ヶ月ごとのリリースにあわせ、次のバージョンがリリースされるまでの間（つまり6ヶ月）のみサポートされるというもの。Java 9がその初めての対象となり、その次の18.3も同様です。

もうひとつは、5年間のサポートが行われるバージョンで、こちらはロングタームサポートの対象であるという表現をされます。直近では18.9がその対象となります。IBMがJava 8の次にサポートするのはこのバージョンとなります。

IBMはJava 8 を推奨

ガントチャートを見てお気づきかと思いますが、“旧”リリースモデルの最終版であるJava 8は、“新”リリースモデルのロングタームサポート対象よりもさらに長い保証期間となります。

我々は、最新のハードウェアとベストなテクノロジーで、Java 8を2025年までサポートします。セキュリティなど保守上の懸念もカバーされますし、このバージョンが最も推奨できるJavaです。

もちろん、最新を使用したいというニーズがあるユーザーもいらっしゃることを想定しています。常に最新バージョンを使用するために、我々はOpen J9という選択肢を用意しました。

安定性と最新、そのどちらを選ばれるかは、ユーザーの用途により決められるでしょう。

Javaのリリースモデル変更

先月リリースされた“9”を皮切りに、Javaのリリースモデルは変更されます。これまでは、新機能が実装されたら新バージョンとしてリリースする“機能”ドリブンのリリースモデルでした。しかし、それでは変化の速い現代に適応しにくくなることから、“時間”ドリブンのリリースモデルに変更となります。機能の仕様策定状況に関係なく、6ヶ月ごとに必ずバージョンアップされるようになり、バージョンもナンバリングではなく“18.3”などの日付を表すものとなります。

IBM SDKの対応方針

まず、IBMはJava9向けのIBM SDKを作成しません。Java9を使用したいユーザーは、Open JDKに加え、今回オープン化を発表したOpen J9（経緯などの詳細はIBMSpecial Session #2参照）を使うことで、オープンソースではありますが、IBMのテクノロジーをもとに開発を進めることができます。重要なのは、9月にリリースしたIBM SDK for Java(SR5)と同じJVMを、Java 9や18.3、18.9にも適用できるということです。

ロングタームサポート

“時間”ドリブンのリリースモデルは、2種類のサポート種類に分かれます（下ガ

当セッション最大のポイントはこの表。3行目に示されている8のサポート期間が、それより未来にリリースされるロングタームサポート対象のバージョン（6行目）よりも長いというところにある。IBM社はもともとProject Jigsawに対しJCPで反対票を投じる（その結果Java 9のリリースが遅れた）ほど、モジュール化に対し慎重派の姿勢を見せていた。もしかしたら、それがこのサポート期間の表明にもつながっているのかもしれない

Steve Wallin ,Program Director- IBM Runtime Technologies

IBMの“オープン化戦略”とMicroProfileが成したことWebSphere Update - On-Premises and in the cloud


今回発表されたLiberyのオープン化の話から、Eclipse Foundationへの移管について、Oracleから受けた相談内容を含めて経緯を伺いました。一年前のあの時期にMicroProfileを発表した意図も説明くださっています。

移管により仕様策定のプロセスがどうなるか不明で、その点が気がかりです。

JCPとEclipseとの進め方はまさに今議論中です。まずはGlassfishとそのソースコード、TCKの移管を優先し、その後、仕様策定のプロセスやガバナンスなどの見直しが行われると思います。これには数ヶ月要することを想定していますが、その見直しを経ることで、JCPの今の仕組みのよいところは残しつつ、新たなプロセスを作っていくことになるでしょう。

JCPは仕様策定に年単位の年月を要する点がネックでした。

我々もJCPの活動をもっと速いものにしたいと思っていました。その点でも今回の移管は効果を発揮するでしょう。

What About JCP? IBM社の見解 - Steve Wallin

移管にともないJCPはどうなるのか。この点に関するIBM社の見解については、会社代表としてJCPのExecutiveCommitteeに参加しているSteve氏（前ページ参照）が回答してくれました


―――

Steve

―――

Steve

写真は公開NGとなったため、別のものに差し替えています

“IBM × アメリカン航空”の事例で見るカスタマー・ソリューションの現実解

American Airlines Customer Solution


――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

――――――――――――――――――――――――――――――――――――――――――――――――――――――

――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

P.15 Oracle OpenWorld / JavaOne 2017 REPORT | 取材・構成・文：西野大介（SOMPOシステムズ株式会社）

このページは写真・本文ともに公開NGとなりました（興味深い事例を丁寧にまとめたページだったので、皆様にお見せできないのが残念です）


S P EC I ALS E S S I O N

at Oracle CVC

JavaOne講演の隙間を狙い、Oracleの未来を握る重鎮の方々から直接お話をうかがいました。オープンソースにコミットする意気込みや、Oracleから見たEE4Jへの思いなど、顔を突き合わせたからこそ見えるその真意を、この記録から読みとってください。

*

* CVC : Customer Visit Center

我々はなぜJava EEをEclipse Foundationに移管したか

Eclipse Enterprise for Java (EE4J)

[Oracle Special Session #1]

IBM社の特別セッションでも話があった今回の移管について、こちらはOracle社側の視点で解説されています。両者の立場の違いによる微妙なトーンの差を比べると、今後のJava EEの動きが少し予測できるように思います。

それが我々がビジネスに勝つという手段であり、決して独自機能を持つことではありません。独自の機能を持つということは、ユーザーを環境へロックインすることと同義でもあるからです。それはユーザーの望まない方向であり、我々もそれを望みません。

Fn Project

我々は、月曜のJava Keynoteで、コンテナネイティブなサーバレス開発のプラットフォームを発表しました。 “ F nProject”という名前で、オープンソース化します。これを用いることで、クラウドニュートラルな開発を行うことができます。このプラットフォームが持つ開発キットでビルドしたサーバレスアプリケーションは、Oracle Cloudだけでなく、Google Cloud、Microsoft Azure、AmazonAWS、どこでも動かすことができます。DockerとKubernetesに対応している限り。

我々はクラウドニュートラルなマイクロサービス＆サーバレスのプラットフォームを求めていました。AWS Lambda、Google Functions、Azure Functionsなど、いくつかサーバレスプラットフォームはありますが、いずれも本来オープンソースで完結するプラットフォームであるべきです。そして、我々は、その考え方を体現していきます。Fn ProjectとOracleCloud Infrastructureによって。

Kubernetes will win

Dockerに代表されるコンテナ型のアプリケーション実行環境。そのデプロイメントプラットフォームはMesosやDockerSwarmなど、様々あります。しかし、我々はその中でKubernetesが勝者となると考えています。Oracle Cloud以外でも、Amazon AWS、Microsoft Azure、GoogleCloud、どのクラウドもサポートしていますし、そして、クラウドニュートラルです。もちろん、オンプレでも動きます。

Oracleは3週間ほど前、Cloud NativeComputing Foundationにプラチナ会員として加入しました。それに先立ってKubernetesのプロジェクトにも参画しています。その事実からもお伝えしたいのは、我々は他のクラウドプロバイダとは違うということ。オープンソースの一部分をサポートするのではなく、オープンソースで完結すべきという考えを持っています。

そして我々は、Very Heavilyに、オープンソースコミュニティ側に立つことにコミットしています。これは過去のOracleのやり方とは異なる方向です。実際のところ、我々はSpringOneやKubeConなどもスポンサードしていますし、カンファレンスコミュニティへの参加にもVeryActiveです。Oracleは製品開発だけをしているのではないのです。

純粋にクラウドの品質で勝つ

さて、ここまでの話から、あなたはおそらくこう言うでしょう。「全てをオープンソースにしたら、Oracleはどうやってビジネスで勝つのか？」と。その答えは、クラウドの品質です。Oracle CloudInfrastructureというベアメタルプラットフォームは、セキュアかつハイパフォーマンスであり、高稼働率を誇る上に、コストパフォーマンスが非常に良い。この通り、純粋にクラウドの品質そのもの、

Mike LehmannVP Product Management

Container Native Application Development

ープンソース団体に移管することを決意しました。我々はこの8月、その評価をすべく、IBMとRedhatにコンタクトをとり、会話をし、彼らにアイデアを求めました。その場では、Apache SoftwareFoundationなどのいくつかの団体について話しましたが、会話の結果、EclipseFoudationを選択しました。よく知られている団体であり、Java EEについても熟練しています。何より、MicroProfileプロジェクトもやっていて実績があります。そこで、我々はJava EEをEclipse Foundationに移管し、同時にコミュニティスポンサーとなることを決めました。EclipseFoundationの持っているテクノロジーをサポートし、EE4Jに貢献するために。

Oracleが提供するもの

我々は、GlassFishやTCKといったJavaEEの技術群をEclipseにRelicenseします（注：TCKとはJava EEの認証を取るためのテストキットのこと。これを使用したテストを通らないとJava EE認証済のアプリケーションサーバーを名乗ることはできない）。そして、Eclipse FoundationはNimbleに動いていきますので、JCPのゆっくりとした仕様策定のリズムとは、必然的に足並みがそろわなくなってきます。つまり仕様策定においても、Eclipse Foundationが関わってくる流れに自然になっていくでしょう。

全てがNimbleになる。それによりJavaEEはさらなる進化を遂げていくでしょう。

Java EEとOracleを取り巻く課題

9/21にリリースしたJava EE 8。これは現代的な能力を持っていて、特にRESTfulサービスやJSONへの対応、新たなセキュリティ対応などの面でとてもよい進化をしています。しかし、これまで系譜を乱すことなく進化を続けてきたEEですが、8の先はよりNimble（ページ下参照）に対応し、プロセスを柔軟にすることが求められています。

例えばライセンス許諾の流れ。これまでベンダー各社は我々にライセンス許諾を得てから、アプリケーションサーバーに機能搭載ができるという流れになっていました。このプロセスは、ベンダーにとってハッピーではありませんでした。

仕様策定においてもそうです。Java EEは37の要素で構成されていますが、Oracleはそのうちの33の要素をリードしています。この事実は多くのベンダーにとって懸念であり、Javaのコミュニティにとってもハッピーではないことでしょう。そして、これらの事実はパブリックな問題に発展してしまっていました。ベンダーたちはコミュニティのメンバーに、アンハッピーであることを表明し、プレスにも伝えています。

IBM、Redhatとの鼎談

我々は、Java EE 8のリリースを迎えた今、これらの課題に対応する時機が来たのだと考えました。そして、Java EEをオ

今回の移管については、頻繁に“Nimble”（すばやい、俊敏）という単語が使われていた。この件の意思決定において、いかにその点が重要視されていたかが推察される

Will LyonsSenior Director, Oracle WebLogic Server and Java EE Product Management

オープンソースへのコミットとOracle Cloudが持つ品質への自信

Oracle Cloud - Container Native Application Development


Cloudを主軸に据えたOracle社のビジネス戦略について語っていただきました。その内容は、戦略として実にシンプルで、かつ我々ユーザーにとってメリットの大きい内容でした。これが市場にどのように受け入れられていくのかということが、今後のCloud業界全体の在り方に大きな影響を及ぼすのではないでしょうか。

*Mike氏の言う“サーバレス”は主として“FaaS”のことを指していると思われますが、ここでは氏の表現を尊重しそのままとしています


Fn Projectが流行るかどうか、それはFaaSの未来に直結するのではないか


Some Pieces of Advice


機能数が多いアプリケーションにおいて、開発やテストを効率的に行うためのアドバイスをいただけますか？

Jez HumbleとDavid Farleyが書いた“Continuous Delivery”いう本を知っていますか？（*1）その中では、テストの重要性について言及されています。テストとはコミットするたびにすべきものであり、そのために、テストが高速で完了するような仕組みを持つべきです。重要なのは、継続的なテストをやめてはならないということ。そのためには自動的にビルド、デプロイする環境をもつことが重要となります。これはJSFやプレゼンテーション層だけの話ではなく、アプリケーション開発全般において言えることです。 Continuous Deliveryを導入すると、何か問題があったときにすぐその直前の状態に巻き戻せます。それが非常に重要です。また、同種の手法は他にもあります。例えばcanary releaseと呼ばれるもの（*2）。こういったDevOps開発手法（*3）はいろいろありますので、開発チームに合ったものを選定して適用すべきでしょう。

JavaScriptを自前で開発することに対するメリット・デメリットなどをご教示ください。

PrimeFaces（*4）などのコンポーネントは便利ですが課題もあります。例えば、PrimeFacesはSpecificなバージョンのjQuery（*5）を持っています。異なるコンポーネントライブラリがまた別のバージョンのjQueryを持っていた場合、コンフリクトを起こしてしまう原因となります。自前で開発したJavaScriptの場合、そういった問題を孕まないのがメリットです。また、多くのJavaScriptを開発するならOracle JETという当社のツールをおすすめします。用いることで非常に簡単に実装できるためです。

プレゼンテーション層のパフォーマンスをあげるには、どういったアプローチをすべきでしょうか？

EL式を少なくすべきでしょう。あれはとてもヘビーウェイト。なぜなら、EL式は非常にダイナミック（動的）だからです。

将来的なJava EE 8への移行に備えるには、アプリケーションをどのような構造にしておくべきでしょうか？

CDIを活用しておくことでしょう。あの技術はJAX-RSやJSFの統合にとても良いです。CDIでの依存性注入を活用した構造にしておくことが、Java EE 8対応準備の重要なポイントとなります。

Ed Burns,JSF Spec Lead, Oracle

OracleのCVC特設会場。関係者のみが入場できるスペースで、プレハブのように建てられた会議室が特別セッションの舞台となる。

このセッションでは特定の技術や製品について説明いただくのではなく、こちらから持ち込んだ質問に対し一問一答で答えていただきました。出てきたのはアプリケーション品質に直結する具体的なアドバイスばかりで、どれも今後の開発に役立ちそうです。

Continuous Deliveryの重要性

――

Ed

PrimeFaces の問題点

――

Ed

EL式に注意

――

Ed

Java EE 8移行への準備

――

Ed

*1：Continuous Delivery

継続的デリバリー（CD）と呼ばれるDevOps開発手法のひとつ。コード修正の発生時に、自動でビルド、テスト、さらに環境配置までを実行するというもの。

*2：Canary Release（カナリアリリース）

炭鉱で有毒ガス発生を検知するためにカナリアを用いていたことからネーミングされた開発手法。新しいサービスなどを一部の特別ユーザーだ

けに先行公開するというもので、問題発生時にはそのユーザーの権限を一般ユーザーと同じに戻すことで、すぐに復旧作業を行えるというメリットがある。

*3：DevOps開発手法

開発 (Development) と運用 (Operations) を組み合わせた用語であり、開発担当者と運用担当者が連携して協力する開発手法を指す。主に、アプリケーションのビルド、テスト、リリースを迅速かつ頻繁に行うために用いられる。

*4：PrimeFaces

JSF用のリッチUIコンポーネント集のこと。パスワード入力ボックスやエラーメッセージ表示など、様々な部品が用意されているので、開発者が各自で作り込まなくとも見栄えのする画面が構築できる。

*5：jQuery

Javascriptのライブラリ（作り込んだ機能を他者も利用可能な状態にしてまとめたもの）のひとつ。利用者は、短い実装で様々な機能が利用できる。

JAVAONESESSION


#7 独立したケースのみとせよ

機能変更やテストの速度向上のために、一部のケースを削除することもあるでしょう。それらを素早く、ミスなく、容易に実現するために各ケースは独立させなければなりません。

#8 診断用データを用意せよ

アサーション（注：テストコードに埋め込み調査を容易にするメッセージ機能）や環境情報を活用すべく準備します。デバッグをシンプルにするためです。

#9 環境情報は外出しせよ

テストは環境に依存させず、持ち運び可能にしなければなりません。ポート情報、IPアドレス、ファイルパス、DB接続情報などは、テストケースといえど実装に組み込んではなりません。プロパティファイルやモックオブジェクトを活用しましょう。

#10 無関係な出力は避けよ

多すぎる出力物は混乱を招く元となります。何事もなく通過したことそのものが、テスト成功の結果なのです。

#3 スモール＆シンプルにせよ

各ケースを独立させるためにも、それぞれは小さく、シンプルに。そのためにも、必ずロジックとセットアップは分けます。

#4 １要素のみテストせよ

１シナリオにつきテストはひとつにします。なぜなら、なぜフェイルしたかを明らかにすべきであるからです。それこそが、迅速なデバッグを可能にします。

#5 速いテストのみ実行せよ

単体テストは可能な限り繰り返すべきです。それにより、プロジェクトが進行する中でも全体の品質レベルを保つことが可能となります。そのためには、実行に一晩かかるようなケースではなく、すぐに完了するケースとしておくことが重要です。

#6 絶対の再現性を保て

すべてのテストは信頼できるものでなくてはなりません。フェイルしたが、それがどのように発生したか再現できないテストは頭痛の種となり、価値がないどころかリソースの無駄です。

#1 まず事前に考えよ

偉大なテストを始めるために必要なこと。その第一ステップは、いきなりテストを始めるのではないということです。「何をテストするのか」そして「なぜテストするのか」を事前に考えることから始まります。そのためには、テストを単体⇒結合⇒業務テストのように小さい順に考えることは適しません。まず業務テストとして何があり、それをブレイクダウンしていって結合・単体テストに落とすという順に考えるべきです。

#2 わかりやすいケースにせよ

わかりにくく作ろうとする人はいませんが、わかりやすく作れていないケースは散見されます。「わかりやすさ」にはいくつもの視点があります。「文章がわかりやすい」ことはもちろんですが、「このテストの結果何が期待されているのか」や、「このケースで何が診断されるのか」といった意図の面。そして、「どのようにすればデバッグできるか」という解析の面でもわかりやすいケースにしなければなりません。

極めてシンプルな、しかしなかなか徹底できないテストの掟について、わかりやすくまとめられたセッションです。経験の長い方はあらためて初心に返るために、若手の方は基礎を知るために、ぜひこの記事でTIPSを確認してみてください。

“偉大なテストケース”に必要な10のシンプル・ルールTen Simple Rules for Writing Great Test Cases

Stuart Marks, OracleSteve Poole, Developer Advocate, IBM

[JavaOne Session #1]


“RESTful API” のつくりかたEffective design of RESTful APIs

Mohamed Taman, Enterprise Architect / Innovation & R&D Sr. Manager, e-Finance


マグカップなどの身近な例をもとに、APIデザインの進め方をわかりやすく教えてくれるセッションでした。あなたは、関連サブシステムとのIFを適切に定義できている自信はありますか？ぜひ、このまとめで手順を再確認してみてください。

APIファーストの精神

APIについて考える際、前提ととして最も大事なのは、「APIファースト」で考えること。それにより、新しい技術の利点を活かせるだけでなく、価値のある成果物を生み出せるので、チームメンバーも活性化できます。

価値のあるAPIを作るための5ステップ

価値のあるAPIを作る為のプロセスは、5つに分解できます（写真（上）参照）。ひとつずつ解説しましょう。

①関係者を特定する。関係者ひとりひとりをとらえる必要があります。彼らは誰なのか、組織内部・外部どちらの人間か、どういう存在か、簡単な説明も必要です。ここからは、コーヒーショップの例で説明していきましょう。

あなたは店の常連客です。他に

マグカップのハンドルはすばらしいAPI

RESTful APIの効果的なデザイン。それを語る上で初めに述べたいのは、「APIデザインは難しい」ということ。どの機能をAPIとして公開するのか、公開する最良の方法は何か、公開したらどのように改善のアプローチをとるのか。考えるべきことはたくさんあります。そして何より、使う側にとって使いやすく、わかりやすく、無駄がない姿を追求しなければなりません。

よいAPIデザインというのは、身近にたくさんあります。例えば、マグカップのハンドル。これはコーヒーと我々をつなぐ、実にすばらしいAPIです。この形状により、コーヒーが熱くても影響なく持つことができます。握るのも簡単です。そして、何の説明がなくても誰もが使うことができるでしょう。これこそがAPIの理想形です。

APIを作るための5つのステップは左記のとおり。これらはウォーターフォールのように一方通行で進めるのではなく、前後に進んで戻ってを繰り返しながらブラッシュアップするのがよいとのこと。

ト化する」「商品を参照する」「商品を検索する」「商品を追加・変更する」などがリソース定義としてあげられます。(b)次に、aの整理をもとにHTTPアクションに紐づけましょう（詳細は写真（下）参照）。(c)そしてそれぞれのリソースを「独立タイプ（単体で存在できるもの）」、「依存タイプ（親がいないと存在できないもの）」「リソースとリソースを結合するもの」に分けます。

⑤APIを検証する。最後にするのは、まず各リソースのアクションを付箋に書き出し、それを並べて各アクションを関連付けしましょう。そして俯瞰し、欠けている要素があればそれを書き加えた付箋を足します。

以上がAPI定義の手順です。REST、そしてHTTPは価値のあるものですが、適切に活用できなければ効果が出ません。あなたのAPIがすばらしいものになることを祈っています。

いるのは、レジ係、バリスタ、他の客などですね。関係者はこれで特定できました。

②関係者の活動を特定する。常連客のあなたは、(a)コーヒーをオーダーし、(b)できあがりを待ち、(c)コーヒーを受け取るでしょう。これは活動です。

③活動を詳細化する。(a)あなたはレジ係とともに、オーダーを完成させます。すると、(b)レジ係はバリスタにオーダーを投げ、(c)バリスタは受け取ったオーダーをキューに追加します。そして、(d)完成したコーヒーをあなたに渡すでしょう。

④APIを定義する。ここからはオンライン書店に例を換えて説明します。APIを定義する際の手順は、ここでさらに3つのステップに細分化されます。(a)リソースごとの活動定義。商品リソース、カートリソース、注文リソースなど様々ありますが、それぞれ定義します。商品なら、「商品をリス


Q.

A.

Q.

A.

Q.

A.

HTTPのアクションはGET、POST、PUT、DELETEの4種類。整理したリソースの活動に対応するアクションを整理していくのが、API定義をする上で欠かせない手順となる。

あなたが知りたくて、でも誰にも聞けなかったこと

Everything You Ever Wanted to KnowAbout Java and Didn’t Know Whom to Ask

Speakers:Java Champions, open source developers,JCP experts, JavaOne speakers, and others

第一線で活躍するJavaのエキスパートがずらりと並び、その場で質問を受けて答える怒涛のセッション！45分という限られた時間で答えたQ&Aの数は全29個。具体的な内容まで踏み込まれたものは一部でしたので、ここでは選りすぐった回答をご紹介します。


（左上・左下）その場で観客に質問を募集し、テキストで内容を書いていくという極めてインタラクティブなセッション。“JavaとCはどちらが速い？”という意地悪な（？）質問もあり、会場から笑いが起こった（右上）その場で質問に答えるのは、JCPのエキスパートやオープンソースの開発者、Javaチャンピオンなどの錚々たるメンバーたち

他言語と比較した場合のJavaの優位性とは？

まず、Write Once, Run Anywhereであること。加えて、一般的なアプリケーションからIoTまで、ひとつの言語を学ぶだけで多種多様な開発が行えるということ。さらに、最も人気のある言語なので、検索すればたくさんの資料が見つけられるということ。

Java EEの未来はどうなる？

ご存知の通りJava EEはEclipse Foundationに移管される。それによって起きるのはポジティブな変化だ。プロセスはオープンになり、Java EEにはより革新的な進化が続くだろう。なぜなら、ここにいる我々全員がそこに強い興味を持ち続けるからだ。

Javaはもう古い言語か？

Javaはこれからも進化し続ける言語だ。Project Panama、Loom、Valhalla、Amberと様々なプロジェクトが立ち上げられ並行開発されている。リリースサイクルも変わり6ヶ月ごとにその新しいフィーチャーを使うことができる。進化してるでしょ？（笑）

JShell

RubyやScalaなど、多言語では標準でついている“REPL（対話型評価環境）”。JavaでもついにJShellというツールが導入され、その環境が使えるようになりました。REPLとは、プログラムを読み込み（Read）、評価し（Evaluate）、表示（Print）、これを繰り返す（Loop）。の略。なんだか難しそうですが、要するに、コマンドラインで一行ずつJavaを書き、一行ずつ実行できるというツールです。以下に例を示します。jshell>というのがコマンドプロンプトで、例では2回実行しています（まず変数に文字列を入れ、次にその文字列を出力）。開発者の利便性向上に貢献するでしょう。

ツールの主な変更点

jshell> String str = “test msg”str ⇒ “test msg”

jshell> System.out.println(str)test msg

言語仕様（細部）の主な変更点 “核”への主な変更点

Javadoc Next

Java実装からHTMLを生成するJavadoc。これまではHTML4で記述されていましたが、9からHTML5に対応することに。また、検索窓が追加され、利便性が大幅に向上します。

Java9、言語とツールはどう進化したか

JDK 9 Language, Tooling, and Library Features

Joe Darcy, JDK Engineer, Oracle


Java9（JDK9）の主な変更点をざっとまとめました。細かいものは他にもあるものの、これさえ知っていれば9の知識としてまずは十分だと思います。ここではセッション内容の範囲を超えた解説も加えながら、ひとつひとつを紹介します。

一行ずつ実行できるのでちょっとした検証も簡単。その手軽さから、教育分野などでの利用者も多い

クロスコンパイルの新ポリシー

javacコマンドによる、過去のバージョンをターゲットにしたコンパイル（＝クロスコンパイル）には、“one plusthree back”というポリシーが導入されました。対応可能なのは現ver + 3ver前までとなります。

右上が検索窓。結果を t ypeとmemberで分けて表示するなど、細かい気配りも効いている

コレクションへの値設定

of()というメソッドが追加されました。これにより、冗長的だったコレクションへの値設定をまとめて行うことができるようになります。

モジュール化：①実装方法

“Project Jigsaw”と呼ばれていたモジュール化がついにJava 9で導入されました。モジュール化とは、「そのクラスがどのクラスと関係しているか」を、より厳密化できる仕組みのことです。これが一体どんなものかをイメージするには、実装方法から見るのが良いでしょう。モジュール化対象とするクラスはこれまでと変わらない書き方で実装するのですが、アプリケーションのルートディレクトリにmodule-info.javaというファイルを作成して配置する点が異なります。

module-info.java（公開側）

上記は、com.example.helloというパッケージをsampleserviceというモジュール名で公開するという記述です。

そして利用する側もmodule-info.javaを配置し、以下のように書きます。

module-info.java（利用側）

これでsampleserviceを利用できるようになります（なお非公開のモジュール名を書くとコンパイルエラーとなる）。

モジュール化：②効果

公開範囲を明確化することで、これまであいまいになりがちだった各クラス間の依存関係が明確化できます。さらに、標準ライブラリも含めて、必要なモジュールだけを組み込んで動かせるようになるため、ランタイムのサイズを軽くできます。個々のサービスが小さく数が多いマイクロサービスに適した変更点と言えるでしょう。

内部APIが利用不可に

モジュール化導入にともない、JDKの標準ライブラリそのものもモジュール化され、公開範囲が明確に指定されることとなりました。その結果、ほとんどの内部APIはアクセスできなくなります。なお、代替APIの提供が未完のものは当分の間利用可能とのこと。

モジュール化は必須ではない

なお、後方互換に優れたJavaという方針通り、従来の構造で実装し続けることも可という点も覚えておきましょう。

List<String> list

= new ArrayList<>();

list.add("val1");

list.add("val2");

Map<String, String> map

= new HashMap<>();

map.put("key1", "val1");

map.put("key2", "val2");

従来の実装

List<String> list

= List.of("val1", "val2");

Map<String, String> map

= Map.of("key1", "val1",

"key2", "val2");

String コンパクト化

Stringクラスの内部仕様を変更し、メモリ効率を向上させたとのことです（中身の変更のみであるため、我々がこの変更を実装時に意識することはない）。これまで全ての文字を一律2バイト文字（char[]）で扱っていましたが、大半の場合1バイト文字で足りることが分かっていたため、半分が無駄になっていたといいます。今回の変更により、1バイト文字/2バイト文字としての管理が適切に使い分けられるようになったとのこと（注：ネット上の開発者情報では、むしろ遅くなったという報告も見られ、どのような効果が出るかは現時点で未知数のようです）。

今回でいうと9 + 8,7,6までが範囲となる（さらに6は非推奨）

新実装。一度に値を設定できる

Applet API 非推奨へ

ひとつの時代が終わります。一時期まではそれなりに存在感を持っていたAppletですが、ついに9で非推奨となりました。実態として多くのブラウザで稼働しなくなりつつあり、時代の流れに沿った対応と言えるでしょう（Appletがどんなものかという説明は今さらなので割愛）。

・java.applet.AppletStub

・java.applet.Applet

・java.applet.AudioClip

・java.applet.AppletContext

・javax.swing.JApplet

今回非推奨となるApplet関係のクラスは上記の通り


module sampleservice {

exports com.example.hello;

}

module sampleclient {

requires sampleservice;

}

OPENWORLDK E Y N O T E


Oracle OpenWorld Keynote - Larry Ellison

“自律型DB”その威力Oracle Database 18c。Oracleが世界初の自律型DBとうたうそのデータベースは、DBAの仕事内容を大きく変える可能性を秘めた、新しいデータベースでした。恒例となったAmazonへのDisrespectとともに、そのデータベースの革新性に触れてください。

No Human Labor, No Human Error

自動走行車は安全です。なぜなら、人の手の介入がないから。システムにおいて、人の手の介入があるということは、ミスが入りこむ余地があるということです（No Human Labor, No Human Error）。

Oracleはこれをデータベースで実現しました。Oracle Database 18c。これは世界初の“自律型DB”です。システムの世界における脅威とはサイバー犯罪の観点、特にデータを盗まれること。その際はセキュリティホールが狙われます。自律型DBは、自動でそのパッチを施します。その脅威からデータを守るために。

サイバー犯罪が狙う"隙間"対策

通常、パッチ適用にはシステムを止めなければなりません。だから、セキュリティ懸念を発見した直後ではなく、少し期間を置いてから対応をします。その隙間こそが狙われる。自律型DBであれば、自動で、即座に実行できます。ヒューマンエラー

“AWSに比べ半額”を契約に盛り込む

その上、Amazonのクラウドは高額です。我々のシステムを使えば、Amazonの半額で機能が実現できます。今日この場で約束しましょう。我々のシステムなら、Amazon AWSより半額になる、それを契約書の中に盛り込むことを（ここで拍手喝采）。我々はそれだけ自信があるのです。

自動化がもたらす真の効果

自動化することで何が起きるか。システムにとってよいことはもちろんですが、データベースプロフェッショナルにとってもそれは同じです。彼らの仕事は減りません。むしろ増えるでしょう。バックアップなどの日常的に行っていた作業はなくなり、その分、データベースのデザインや、アナリティクスに時間を費やせるようになります。それは、より生産的な時間の使い方になるでしょう。そしてそれこそが、我々の望んでいたことです。

Larry Ellison,Chief Technology Officer, Oracle

が入り込む余地もありません。自動で行えるのはセキュリティ対

応だけではありません。プロビジョンやシステムアップデート、チューニングも自動です。

自動で行えるため、稼働率も上がる。このシステムは99.995%の稼働率を誇ります。この数値は、年間のダウンタイムが30分未満であることを意味します。とても短い時間です。

Amazon AWSとの違い

他社もこういった数値を出していますが、それらには必ず例外が含まれています。Amazon AWSの契約条項をお見せしましょう。この通り例外が書いてあります。稼働率保証において、システムがダウンしている時間は除外、Amazonのメンテナンス時間も除外、地域の停電時間も除外、ソフトウェアのバグによって起こった時間も除外...99%を超える保証をうたっていても、必ずこういった例外が書かれています。我々の契約にそれらの文言はありません。


昨年に引き続きAmazon AWSを痛烈に批判。今年は出典を明記した上で契約条項にまで踏み込む

自律型DBを使うことで、DBAはよりInnovativeな仕事に時間を使えるようになると力説

①群衆- ビッグデータ- オープン

コンテスト

俳優業のかたわらで続けるクリエイター支援

俳優業を辞めたことがあるんです。大学に進学するために。でも、実際には通ったのは“20分”でした。そのあとまたすぐ俳優に戻りたかったんですが、現実は厳しく、もう仕事はなかった。そこで“HITRECORD”というサービスを立ち上げました。オンラインで人とつながり、クリエイティブなことを一緒にできるという事業です。立ち上げはもう10年前になりますが、その間、本を出したりTV番組を作ったり...エミー賞をとった作品もあります。

そんな経緯もあり、わたしはインターネットが好きです。この発明のおかげで、いいことがたくさんありました。

しかし、今のネット文化の中では、コンテンツ作成における大きな制約が存在しています。

インターネット上のクリエイティブを縛る３要素

キーワードを挙げましょう。1つ目は“群衆(crowd)”。群衆はパワーがあります。“ビッグデータ”と呼ばれる統計により、たくさんの人が“いいね”をはじめとするインターネット上の行動により数多くのデータを提供し、企業はそれを活用しています。でも、その中の多くの人たちは、自分がデータを提供していることを知らないかもしれませんね。

また、群衆が参加する“オープンコンテスト”。ランク付けですね。インターネットでたくさん見られる手法です。あるテーマに対し募集があれば、誰でも参加できます。誰もが平等です。でも、彼らは“競争”をしており、“協力”しているわけではありません。ある人の良いアイデアは、別の人には障害になることがあるからです。

“幻となった” OpenWorld Keynote

ビッグデータに価値はないジョセフ・ゴードン＝レヴィット。映画“スノーデン”などで知られる俳優が、最終日のOpenWorldキーノートに登壇。その内容は、「データが未来を創る」と断言したIntelのJavaOneキーノートや、そのデータ分析能力を喧伝したOracle Analytics Cloudのプレゼンを真っ向から否定するテーマで、聴講者に衝撃が走る講演でした（そして、OpenWorldのキーノートは全てYoutubeにアーカイブされていますが、唯一この講演部分のみ存在しなかったかのように除去されています）。あまり知られていませんがクリエイター支援者としての側面を持つ氏の経験から語られるその内容は、エンジニア畑でないからこそ見える、インターネットの未来を予見した貴重な講演でした。長めの文章ですが示唆に富む内容なので、ぜひ多くの方に読んで頂きたいと思います。

次のキーワードは“フリーカルチャー”。何でもタダになりました。その最もいい例はGoogle検索でしょう。わたしたちは無料で多くのコンテンツやサービスを使うことができます。

しかし、それらは本当にタダなんでしょうか？Web上では広告による収益モデルが普及しており、そしてそれは、コンテンツの作者でない人にお金を届けています。音楽業界はそれが原因で衰退しました。

最後のキーワードは“ソーシャル”。これは、コンテンツを生み出しません。コミュニケーションのためだけに消費されるものです。インスタグラムの写真、いくら“いいね”がたくさんついているものでも、そんなに長い時間見ないでしょう？

“群衆”、“フリーカルチャー”、“ソーシャル”。この三本柱が変わらなければ、インターネット上でのクリエイティブに支障があるままです。

これまでの制約を打ち消す、代替の３要素

これらのキーワードを打ち消す3つの要素があります。これはわたし

が単に想像したことではなく、HITRECORDで実際に経験して学んだことです。

まず1つ目、“群衆”を打ち消すのは“コミュニティ”です。大事なのは“ビッグデータ”のように人を“数”で計るのではなく、“個”で見なければなりません。何かを調査したいとき、“いいね”の数を計算しても、深いことは何もわからないのです。うちのHITRECORDについては、ビッグデータには何もヒットしないでしょう。つまり、ビッグデータでHITRECORDの活動は復元できないのです。

また、群衆が参加する“オープンコンテスト”に対立するのが“リミックス”。例えば、ハンバーガーの絵を誰かが描いたとしましょう。すると次に、それをアニメにする人がいます。最初の作者が考えもしなかったことを、別の誰かがクリエイトする。これが“協力”です。これは、インターネット以前にはできませんでした。

2つ目。“フリーカルチャー”の文化には、代わりに“正当報酬 ( f a i rcompensation)”を提案します。我々は、リミックスに参加した人たちに対し、報酬を支払っています。

その金額は6年間で200万ドルになりました。そして、その間の訴訟は0件です。

3つ目の“ソーシャル”に対しては、“コラボレーティング”です。人々は単につながるのではなく、共通の目標に向かっていくことが大事です。HITRECORDはそうしています。例えば、“クリエイティブチャレンジ”と呼んでいる制度があります。写真や文章などさまざまなコンテンツについて、誰もがプロジェクトを発行し、資金調達を含めた作品制作が行える仕組みです。

インターネットは、もっと“大人”になるべき

今日の話の最後に、そのプロジェクトの事例紹介として、ひとつのショートムービーを紹介しましょう。“今夜初めて見た星”という名の作品です。ある日投稿された日記から脚本が作られ、ディレクションされました。そして演じる俳優が集まり、イラストレーターは動画に重ねる絵を描きました。さらにコンポーザーが作曲し、ミュージシャンたちが演奏した音楽も加えます。こうしたプロセスを経て作り上げた作品は、ハリウッドでは真似できないような出来栄えに仕上がりました。

今回取り上げるのは映像作品ですが、クリエイティビティというのは芸術分野だけではないでしょう。例えばジャーナリズム。優秀なブロガーはたくさんいます。教育はどうでしょうか。競争ではなく、コラボさせてはどうか、それもクラスの中ではなく世界中と。わたしはここで強調して言いたいんです、インターネットがそういった存在であればと！そのために、オンラインコミュニティはもっと“大人”になるべきなのです。そして、それこそがわたしのお伝えしたかったメッセージです。

ジョセフ氏が壇上を去った後、講演の最後に流れたのは、日記の投稿をきっかけに作られたというショートムービー。3分弱で終わるごく短いストーリーの中では、視覚障害を持つ少女が父のくれた赤外線カメラで初めて星を見るまでの過程を描いている。俳優とイラストが融合したその映像は、マスに向けた商用映画などにはない手作りの味わいが感じられる仕上がりとなっていた。少女が見た星空がどのような景色だったかは、ぜひ皆様にも実際にご覧いただきたい。タイトルで検索するか、以下のURLから視聴可能

https://www.youtube.com/watch?v=nX5

iuHnLlX8

“FIRST STARS I SEE TONIGHT”（今夜初めて見た星）

②フリーカルチャー

③ソーシャル

①コミュニティ- 個人- リミックス

②正当報酬

③コラボレーティング

氏の講演は負の要素と正の要素を完全に対比構造としてとらえ、説明していた。図で示すと右記の通り

インターネット上のクリエイティブ、これまでとこれから

これまでこれから


Ending


the Ambience of San Francisco

Ed Bunrsと対面。用意していた質問のうち、一つ目は細かい話すぎたのと緊張でなかなか伝わらず、冷や汗...。最終的には理解してもらえたものの、業務に寄り過ぎた内容でFW視点ではないから回答できないとばっさり。めげずに二つ目の質問をしたところ、そちらは伝わって一安心

Mike Lehmann（左）とWill Lyons（右）とも隣でしっかり相対し、質問の時間をいただけました

毎年恒例、世界各国J a v a コミュニティの方々のコラボ寸劇。今年はマトリックス！Kang-Fu Masterとして日本からはOracle伊藤敬さん、Java女子部横田さん、Javaチャンピオン桜庭さんが登壇。次々出てくるJavaジョークに会場は大受け

桜庭さんと寺田さん、二人のJavaチャンピオンに囲まれて写真撮影。感無量すぎる

完全自費でプライベートとして参加したというOracle伊藤智博さんとselfie!!（ピースサインしましょうと言ってノリで強制させてしまいました...快くやってくださる伊藤さんに感謝）

The Chainsmokersのライブにも無料招待。映像効果がすごく、空一面に雷のようなレーザービームが。写真にうまく写らないのが残念！

今年も出てますOracleショップ。書籍は当然すべて英語

ランチは無料配布されています。味は...しかし、セッションがツメツメでお昼に行く時間もとれないため、あるだけでありがたい！

月曜夜は J C Pメンバーが参加できるパーティへ。会場はこんな感じでめちゃくちゃ混んでます

会場のトイレをふさぐDuke

外はこんなです。暑そうで意外と冷える

02：JCP Party

01：Special Sessionの裏側

IBMセッションの最後は皆で記念撮影！（一部の方が帰られたあとだったのが残念！）

03：会場の様子

当社のアーキテクチャ説明を真剣な面持ちで聴くスペシャリストの面々

企業ブースはたくさん出展されてます。JavaやDukeのグッズ（バッグとか栓抜きとか）がいろいろ無料配布されていました

04：余興

05：グルメ物価は高めですがおいしいものがたくさんあるサンフランシスコ。今年はやわらかいステーキとカニをいただきました！


本編に入りきらなかったエピソード、ここで一気にお見せします。現地の雰囲気を感じてみてください！

一部の写真は公開NGとなったためマスクしています


SEE YOU NEXT YEAR!!

（写真は同行させていただいた浦川社長と、帰国前夜ホテル前にて）

[ダウンロード推奨]OOW2017 and Javaone2017 report Daisuke Nishino(Sompo Systems)

Technology

Transcript of [ダウンロード推奨]OOW2017 and Javaone2017 report Daisuke Nishino(Sompo Systems)