JavaOne 2015の準備中、InfoQは、今年のカンファレンスのセッションカタログの中で、注目するスピーカーたちに話を聞いた。
エンタープライズアプリケーションの世界におけるHTML5とJavaScriptクライアント
John Brock氏、主席プロダクトマネージャ、Oracle
Geertjan Wielenga氏、主席プロダクトマネージャ、Oracle
InfoQ: 企業の中で、NetBeansはHTML5とJSクライアントの開発にどのように適合しますか?
Wielenga氏: NetBeansは、いろいろなものを1つにまとめます。AngularJSと他の主要なJavaScriptフレームワークと共に動く、すぐに使えるツールを提供します。JavaScript、CSS、HTMLが動く、高度なエディタも同様です。また、ChromeとNetBeansで相互に作用できるChromeプラグインがあります。例えば、NetBeansで変更されたことは、直ちにChromeで更新され、Chromeのアプリをクリックすると、デスクトップでもモバイルデバイスでも、関連するDOM要素がNetBeansでどこに定義されていかをすぐに見られます。さまざまな機能がありますが、Cordovaとの統合はこちらで見られます。
https://netbeans.org/features/html5/index.html
これらすべては無料であり、こちらからNetBeans IDEのHTML5/JavaScript のバンドルをダウンロードできます。
InfoQ: あなたのセッションから持ち帰ってほしい重要なことは何ですか?
Wielenga氏: JavaScriptエコシステムは、常に新技術がやってきては去っていく不安定な環境です。それにもかかわらず、意味のあるアプリケーションをこのドメインで作成できます。その場合、エコシステムのどの部分があなたのニーズに関係し、使用に耐えるほど安定しているかを、常に注意深く決めなければなりません。
InfoQ: NetBeansが社会的に意味を持ち、革新的であるようにするために、Oracleは何をしていますか?
Wielanga氏: 150万ユーザのNetBeansコミュニティに、ニーズが何かを継続的に尋ね、NetBeansがNetBeansを使う人たちの役に立つかどうか、そして、どのように役に立つのかを知るために、ツールと技術の状況を継続的に評価しています。
Java 8 Stream APIとRxJavaの比較: パターンとパフォーマンス
José Paumard氏、CTO、JPEFI
InfoQ: Java 8 Stream APIとRxJavaの主な違いは何ですか?
Paumard氏: これらは両方ともストリームに関するAPIです。手短に答えると、Java 8 Stream APIはストリームに関するAPIで、RxJavaはリアクティブストリームに関するAPIです。それ以外では、これらのAPIでは、データ処理のパイプラインを書くことができます。同時に複数のソースからデータを消費し、カスタムのソースに接続できます。最も大きな違いは、J8のコンテキストでは、パイプラインはソースからデータを引っ張りますが、RxJavaは生成されるデータを聞いているものがあり、自主的にデータを生成するソースを聞くことができます。これにより、データ処理のパイプラインの設計に新しい問題が生まれます。主な疑問は、もしパイプラインの速さが十分ではなく、生成されたデータすべてを消費できなかったらどうなるかということです。これにより、考えられるユースケースによって、裏側にある疑問と、様々な解決策が浮かんできます。JDK 8でリアクティブストリームを構築するために、Java8 CompletableFutureとJava 8 Streamを組み合わせられます。こうすることで、私たちが必要なことはすべて提供されますが、構成するのは難しいことです。アプリケーションを構築する、より簡単なモデルが確かに必要でしょう。
InfoQ: RxJavaが未来の波になると感じますか?
Paumard氏: リアクティブストリームの疑問に関して、現在、数多くの活動があります。RxJavaは1つの答えであり、答えは他にもあります。現在、JDKにReactive Stream APIを作成しようとする動きがあり、9に入るはずです。私は、「リアクティブなJavaへ」という別の講演で、このAPIについて話します。9の活動は、すべてのリアクティブAPIの相互運用を可能にするインタフェースといくつかのクラスの共通設定を提供します。(http://gee.cs.oswego.edu/dl/jsr166/dist/docs/ でFlowクラスを探してください。) そこに書かれている通り、RxJavaは、私がJavaの中で推奨するものではありません。APIは、1つのメインとなる、非常に大きな1万ライン、250メソッドのクラス、Observable、をベースにした複雑なものです。「クリーンなコード」とはほど遠いところで、スタティックメソッドを多用しているため、テストは悪夢のようです。実際に、RxJavaは、.NET APIを書き換えたもので、いくつかの欠点があります。パフォーマンスはそのうちの1つです。RxJavaは、あるユースケースでは効率的に使えますが、使えない場合もあります。一言で言えば、リアクティブなパターンは、現代のアプリケーションで必要な多くのことを提供します。RxJavaはまだ開発中のため、いくつかの共通の問題は解決する必要があります。新しいツールが開発され、開発者やアプリケーションアーキテクトとして、私たちは、絶対にこの課題に注目し続けなければなりません。
InfoQ: Spring 5はリアクティブアーキテクチャに注目するという、Spring Teamの 最近の発表 についてどう思いますか?
Paumard氏: Springが最近リアクティブアーキテクチャに向かっているという発表を見て、私は驚きませんでした。Springは常に新しいプログラミングモデルの最先端にいて、そのようなモデルを作り出せることを、これまで私たちに示してきました。リアクティブは、マイクロサービスととてもよく合い、マイクロサービスを組み合わせて、繋げて、構成するために、とてもクリーンで設定が簡単なモデルを提供します。また、例外の扱い方も見事です。裏側にある疑問は、難しい質問です。ユースケースに基づいて扱うべきでしょう。将来、この課題について、新しいことをもっと見られると私は確信しています。
怒りのJava 8
Trisha Gee氏、開発提唱者、JetBrains
InfoQ: 開発者がJava 7を使うべき理由はありますか?
Gee氏: 考えられる理由はありません! サポートは終了していますし、Java 8より優位な点は間違いなくありません。時には、新しい技術の採用に対して組織が保守的になるために、Java 6を使い続けている人たちがいます。私は、そのような組織の多くが、6から、直接、8を使い始めるのを見ています。
InfoQ: 講演のタイトルから、あなたはJava 8をかなり使いこんで、気に入らないことを見つけたようですね。気に入らないことは何ですか? それらの問題をJava 9は解決しますか?
Gee氏: あぁ、それはよくある誤解です。講演のタイトルをこのようにしたことを後悔し始めました。「怒りの」は、「実行中の」や「現実世界の」の意味です。これは、一般的な英国人気質ですが、誰もがこの言葉を聞く訳ではありません。この講演の目的は、「これはラムダです」「これはストリームです」という、ただスライドを示すためのものではなく、完全に動いているアプリで、Java 8を使っていることを示すことです。
Java 9に関して、その中には確かに興味深いことがありますが、Java 8が持っていたものより、日々の開発の中では、ほんの少しのインパクトしかないと思われます。(それでもやはり、Java 9のStream APIには、いくつか拡張部分があります。これらは、無限ストリームの使用に関して、私が好きではないあることを確実に扱ってくれます。)
InfoQ: あなたのセッションから持ち帰ってほしい重要なことは何ですか?
Gee氏: 開発者として、新しい機能がどのように動くのかを感じて欲しいと思っています。ただ新しいシンタックスに気付くだけでなく、ラムダやストリームを使うかもしれない場合や使う場所、そして、問題の考え方をどのように変えるかを理解して欲しいのです。また、Java 8がよりよい解決策を提供するか、それとも、従来のアプローチがより簡単で、理解しやすいどうか考える時に、決めなければならないことも紹介したいと思います。最後に、IDE (私の場合は、明らかに、IntelliJ IDEAです!) が、従来の実装方法から、新しい機能を使った方法へ移行するのに役立つことを紹介したいと思います。
MVC 1.0 (JSR 371) の紹介
Santiago Pericas-Geertsen氏、テクニカルスタッフのコンサルティングメンバ、Oracle
InfoQ: なぜ開発者は、Spring MVCのような人気のあるフレームワークではなく、MVC 1.0を使うべきですか?
Pericas-Geertsen氏: MVC 1.0は、Java EE 8の一部である標準 APIであり、複数のベンダがサポートしているからです。また、多くの開発者がすでに使っていて、人気のあるJAX-RS APIをベースにしているからです。
InfoQ: 今日、JavaScript MVCフレームワークは、従来のサーバサイドMVCフレームワークよりも人気があるようです。クライアントのMVCが人気のある世界において、なぜサーバにMVCが必要なのですか?
Pericas-Geertsen氏: ウェブUIフレームワークになると、どんな場合にも上手くいく解決方法はありません。サーバサイドからクライアントサイドに移行した企業が、パフォーマンスの問題にぶつかり、サーバサイドに戻ったという報告を聞いています。JSをベースにしたクライアントサイドのフレームワークは素晴らしいものですが、次の10年間は、両方のアーキテクチャが共存する余地があると信じています。仕事にぴったりのツールを使いましょう。
InfoQ: あなたのセッションから持ち帰ってほしい重要なことは何ですか?
Pericas-Geertsen氏: MVC 1.0の基礎と、JAX-RSと拡張点の関係を学んでください。次のプロジェクトでMVCを考慮できるように、十分な情報を収集してください。
HTML5ウェブコンポーネント、Polymer、Java EE MVC 1.0を使った現代的ウェブアプリ
Kito Mann氏、主席コンサルタント、Virtua, Inc.
InfoQ: あなたは、Java EE MVCについて話し、長い間、JSFを提唱しています。MVC 1.0 対 JSFについてどう思いますか?
Mann氏: これは、必ずしも二者択一の提案ではありません。Java EE MVCは、Spring MVCのように、アクション指向のフレームワークです。あるチームにとって、従来のアクション指向MVCフレームワークはよい選択ですし、他のチームにとっては、JSFのように、コンポーネント指向のMVCフレームワークがよい選択です。そして、何らかの理由で、両方のモデルが必要ならば、それも十分可能でしょう。最初は、私たちはJSFの上にMVCを構築しようと考えました。(それは十分可能です。) しかし、別々にしておくことにしました。
InfoQ: 今日、JavaScript MVCフレームワークは、従来のサーバサイドMVCフレームワークよりも人気があるようです。クライアント側のMVCが人気のある世界で、サーバ側にMVCが必要な理由は何ですか?
Mann氏: 私はこの業界に長くいるので、私たちがある特定のアプローチの長所と短所を学ぶにつれて、アーキテクチャの好みは、行ったり来たりすることを知っています。すべてのケースに合う、たった1つのアーキテクチャモデルは決してありません。サーバにすべてをおくことは、プラウザでできることを制限し、ハードウェアの必要性を増加させます。クライアントにすべてをおくことで、より拡張できるようになりますが、クライアントにより多く負荷をかけます。このため、様々なハードウェアプラットフォームで、様々なブラウザがある場合、実行するのが難しくなります。ちょうどよいのは、どこか真ん中辺りでしょう。純粋なJSフレームワークよりもサーバを使いますが、純粋なサーバサイドフレームワークよりも、少なくします。しかし、ユースケースに関わらず、重要な点は、Java EE プラットフォームは、様々なオプションをすべてサポートしなければならないことです。
InfoQ: 私が、ウェブコンポーネントとPolymerでウェブアプリを書いている開発者だとしたら、どうしてJAX-RSではなく、サーバでMVC 1.0を使うべきなのですか?
Mann氏: MVCの素晴らしいところは、JAX-RS上に構築されていることです。 (最初は、JAX-RSの一部にすることを議論しましたが、JAX-RS EGは別々にしておきたいと考えました。) 実際には、JAX-RS上の小さなレイヤです。だから、ルーティングを扱い、ビューを返すようなウェブアプリの機能を持つ、純粋なRESTサービスを簡単に組み合わらせられます。(Facelets、JSP、その他にVelocityやThymeleafのような技術もあります) これにより、サーバサイドテンプレートやデータバインディングを使うところに強みがあります。
NetflixはDevOpsをどう思っているか - 妨害者 : そうではありません
Dianne Marsh氏、エンジニアリングディレクタ、Netflix
InfoQ: Netflixは、クラウドを使うパイオニアであり、オープンソースのクラウドツールを作成してきました。クラウドを展開し、より簡単にモニタリングするのに、どのオープンソースツールを推薦しますか?
Marsh氏: Asgardは、何年もの間、クラウド展開の最先端でした。私たちは、Asgardから学んで構築した、新しい展開ツールに取り組んでいます。これは、単なる展開ツールではなく、実際は継続的デリバリプラットフォームです。ワークフローを管理する段階で、これは、強力なツールになるでしょう。あと2、3ヶ月、お待ちください。
モニタリングに関して、私たちのAtlasツールは、十分役に立っていますが、だれでもこのような複雑なツールが必要な訳ではありません。私が必要不可欠だと思うのは、Janitor Monkeyです。クラウドの中で、使われていないインスタンスを削除するので、費用を管理するのに役立ちます。使用しないものに、支払う必要はありません。
InfoQ: より多くの開発者が運用の役割を担うようになるにつれて、従来のシステム管理者に未来はありますか?
Marsh氏: システム管理者は、自分たちのサービスを展開し動かす開発者とは、まったく違う仕事をします。例えば、システム管理者はサードパーティのツールを管理します。開発者は、自分たちがビルドしたものを動かします。これは、時には、コードを読んで不具合を修正できないツールを管理するよりも、明らかに簡単です!
InfoQ: あなたのセッションから持ち帰ってほしい重要なことは何ですか?
Marsh氏: DevOpsは、かなりいろいろなものを詰め込んだ言葉です。その前のアジャイルのように、沢山のことを1つにまとめて、それらがみんな同じ価値があると仮定しないように気を付ける必要があります。しかし、大部分は、参加者たちが、ツールのサービスの中で何が行われているか洞察し、ツールの真価を認めることと、自分たちの会社でどのツールが役に立つかという情報を手に入れてほしいと思っています。
Oracle IoTクラウドサービスを紹介
Harish Gaur氏、プロダクトマネジメント部門シニアディレクタ、Oracle
Pete St pierre氏、主席プロダクトマネージャ、IoTクラウドサービス、Oracle
InfoQ: Oracle IoTクラウドサービスとは何ですか?
Gaur氏: IoTクラウドサービスは、Oracle PaaSポートフォリオに新しく追加されたものです。Oracle IoTクラウドサービスを使えば、顧客はどのデバイスでも安全に接続し、デバイスデータをリアルタイムで予測分析することができます。そして、エンタープライズアプリケーションの中でビジネスプロセスを拡張できます。これにより、Oracle PaaS、JD Edwardsを含む、OracleやサードパーティのSaaSアプリケーション、Oracle E-Business Suite & Oracle Fusion Applicationsで事前ビルドを統合し、予防的なメンテナンスや資産のトラッキングのためのIoTアプリケーションを迅速に開発できるようになります。
InfoQ: 競合相手はだれですか? あなたの製品はどこが優れていますか?
Gaurd氏: IoTは混み合った市場です。ある点に関して解決策を提供するベンダがいくつかありますが、Oracleは他にはない点がいくつかあります。
a) プラットフォーム: Oracleは、スマートゲートウェイ、デバイス接続性、セキュリティ、エンタープライズアプリケーション全体のアナリティクスをつないで、完全に統合されたプラットフォームを提供する唯一のベンダです。IoT CSは、複数のエンタープライズアプリケーションをすぐに接続できるようにするので、IoTアプリケーションを素早く開発できるようになります。
b) デバイスの仮想化: まず、会社の他のデバイスに接続できるようになります。簡単なAPIとして、すべてのデバイスを公開します。つまり、CRMやサービスクラウドのようなエンタープライズアプリケーションは、トランスポートプロトコルやメッセージ形式等の技術的な差異を心配せずに、これらのデバイスと接続できます。
c) セキュリティ: セキュリティは、最も重要なことです。Oracle IoTクラウドサービスにより、アプリやユーザのように、デバイスは社内で第1級オブジェクトになり、エンドツーエンドセキュリティを提供します。
d) アナリティクス: Oracle IoTクラウドサービスは、リアルタイムで歴史的なビックデータと、デバイスデータの予言的アナリティクスを可能にします。これにより、顧客は、デバイスから流れ出るデータを理解し、重要なパターンや例外を識別し、意思決定できるようになります。
InfoQ: この提案は、企業をターゲットにしていますか、それとも、開発者をターゲットにしようとしていますか? 学生やオープンソースプロジェクトには、フリーアクセスを提供しますか?
Gaur氏: 私たちのターゲットは、工業生産、輸送、物流管理のような産業にいる企業です。はい、IoT1クラウドサービスを試す顧客やパートナーに対して、無料で試してもらいます。IoTクラウドサービスクライアントライブラリを含む、IoTクラウドサービスのいくつかの技術的なコンポーネントは、オープンソースです。
Java 8でiOSアプリをビルドする
Shay Shmeltzer氏、プロダクトマネジメントディレクタ、Oracle
InfoQ: 私は、2、3年前にOracleで働きました。その時、私たちはiPadの開発に「TAP」フレームワークを使いました。そのフレームワークはJSFのように見えて、開発者たちはXMLを書いて、iOSアプリを作成できました。あなたのセッションでは、このフレームワークについて話しますか、それとも、もっと新しくてよいものがありますか?
Shmeltzer氏: 私のセッションでは、Oracle MAFについて話します。これは、おそらくTAPの時代に使っていたものを進化させたものです。MAFは、Javaを強化するデバイスで動くMVCベースのフレームワークです。HTML5で解釈して表現するビューを定義するためにXMLを使い、コントローラとモデルレイヤを書くためにJavaを使います。
ビルドしたアプリはiOSとAndroidの両方で動きます。Oracleは、内部的にMAFを使い、100以上のアプリをビルドし、今ではiTunesやGoogleストアで提供されています。
InfoQ: iOSアプリをビルドするのに、開発者はJavaを使うべきだと思うのはなぜですか?
Shmeltzer氏: 世の中には、何百万ものJava開発者がいます。私たちは、彼らが自分たちの持つスキルを使い続けて、デバイス上のモバイル開発にもそのスキルを使ってほしいと思っています。自分が知っている言語 (Java 8)、自分が知っているIDE (EclipseやJDveloper)、自分が知っているアーキテクチャや方法論 (MVC、POJO、コンポーネントベースのUI定義)を使うのです。
Javaに投資したIT専門店のために、私たちは、スキルギャップの橋渡しをして、デバイスのアプリを作成する時に、既存の開発リソースを活用できるようにします。
InfoQ: あなたのセッションから持ち帰ってほしい重要なことは何ですか?
Shmeltzer氏: もしあなたがJava開発者ならば、既に持っているスキルをすべて活用し、新しいモバイルデバイス開発の世界へ、途切れることなく移行できる解決策があります。
スタイルのあるGroovy
Guillaume Laforge氏、Ninjaの作者でRestlet提唱者、Restlet
InfoQ: あなたの最近の記事、ApacheにしてからGroovyのダウンロード数が2倍にという記事を見つけました。 これは、ほぼAndroidのおかげだと思いますか?
Laforge氏: 率直に言って、少しはそう思います。New York TimesのAndroidアプリのように、Apache Groovyで書き直されたAndroidアプリが成功したのを見ましたから。このことは、こちらのブログで説明しています。
http://open.blogs.nytimes.com/2014/08/18/getting-groovy-with-reactive-android/
間接的には、Googleは、Android開発者がAndroidアプリをビルドするために、Gradleのビルド自動化を使うことを選びました。GradleはDSLでGroovyを使っているので、自然にますます多くのモバイル開発者たちがGroovyをよく知るようになります。
しかし、もっと一般的に、Androidと並んで、Groovyを採用するための重要な原動力としてGradleを見ています。ますます多くの企業や大きなプロジェクトがGradleビルドに移行しています。
最後に大切なことをいいますが、GroovyがApache Software Foundationへ移行したことは、そのこと自体が原動力になっていると私は信じています。Apache Groovyがここに存在し続けて、長期間使われることを開発者たちが理解することで、すでに十分成熟し、開発者たちに十分信頼されています。
InfoQ: Groovyで生産性を上げる上位3つのヒントを教えてもらえますか?
Laforge氏: あぁ! それは難しいな。たった3つしか選べないなんて!
1) まず初めに、Javaのようにコードを書けます。GroovyはJavaの上位セットのようなものです。しかし、Groovyを学びながら、だんだんと新しいコツを学び、コードをより簡潔で、よく表現できた、信頼できるものにしていきます。
2) 2つめは、GDK (Groovy Development Kit) を学んでください。Apache Groovyは、沢山の素晴らしいAPIや、とても役に立つJDKのクラスを利用したメソッドを提供し、一度利用すればかなり生産性を上げられます。
3) 最後に重要なことをいいますが、型コントラクトの概念は重要です。どこでも「def」を使い、どんな変数、パラメタ、フィールドでも、すべて動的に型を決められますが、これはよいプラクティスではありません。API、自分で操作できること、に明確なコントラクトを定義することは重要です。そのため、変数、パラメタ、フィールドを宣言する時に、適当な型を使うべきです。そうすれば、Javaとの相互運用性の役に立ち (同じプロジェクトで両方の言語を混ぜ合わせる時に)、ドキュメント (JavaDoc/GroovyDocを考えてください) の役に立ち、コンパイラは、よりよいコードアシスト (ナビゲーション、コード補完、エラー候補等) をうれしく思うでしょう。
また、
@CompileStaticや@TypeCheckedアノテーションも活用できます。
InfoQ: あなたのセッションから持ち帰ってほしい重要なことは何ですか?
Laforge氏: それは、私のセッションに来る人によります。Groovyのベテラン開発者たちは、クールで新しいGroovyのコツを学んで、自分たちのプロジェクトでうまく使えるでしょう。Groovy初心者たちは、その強力な機能を発見するでしょう。生産性、コード可読性、強力さ、ドメイン特化言語等に関して、Groovyが提供する素晴らしいことすべてについて、疑い深い人たちは、自分たちの判断や考えを見直すかもしれません。
誰でも何かしら学ぶことかあると思います!
REST/WebSocketベースのマイクロサービスが盛んになる方法
Pavel Bucek氏、主席ソフトウェアエンジニア、Oracle
Michal Gajdos氏、ソフトウェアエンジニア、Sapho
InfoQ: caniuse.comによると、主要なブラウザすべてでWebSocketはサポートされています。開発者たちがウェブソケットを使わない理由はありますか?
Bucek氏:ブラウザ / クライアントサポートに関して、答えはノーです。すでにすべてそこにあり、どんなことでも簡単に使えます。要求された時に長いポーリングを使ってウェブソケット接続をエミュレートできるフレームワークさえあります。しかし、私はそれらが重要だとは思っていません。それが、ウェブソケットを利用する本当によい理由ではありません。
バックエンドインフラストラクチャの要求に関して、何か問題があるかもしれません。それは、「標準的な」アプリケーションと比べて、少し違うかもしれませんが、バックエンドがすでにhttpsや、もっと永続的な接続を提供する何か別のものをサポートしている場合、それは問題ではありません。
InfoQ: 「RESTは死んだ」と聞きました。そして、リアクティブAPIが次に来ます。この考え方に同意しますか?
Bucek氏: RESTが死んだなんて、馬鹿げています。RESTは、簡単で効果のある「RMI」プロトコルで使われます。私は、RESTを別のものにしようと考えたことさえありません。
「リアクティブAPIが次に来る」ことには、同意します。現在発展しているインフラストラクチャに関して、何かを非同期で、できれば2つ以上の「こと」をしたいでしょう。例えば、RESTクライアントの呼び出しは、そのようなことを組み合わせ、受け取った応答すべてに基づいて、1つの応答を作り出します。このようなことは、リアクティブAPIを使えば、かなり簡単に実行できます。ブロックされたり、余分なスレッドを使ったり、同期の問題について考えたりする必要はありません。
InfoQ: あなたのセッションから持ち帰ってほしい重要なことは何ですか?
Bucek氏:
- WebSocketとRESTは競争相手ではありません。お互いに補完するものです。
- 効果的な双方向のコミュニケーションが必要で、ブラウザ (または、スタンドアロンアプリ) で応答時間を遅らせる場合、WebSocketプロトコルを使うことを考えるべきです。
- WebSocketはHTTP/2に置き換わっていません。
InfoQは、私たちの質問に答えてくれたスピーカーたちに感謝する。JavaOne 2015には、ここで紹介されたものの他に、沢山のセッションがある。新しいJava言語の変更、現代のエンタープライズアプリケーション、リッチクライアントサイドの解決策、スマートデバイスをターゲットにしたIoT開発、そして、クラウドでのウェブサービス開発について、参加者たちは学べるだろう。
Javaキーノート、「接続された世界で加速するJava」は、2015年10月25日(日)1:45-4pm(PDT) に実施される。http://www.oracle.com/javaone/liveでライブのストリーミングを視聴できる。