Struts後時代のJava EE／Javaモダン開発はどうあるべきか〜JJUG CCC 2014 Springまとめリポート（前編）

Java EEにおいてJava 8はどこまで利用できるのか、Java開発でGit、CI、継続的デリバリは、どこまで有効なのか、Struts後時代のJava EE開発における有効なフレームワークなどをお伝えする。

[山本裕介，株式会社サムライズム]

　日本Javaユーザーグループは2014年5月18日、「JJUG Cross Community Conference 2014 Spring」を開催した。「JJUG Cross Community Conference」（以下、JJUG CCC）は毎年春と秋に開催されるカンファレンス。初心者向けからエキスパート向けまで、Java／JVMに少しでも関連すればいいという広いテーマでさまざまな講演が行われている。

　今年は4トラック同時進行、合計25ものセッション、ハンズオンセミナーという規模で大いににぎわった。

会場はベルサール西新宿。多くのセッションで立ち見が出るほどのにぎわい

Java EEにおいてJava 8はどこまで利用できるのか

　楽天 DU金融サービス部 岩崎浩文氏はJava EEにおけるJava 8の利用について「Java 8 for Java EE 7/6」と題して講演。Java EEのおさらいから始まり、Java EEが、長く続いた.NET FrameworkやSpring Frameworkとの競争・低迷期を脱却し、再度エンタープライズでは主流に返り咲いていることを説明した。

楽天 DU金融サービス部 岩崎浩文氏

　そして最新仕様であるJava EE 7に準拠しているのは2014年5月現在「GlassFish」「WildFly」のみで、主流は多種多様なアプリケーションサーバーが対応しているJava EE 6とのことだ（楽天はGlassFishを活用していることでも有名）。

　エンタープライズ分野でJava SE 8を使うことにより得られる優位点として、岩崎氏は以下の可能性を挙げた。

• Date and Time API（JSR-310）で和暦が容易に扱える
• Type Annotation（@NotNullなど）の活用によるnullチェックコードの排除、コードの簡略化
• Lambda記法によるコードの簡素化、可読性の向上
• Parallel Streamの利用によるビジネスロジックのパフォーマンス向上

　しかしながらJava EE 7仕様策定時点でJava SE 8はリリースされていなかったことから制約がある可能性もあり、実際に検証した結果を発表した。

• Lambda記法：まず問題なく使える
• Date and Time API：ビジネスロジック内での利用は問題ないが、既存フレームワーク、ライブラリ、JDBC APIなどで対応していない箇所では旧API（java.util.Dateなど）との相互変換が必要になるケースが出てくる
• Stream API：Parallel Streamの利用はアプリケーションによるスレッドの使用を禁止しているEJBの仕様と衝突するため、動作するかどうかはアプリケーションサーバーに依存

　岩崎氏は「プロダクション環境でJava SE 8を使うにはJava EE 8の登場を待つのが一番安全」としながらも、Java SE 8の対応が始まっているGlassFish 4.0.1のDaily buildの検証を行い、NetBeans 8による認識や起動、EJBのビジネスロジックにおけるLambda／Stream APIの利用に成功したという。

　ただし、Java EE 6対応のWebLogic Server 12.1.2でFork/Joinフレームワーク（Parallel Streamの内部で利用されている）を使ったところ例外が発生すること確認。POJOとして動作させた場合は問題なく動作するとのこと。また岩崎氏は「EJB 3.2の仕様ではユーザー管理スレッドは許されていないので、Fork/Joinフレームワークや、それを利用するParallel Streamを利用してよいかはグレーンゾーンだ」とした。

　結論として、岩崎氏は「制約事項はあるもののJava SE 8の新機能の恩恵を受けられる場面は多くあるためJava EE 6／7のアプリケーションサーバーでもJava SE 8がサポートされ次第積極的に使っていきたい」として、講演を締めくくった。

Java開発でGit、CI、継続的デリバリは、どこまで有効なのか

　ミッションクリティカルな現場で活用されるJavaは、その裏返しとして開発環境や開発・運用ワークフローが保守的なことが多い。アトラシアンのエバンジェリスト、長沢智治氏は「Java開発で活かしてほしいGit、CI、そして継続的デリバリー」というテーマで講演し、モダンな開発現場で活用されている開発環境、ワークフローをJavaの開発現場で生かしてほしいと説いた。

　いわゆる「SIer」ではソースコードの管理にはSubversion（またはCVSや共有フォルダー）を使い、テストはテスト仕様書に基づいて手動で行い、リリースは綿密に記載された手順書に基づいて人間が張り付いて行うという現場もまだまだあるのではないだろうか。

　アトラシアンといえば商用課題管理ツールとしてはほぼデファクトスタンダードの地位を確立している「JIRA」やエンタープライズ向けWikiである「Confluence」で有名だが、他にもチーム開発を効率化するツールをそろえている。

チーム開発をあらゆる側面でサポートするアトラシアンの製品群

　長沢氏はアトラシアンの製品群を活用することで、モダンな開発現場では常識となっているGit、CI（継続的インテグレーション）、そして継続的デリバリが容易に実現できることを、デモをふんだんに交えて解説した。常用しているエンジニアにすらやや難しいGitだが、同社のリポジトリ管理ツールである「Stash」を中心としてコマンドラインを一切使うことなくブランチの作成、プルリクエスト、マージなどを行う様子は圧巻だった。

　またユーザーフレンドリなUIを備えたCIツールである「Bamboo」や、チャットツールである「HipChat」など、洗練、統合された製品群を使ってチーム開発をする魅力を説いた。

　「うまくいくことが証明されている」モダンな開発スタイルを取り入れればメリットがあるのは誰にも自明だが、一方で開発スタイルの変更には大きな教育コストが伴う。またOSSを中心とした開発環境の整備、運用ができる人員をそもそも確保できないという企業は多いだろう。アトラシアンの製品によって低い導入コストで開発フローを一気にモダンな形へ変貌させることは一考の価値があると感じた。

Struts後時代のJava EE開発における有効なフレームワークとは

　シンプレクス社の文字拓郎氏はJavaベースで金融機関向けのシステム開発を行っているエンジニアだ。業務上調査したことを「最近のJava Web開発」としてgistにメモを公開したところ大きな反響があり、JJUG CCCで講演するに至ったという。ここでは、文字氏の講演「Modern Java Web / SPA Development」から概要だけ紹介しよう。

　Javaを使ったWeb開発といえば、Servlet／JSPやJSF、Struts、Springなどを使うのが定番だが、どれも決してモダンなアーキテクチャではなく、近年目覚ましい進化を遂げているクライアント側のWeb技術とのギャップは激しい。

　そこでシンプレクス社においてサーバーサイドはJavaのアプリケーションサーバーを利用し、モダンなSPA（Single Page Application：AjaxやWebSocketを活用して画面遷移しないダイナミックなWebアプリケーション）を開発をするための技術調査を行ったという。文字氏はJavaの開発経験は豊富であるものの、Web回りは定番技術であるServletもjQueryも触ったことがない状態からの手探りのスタートだったそうだ。

　SPAといっても分解すればHTMLとJavaScriptで構成されているWebアプリケーションなので、どのような技術をもってしても実装は可能だ。しかし文字氏は導入のしやすさ、開発生産性、ライブラリ／フレームワークの将来性などを総合して、金融系アプリケーションエンジニアとしてのバランス感覚を発揮して選定した組み合わせを惜しみなく紹介した。

　詳しくは講演資料も参照してほしいが、文字氏が最終的に選択した主なフレームワーク、ライブラリは以下の通りだ。

サーバーサイド

• ビルドフレームワーク：Gradle
• DIコンテナー：Guice
• JAX-RS：Jersey
• ORM：Hibernate
• JSONのハンドル：Jackson
• 開発用サーバー：Jetty（運用はWebLogic Server）

　有名なフレームワークが並ぶが、中でも印象的なのはJAX-RSコンテナーである「Jersey」だろう。Webアプリケーションフレームワークとしては近年PlayフレームワークやSpring MVCなどが人気だが、多くのことを担ってくれる半面複雑さが増すため、RESTサーバーのフレームワークとしても利用でき比較的シンプルなJerseyを採用したという。文字氏は「SPAを開発する際、サーバーサイドはREST APIのサーバーとなるため、無理に複雑なアプリケーションフレームワークを使う必要はないと判断した」と述べていた。

クライアントサイド

• CSS記述：SCSS
• JavaScript記述：CoffeeScript
• MVC：Backbone.js
• テンプレートエンジン：Handlebars
• 依存管理：Bower
• タスクランナー：Grunt

　SPAのフレームワークとして最近人気を集めているAngularJSを使っていないのが意外だが、AngularJSは複雑で学習コストやデバッグコストが高いため「薄い」フレームワークであるBackbone.jsを採用したとのことだ。

ユーザーエクスペリエンスの大きな向上は見られるが、業務アプリでのSPAのUI設計はまだまだ模索の必要がある

　SPAのフレームワークは総じて成熟しておらず、UIの定石も確立されていない状態であり、「あくまで“2013年夏〜秋ごろに選定した際の落としどころ”をまとめてみたものだ」と文字氏は言うが、資料はコード例に加え各フレームワーク、ライブラリの得手不得手までふんだんにまとめられており実践的だ。SPAに限らずJavaでWebアプリケーションを開発する上で当面多くの場面で参考になるのではないだろうか。

後編は、トラブルシューティングやJVM回り

　後編ではトラブルシューティングやJVM回りのセッションについてレポートするので期待してほしい。

著者プロフィール

山本裕介

Twitter APIのJava向けライブラリ「Twitter4J」やトラブルシューティングツール「侍」などを開発するオープンソースソフトウェアデベロッパ。

株式会社サムライズム代表。

Twitterアカウント：@yusuke