「Java EE 8」の注目機能は何か? この先、Java EEはどう進化していくべきか? 寺田佳央氏と川島義隆氏に聞いた

Oracle Java & Developers編集部
2017-05-11 11:30:00
  • このエントリーをはてなブックマークに追加

Java EE 8はJava EE 7のマイナーアップデート版?

──Java EE 7を使っている開発者にとって便利な機能がいろいろと追加されるのですね。Java EE 7からはスムーズに移行できそうですか?

寺田:問題なく移行できると思います。恐らくコード・レベルでは何も変える必要はありませんし、パフォーマンスの問題を抱えている部分を改善するためにJAX-RSのクライアントに入れ替えるといったことが可能になります。サーバ/クライアント間で双方向通信は行わないけど、サーバから一方向でプッシュ配信をしたいためにWeb Socketを使っているような部分を、JAX-RSのServer-Sent Eventに置き換えるといったこともできるでしょう。また、Java Servlet 4.0でHTTP/2のSever Pushが追加される点も注目です。基本的に、Java EE 8は現在Java EE 7を使っている方にとってはマイナーアップデート版のようなものだと言えますね。

川島:Java EE 8はJava SE 8がベースになりますが、すでにJava EE 7を使っているプロジェクトに関しては、こちらのほうが注意が必要かもしれません。Java EE 8への移行に伴ってJava SEをバージョンアップした際、ライブラリの内部的な実装の変更に伴ってそれまで問題なく動いていたプログラムが意図どおりに動作しなくなることがありますからね。

──オラクルの修正提案にあった「Configuration」、「Health Checking」の導入は見送られるようですね※1

※1 オラクルがJavaOneで発表した修正提案の内容については、「『Java EEをクラウド時代のプラットフォームとして大きく発展させる』 Java EE 8の変更、Java EE 9を新たに提案──JavaOne 2016基調講演まとめ」を参照されたい。

寺田:Configurationはアプリケーションの設定を外出しにするための仕様、Health Checkingは接続先のサービスが動作しているかどうかを調べる機能などを規定する仕様であり、いずれもクラウド/マイクロサービス対応において必要なものです。今回、これらが落ちたのは残念ですが、まだ各仕様が十分に検討されておらず、Java EE 8のリリースを早めることを優先したため仕方がないですね。

Java EEに対する企業と開発者のスタンスの違い。開発者は進化のスピードを求めている

──こうしてJava EE 8のリリースが間近に迫ったわけですが、一方で国内の企業や開発者は現在、Java EEに対してどのようなスタンスなのかが気になるところです。川島さんはプリセールス活動でお客さんと接する機会が多いそうですが、それらの企業や開発者の皆さんはJava EEをどう見ているのでしょうか?

川島:企業と開発者とでは、使用するフレームワークに対する評価にちょっと温度差があると感じています。

 まず開発者の方々に聞くと、今勉強したいフレームワークはSpringだという方が多いですね。一方、お客さんに関しては、私がお会いするのはStruts 1からの移行先を検討しているというケースが多いのですが、その候補としてJava EEとSpringが半々という印象です。

──開発者がSpringに引かれる理由は何でしょうか?

川島:やはり進化のスピードの速さです。開発者にとっては新しいものがドンドン出てくるのが楽しくて、今はその点でSpringがJava EEに勝っているのでしょう。

──まだStruts 1を使っている企業は多いのですか?

川島:結構いらっしゃいます。私はStruts 1からの移行に関しては“ゆっくり進めよう派”ですね(笑) Struts 1程度の薄いフレームワークならば自社でメンテナンスできるでしょうし、今のシステムの機能をガラッと変える必要がないのなら、その必要が来る時まで今のシステムを延命しておけばよいと思っています。同じStrutsだからと慌ててStruts 2に載せ替えたことで、かえって脆弱性の問題に悩まされることになったというケースもお聞きします。

──慌てて選択を間違えるよりは、適切な時期が来るまで塩漬けにしておこうというわけですね。

川島:もちろん、セキュリティ脆弱性はつぶしておかないといけないので、私のGitHubでは“struts1-forever”と銘打って各バージョンの脆弱性を対策したものを公開しています。延命派の皆さんはぜひご活用ください(笑)

海外の開発者は、今Java EEでやれることからマイクロサービス化に取り組んでいる

──寺田さんは海外の企業や開発者の状況をよくご存じですが、国内と海外とで大きな違いがあれば教えてください。

寺田:海外もJava EEかSpringかという状況は同じで、やはり今はSpringに勢いがあると感じます。「Spring Boot」を使えば簡単にマイクロサービスが作れますし。ただ、国内と違うなと思うところは、マイクロサービスを作るのにSpring Bootを使わないとダメだと思っていない方も多いんですね。現状のJava EEの中でもマイクロサービス化できる部分があるし、これまでにJava EEで培ったノウハウも生かして、まずはそこからやっていこうという方が沢山いらっしゃいます。

──日本では何かが流行ると、皆が一気にそれに乗っかる傾向が強いという指摘がよく聞かれます。

寺田:成功事例に倣おうということでしょう。ただし、他の会社でうまくいったから、自分も全く同じようにやれば成功するとは限らないので、そこは気をつけないといけません。たとえ同じものを使わなくても、成功事例がなぜうまくいったのか、自分が培ったノウハウや保有する資産/技術で同じことをするにはどうやればよいかときちんと評価/検討して取り組めばよいのです。自分の強みを生かした取り組み方をすることで、全く同じようにやるよりも大きな成功をつかめる可能性もあります。海外には、そのような開発者が多いと感じています。

一刻も早くクラウド/マイクロサービス対応を! スモール・パッケージ化も必須

──話題を“Java EEの今後”に移しましょう。次のバージョンのJava EE 9、さらにその先のバージョンでJava EEが実現すべきこと、お二人が望まれていることをお聞かせください。

寺田:まず、できるだけ早くクラウド/マイクロサービスに対応してほしいですね。今日、システム開発の世界的なトレンドとして「いかに早くサービスをリリースして改善していくか」、「いかに安全性を高めるか」ということに関心が集まっています。そうした中でJava EEが今後も重要なテクノロジーであり続けるために、そしてJava EEで作られたシステムやサービスの価値を高め続けていくためにも、クラウド/マイクロサービスに早急に対応してほしいと思います。

 また、これはおそらくJava EE 9で検討されていることだと思いますが、Java SE 9のJigsawを採用した軽量なJava EEの実行環境を早く実現してほしいですね。今はJDKをインストールする場合でも、AWTなど滅多に使わない古いライブラリまで全て入れなければなりません。これが自分のアプリケーションを動かすのに必要最小限のパッケージやライブラリだけを入れられるようになれば、もっと小さいスモールセットのJavaを実現できるようになり、起動時間の短縮やメモリ使用量の削減も実現できるでしょう。今後はそういったことがますます重要になると思います。

川島:私は、もう“Java EE x”といった大きな単位でのリリースにはあまり期待していなくて、個別のパッケージが進化していってくれればそれでよいと思っています。全てを揃えて出そうとするから余計なオーバーヘッドがかかっているような印象もありますし…。それによって個々のパッケージのリリース・スピードが早まってくれると嬉しいです。

──大きいリリースとしてまとめようとしているから遅くなっているという面はありそうですね。

川島:例えば、Java EE 8にもJava EE 9にも、今のところ「JCache」が入るという話はありませんよね。私は個人で「Enkan」というフレームワークも作っているのですが、これはマイクロサービス向けに特に起動スピードを重視したもので、3秒以内に立ち上げることを目指しています。このEnkanでサービスを作る場合、セッション・ストレージとしてKVSも使えるように設計していますが、クラウド上の本番環境ではDynamoDBなどを使うとして、ローカルで開発する際には別のプロダクトを使う必要があります。ただし、その際にキャッシュのインタフェースを変えたくないので、Java EEの標準のキャッシュAPIが欲しいんですね。現時点でJCacheがJava EEに入っていないのは残念ですが、別に「Java EEのグループの1つだと」と言ってくれるだけでも十分な気がするのですが…

寺田:今、「3秒で起動して…」とおっしゃいましたが、マイクロサービスとともに注目されている「サーバレス・アーキテクチャ」を実現するためにも、スモール・パッケージが必要です。サーバレス・アーキテクチャのJavaって、今はちょっと重たいんですよね。起動が遅いため、他の言語のほうが使いやすかったりするのですが、それでもJavaで作りたいというニーズは非常に多いと思います。なので、3秒どころか、それこそ1秒で即座に起動できる仕組みが欲しいところです。

クラウド環境に適した開発容易性の実現も

川島:クラウド環境に適した“開発容易性(Ease of Development)”も実現してほしいですね。と言うのも、クラウド時代になっても、全ての開発作業をクラウド上でやれないケースは依然として残ると思います。そのときに問題となるのが開発環境です。本番環境がオンプレミスの場合、それとほぼ同じ開発環境をローカルに作れますが、クラウドの本番環境と同じ環境をローカルに作るのは難しいことがあるので、疑似的な環境を用意しなければなりません。それを考慮した標準が欲しいですね。

寺田:同感です。先ほどのJCacheの話とも重なりますが、今はNoSQLのプロダクトが沢山あり、プロダクトごとにAPIが異なります。そのため、あるプロダクトを大々的に使い始めたら他のプロダクトに移るのは難しいですし、用途に応じて使い分けようとしても、プロダクトごとに異なるAPIを1人の開発者が全て覚えて使いこなすのは大変でしょう。Java Persistence APIのようにプロダクトの違いを隠蔽してくれるような仕組みが必要です。

川島:システム・インテグレーターにとって、クラウド・ネイティブのことだけを考えた仕組みは使いづらいんですよ。開発の現場では閉鎖された環境での作業が求められる場合もあり、クラウド上で開発作業が行えなかったりします。そうしたときでも、インタフェースさえ合っていれば問題のないことが保証された仕組みがあると助かります。

──クラウドとローカルを透過的に扱える仕組みも必要だということですね。

川島:あともう1つ、「いつ出すのか」を明確に宣言して欲しいですね。もし間に合わなければ代替手段はほかにあるので、それを使えばよいのですが、ちゃんとした標準が作られるのなら、やはりそれに合わせたいです。なので、それがいつ出るのかをはっきりさせてほしいです。それと、導入を予定していた仕様がいきなり落ちたりっていうことがないようにしてもらえると有り難いですね(笑)

──いろいろなフレームワークをJava EEベースで作っている川島さんとしては切実な要望ですね(笑) Java EEへの期待をいろいろとお聞かせいただきましたが、最後にお知らせを1つ。今年も5月17日に「Java Day Tokyo」が開催されます。読者の皆さんには、Java EE 8のリリースに備えて最新情報を入手する場として、ぜひこのイベントにぜひご参加いただきたいですね。

寺田:今回も米国オラクルからJavaの仕様策定を主導するキーマンが多数来日するようです。Java EE 8やJava EE 9をはじめ、Javaの現在と将来についての最新情報や構想を直接聞けるよい機会ですね。

──お二人もセッションを持たれますよね。

寺田:私はマイクロサービスに関心をお持ちのJava EE開発者の皆さんを対象に、今使えるテクノロジーを利用してJava EEで作れるマイクロサービスを、デモを交えてご紹介する予定です。

川島:私もマイクロサービス関連のセッションなのですが、今、Javaで作ったサービスを更改したりする際、旧バージョンから新バージョンへとサービスを止めずに無停止デプロイする仕組みを作ったりしていて、これをデモも交えてご紹介したいと考えています。

──どちらも面白そうなセッションですね。それでは、読者の皆さんとはJava Day Tokyoでお会いしましょう! お二人とも、本日はありがとうございました。

【5月17日に「Java Day Tokyo 2017」が開催!】

恒例のJava Day Tokyoが今年は5月17日に開催されます。例年、各セッションは早期に満席となりますので、参加を希望される方は下記リンク先よりお早めにお申し込みください。

  • イベント名:Java Day Tokyo 2017
  • 開催日:2017年5月17日(水)9:30〜20:00 (受付開始 9:00〜)
  • 会場:グランドプリンスホテル新高輪 国際館パミール(品川)
  • 参加費:無料
  • 詳細/参加申込み:こちらのWebサイトをご覧ください
このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]