楽天のアーキテクトが説く、J2EEからJava EEへの移行を“今すぐ"始めるべき理由

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

「もうJ2EEは捨て、新世代のJava EEに移りましょう」──Java Day Tokyo 2014のセッションにおいて、楽天のアーキテクト、岩崎浩文氏はこう呼びかけた。前提とする技術や環境が、J2EEの時代と現在とでは様変わりしているのだ。

J2EEと新世代のJava EEとでは、「技術や環境の前提がまったく異なる」

楽天 DU Financial Service Department  Group Managerの岩崎浩文氏
楽天 DU Financial Service Department Group Managerの岩崎浩文氏

 バージョン5以降、開発コンセプトを大きく転換したJava EE。世界的には、この新世代のJava EEがエンタープライズJava開発のメインストリームを成している。だが国内を見渡してみると、まだ多くの企業システムが旧世代のJava EE(J2EE)で稼働している。日本オラクルが2014年5月に開催した「Java Day Tokyo 2014」では、旧来のJ2EEを使い続ける企業や開発者に対して、その弊害と最新のJava EEへの移行メリットを説明するセッションが実施された。講師を務めたのは、楽天でアーキテクトとして活躍する岩崎浩文氏(DU Financial Service Department Group Manager)である。

 岩崎氏はこれまで15年間以上にわたり、さまざまな業種の大規模Java EEシステムの企画/開発に携わってきた。その経験から、特にバージョン6以降のJava EEは、それ以前のJava EEとは別物と言ってよいほど大きく変わっていると説く。「J2EE 1.4など旧式の技術を使っている企業は、早急に最新のJava EEをキャッチアップし、移行すべき」というのが岩崎氏の主張だ。その理由を説明するにあたり、岩崎氏はまずJava EEとエンタープライズITを取り巻く技術の変遷を振り返った。

 1999年にJ2EE 1.2がリリースされて以降、2003年にJ2EE 1.4が登場するまでの期間は、エンタープライズJavaの「爆発的な普及期」であった。BEAシステムズ(現オラクル)のWebLogic Serverといった商用製品をはじめ、オープンソースのJBoss、Apache StrutsやSpring Frameworkなど、アプリケーション・サーバや開発フレームワークが数多く登場し、広く普及した時代だ。

 この時代は複数のサードパーティ製Javaフレームワークが独自の実装でユーザーの支持を集めた。標準仕様としてのJ2EEに開発生産性などの面で課題を感じる開発者が多かったことが主な理由だ。結果的に、これが独自フレームワークの乱立を招き、システムの複雑化や保守の難易度を高めることにつながる。

 この問題を重く見たJavaコミュニティは、2006年にリリースしたJava EE 5から、その方向性を一気に転換。重厚長大化が進んでいた機能セットの見直し、開発生産性の向上、Webアプリケーション開発に適した開発パラダイムの導入などを通じ、標準仕様としての質を高めるべく改良が進む。この流れは2009年リリースのJava EE 6、2013年にリリースされたJava EE 7でさらに押し進められ、洗練化が進んだ。

 岩崎氏は、J2EE 1.2が登場した当初と現在のテクノロジー環境の違いについて、「iモード初代機」から「スマートフォン」へと移り変わった携帯電話や、ISDN(INSネット64)からWi-Fiスポットが街中に設置されるようになった公衆ネットワークなどを例に挙げ、「15年前と現在とでは、前提とすべきテクノロジーや情報環境がまったく異なる」と説明する。

 「ベテラン開発者の中には、Java EEに対して、いまだに"イケてない"というイメージをお持ちの方がいらっしゃるかもしれません。恐らく、そうした方の多くはJ2EE 1.4の印象を引きずっているのでしょう。J2EE 1.4と比べると、Java EE 6やJava EE 7といった新世代のJava EEは大きく変わり、"使える"ものに仕上がっています。もうそろそろ、Java EEに対する見方を変える必要があります」(岩崎氏)

 岩崎氏は、エンタープライズJavaに取り組んできた多くの企業の現状を、「2001年から2006年辺りに作られたシステムが、そのままになっているケースが多いのではないか」と推察する。この時代のシステムは、J2EE 1.3や同1.4をベースに多くのオープンソース・フレームワークを組み合わせて作られ、オープンソースのアプリケーション・サーバ上で稼働している。それらのフレームワークの大半は開発が終了(EOL:End Of Life)しており、セキュリティ上の問題だけでなく、今後の新規開発や機能改良などでも課題を抱えている。

 この状況を、岩崎氏は"悲劇"だと評する。そこから脱するには、新世代のJava EEに移行するしかない。その作業に取り掛かるのは、「今からでも遅くはない」(岩崎氏)というのだ。

Java EE 7なら、システムの全レイヤを標準技術で構築できる

 岩崎氏によれば、新世代のJava EEでアプリケーションを開発するメリットの1つは、実行環境となるアプリケーション・サーバを、商用/非商用を問わず自由に選べる点である。例えば、あるアプリケーション・サーバの開発が終了したとしても、別の商用製品やオープンソース・プロダクトに移行することができる。こうした「ポータビリティの保証」は、「.NET環境にはない、Java EEの最大の利点」だと岩崎氏は評価する。

 また、岩崎氏はかつてのJ2EEと、新世代のJava EEを使ってエンタープライズ・システムを構築する際に使う要素技術の違いについても説明した。J2EEベースのシステムでは、リッチ・クライアントやビジネス・ロジック、データ・アクセスなどの機能を作り込む際、オープンソースや商用などのサードパーティ・フレームワークが使われることが多かった。とりわけJ2EE 1.4の時代はこのスタイルが定着し、Webプレゼンテーション層に「Struts」、ビジネス・ロジック層に「Spring Framework」、データ・アクセス層に「Hibernate」などを使ったシステムが多く構築される。岩崎氏が"悲劇"だと評するのは、ここで進化が止まってしまったシステムにほかならない。

 「現在も使われているシステムは、この時代に作られたものが多いはずです。つまり、日本企業のシステムの多くは、2000年代半ばで進化が止まってしまっているということです」(岩崎氏)

 岩崎氏は、一刻も早くこれらのシステムを新世代のJava EEに移行すべきだと訴える。Java EE 6やJava EE 7であれば、サードパーティ・フレームワークを使わなくても、すべてのレイヤを標準技術だけで作ることができる。ビジネス・ロジック層のEJB 3、プレゼンテーション層のJSF 2、Java FXなど、今日のエンタープライズ・システム開発で十分に使える技術に進化しているのだ。

 また、Java開発環境を巡る状況も大きく様変わりした。かつては「Eclipse」が事実上の標準ツールとして人気を博したが、現在では「NetBeans」(最新バージョンは8.0)やジェットブレインズの「IntelliJ IDEA」(最新バージョンは13.1)を使う開発者が世界的に増加している。

 「まだEclipseを使っている方は多いでしょうが、現在は開発が停滞気味で、NetBeansやIntelliJに流れが移りつつあります。古い開発環境を使っていると、開発者の進化もそこで止まってしまいます。最新技術をキャッチアップするのなら、開発環境もそれに対応したものに変えていくべきでしょう」(岩崎氏)

 さらに岩崎氏は、すでにEOLを迎えたStruts 1のゼロデイ脆弱性への攻撃が続いていることや、Windows XPおよびWindows Sever 2008のサポート・サイクルが終了することなどに触れ、過去の技術にとどまり続けることはセキュリティやITガバナンス上の大きなリスクになると指摘。「リスクが顕在化する前に対処すべき」だと呼びかけた。