この記事は、JavaとScalaの例外分析・パフォーマンス監視のツール Takapi の blog に投稿されたものです。

Javaのマイクロフレームワークとは何か、推奨される理由とは？

どんなプログラミング言語にも、長所と短所はあるものです。例えばJavaは、安全性の高さや、厳しいテストを経ていること、後方互換性などの利点を持つ言語です。しかし、その代償として、アジリティ（俊敏性）や合理性といった面が少なからず犠牲になっています。冗長で、Java自体が肥大化しているという事実も否定できません。とはいえ、新規開発や大規模な開発を行いたい場合、JVM（Java仮想マシン）はバックエンドとして非常に魅力的です。JVMはパワフルな上に、非常に厳しい環境でテストされています。このような利点があるため、結果的にJavaは広く使用され、積極的にデプロイされているのです。

しかし、このJavaの現状を皆が受け入れているわけではありません。中には、JVMの強みを維持しつつ、軽量化する努力を続ける人々もいます。その取り組みの第一波となったのが、Javaの軽量フレームワークです（こちらの記事でも少し紹介しています： Dropwizard vs. Springboot ）。軽量でモダンなJavaフレームワークが登場すると、開発時間は短くなりました。そして最近では、第二波がやってきています。その波こそが、Javaのマイクロフレームワークなのです。

Javaのマイクロフレームワークとは何か

プログラミング言語が成熟するにつれ、毎回のリリース時に避けられない問題があります。それは実績のあるライブラリが肥大化してしまうことです。ある時を過ぎると、そのようなライブラリに組み込まれた機能の大半は、ほとんどのプロジェクトで使われなくなってしまいます。この問題の解決に挑むのがマイクロフレームワークです。そのアイデアは、集中的で迅速なソリューションを生み出すことで、開発プロセスを必要最小限の内容に絞り込むというものです。

マイクロフレームワークは、本質的には軽量フレームワークの延長で、現時点で得られる最軽量のJava開発手法です。まだ登場して間もないため、あらゆる本番環境にデプロイされているわけではありませんが、アーリーアダプタたちの開発現場では、非常に良い結果を出しています。顕著なメリットを持つマイクロフレームワークは、今この分野で大きな盛り上がりを見せ、急成長しています。

ここで、人気の高いJavaのマイクロフレームワークとして、Ninja、Spark、Joddの3つのフレームワークを取り上げてみましょう。

Javaのマイクロフレームワークに関するGithubの統計データ

Ninjaフレームワーク

Ninja は、Webサービスやアプリケーション作成を目的とした、フルスタックのマイクロJavaフレームワークです。PlayやRuby on Railsのプラス面を、純粋なJavaフォーマットに移植することを目的としています。MVC（モデル・ビュー・コントローラ）の概念を採用して、簡潔かつ一貫した方法で、いかなるサイズのアプリケーションでも作成できるようにしています。

統合されたソフトウェアスタックであるNinjaには、追加設定なしで使える幅広い機能（JSON構文チェック、メトリクスのサポート、HTMLレンダリングなど）が備わっています。なお、機能を使うにはコントローラ用のアノテーションと定義が必要です。これらの機能の大半は、NinjaをDevOpsに適したフレームワークにするという目的に基づいています。つまり、Ninjaを使いやすくするために、この種のライブラリが含まれているのです。スケーラビリティ面については、Ninjaはステートレスであるため、単純にサーバを追加するだけで水平方向の拡張ができます。

機能的で使いやすいNinjaですが、その代償として、同分野の他ツールに比べてメモリ使用量が多く、ユーザの選択肢が少ないというデメリットがあります。Ninjaでは開発環境の構成選択、ソースフォルダ一式とファイルの作成は自動で行われます。

人気とライブラリ： この記事を書いている時点で、 Github 上ではNinjaに809のスターと288のフォークが付いています。Ninjaの人気はJoddと同等ですが、Sparkには遠く及びません。票を入れたい方はGithubのページに行ってみてください。Ninjaでは、HTMLレンダリングにはFreemakerを、JSONやXMLの処理にはJacksonを使用しています。また、Ninjaで書かれたコアライブラリは数多く存在します。

始め方： Ninjaの始め方はとても簡単です。NinjaはMavenをベースにしていて、実行にはJavaとMavenが必要です。NinjaプロジェクトはMavenアーキタイプをとおして動くため、いったんビルドしてしまえば、ユーザは新しいプロジェクトをシングルコマンドでビルドできます。最初のプロジェクトを作成するためのコマンドは、以下のとおりです。

mvn archetype:generate -DarchetypeGroupId=org.ninjaframework -DarchetypeArtifactId=ninja-servlet-archetype-simple

値を数個入力し、プロジェクトのディレクトリに移動したら、以下のコマンドを実行してください。”SuperDevMode”（変更を自動で取得するモード）でNinjaが起動します。

cd MY_INSTALLED_PROJECT
mvn clean install // to generate the compiled classes the first time
mvn ninja:run // to start Ninja's SuperDevMode

そこから、プロジェクトを最適なIDE（統合開発環境）にインポートし、コーディングを始めましょう。さらなる詳細は、 ドキュメント をチェックしてみてください。

まとめ： Ninjaフレームワークは、スケーラビリティやシンプルさを提供し、そして簡単に使えるようにJavaフレームワークを再設計したものです。ユーザが起動から実行までを素早く行えるような多くの機能を提供しています。フルスタックフレームワークとしては、他のものよりもメモリ使用量が大きくなり、カスタマイザビリティは小さくなります。

Spark

Apache Sparkと混同しないようにしましょう。ここで言っている Spark のゴールは、簡単かつシンプルにREST APIやWebアプリケーションを作成できる、純粋なJavaフレームワークを設計することでした。Sparkは、1MBより小さなサイズでアプリケーションを迅速かつ簡単に開発できるようにするための、速くてスリム化されたフレームワークです。当初Sinatraに触発され、活発なリリースサイクルを維持し続ける熱心な開発者コミュニティのおかげで、十分に作り込まれたWebフレームワークになりました。

マイクロフレームワークとして、Sparkではアプリケーション設計の際にユーザがテンプレートエンジンを選べるようになっています。ライブラリの選択が柔軟にできるため、選択肢のない固定されたシステム特有のロックインや学習曲線の問題を気にせず、プロジェクトに最適な選択肢を選ぶことが可能です。なお、メモリ使用量の小さいソリューションを提供するため、必要とされるコンフィギュレーションやボイラープレートは、ほとんどありません。

Sparkの柔軟さやシンプルさの代償は、同分野の他の選択肢に比べて機能性が低いことでしょう。Sparkはできるかぎり合理的かつ簡単であることを目指しているので、過度なアノテーションやXMLコンフィギュレーションのような余分な労力を要するようなものが省かれているのです。非常に軽量なフレームワークにするため、便利に使えそうな機能も犠牲にしています。

始め方： Sparkの始め方は、極めてシンプルです。実行にはJavaとMavenが必要です。まず最初にMavenの依存関係を設定しましょう。

<dependency>
  <groupId>com.sparkjava</groupId>
  <artifactId>spark-core</artifactId>
  <version>2.2</version>
</dependency>

次のステップは、Sparkをインポートし、コーディングをすることです。

import static spark.Spark.*;
public class HelloWorld {
    public static void main(String[] args) {
        get("/hello", (request, response) -> "Hello World!");
    }
}

さらなる詳細は、 ドキュメント をチェックしてみてください。

人気とライブラリ： これを書いている時点では、SparkはGithubで2,398個のスターを獲得しており、542回フォークされています。今回この記事で紹介している3つのフレームワークの中で最も人気です。あなたも票を入れたい場合はGithubのページに行ってみてください。柔軟性の一例として、Sparkではユーザが、特定のライブラリにロックされることがありません。例えば、HTMLレンダリングでは、Freemarker、Mustache、Velocity、Jade、Handlebars、Pebble、Waterなどを使うことができます。どれを使うにしても、Mavenの依存関係を設定しましょう。

まとめ： Sparkは、Javaにおける多くの余分な部分がそぎ落とされ、シンプルに設定でき、広範囲のJavaプロジェクトを作成する際に使える、最小限で柔軟性のあるWebフレームワークとなっています。しかし、スリム化したことで、機能性を失っている面もあるため、Sparkは大規模なWebアプリケーションにとっては理想的なフレームワークではありません。

Jodd

Jodd は、Javaのマイクロフレームワーク、ツール、ユーティリティのコレクションで、そういう意味では他のものと直接比較できないかもしれません。実際のところ、例えばSparkをJoddコンポーネントの一部と言うことだってできてしまいます。Joddのドライバは、メモリ使用量、それにJavaのツールやフレームワークにありがちな緩慢さを減少させ、超軽量級のフレームワークやツールの選択肢を提供することを目的にしています。一体的なアプリケーションというわけではないため、各ライブラリを個別に切り離すことができ、ユーザは必要に応じて使うものを選べるというわけです。

登場してからある程度の時間が経っており、その時々の要求に応じてツールやユーティリティが随時、軽量化されています。ツールやフレームワークを別々に維持し、ゆるいバンドル版として提供することで、個別の要素に集中的に取り組めるのです。含まれているフレームワークは、例えばリクエストの処理やHTML5の構文解析用のもの、それにDIコンテナなどが含まれています。このようなコレクションは、一見すると合理化されたマイクロフレームワークというコンセプトに相対するようですが、バンドル全体で1.5MB未満であり、メモリ使用量はわずかでしかありません。

Joddを使う上での代償は、特定の用途を対象にしていないということです。ほとんどの機能はライブラリコレクションとして提供されていますが、用途に合わせて、ある程度、自分で設定が必要になってきます。カスタマイズできるという点は、ユーザに多種多様な制御性や柔軟性を提供しますが、逆に使いやすさという点では足かせになるでしょう。幸い、各ツールはシンプルで小規模のため、コードをいじるにしても複雑で身動きが取れないということはないと思います。また、Joddのサイトにはガイドや参考になる実用例などもあるので、ぜひ参考にしてみてください。

始め方： JoddはGradleでビルドされており、Java 1.5以上を対象にしています。ツールのコレクションということもあり、他のツールに比べるとやや分かりにくい印象があるかもしれません。まずはバンドルごとダウンロードして、Joddの全てのモジュールを入手するのも手です。あるいはGitのソースからJoddをビルドしてもいいでしょう。以下がその方法です。
まずJoddのGitリポジトリをクローンします。

git clone https://github.com/oblac/jodd.git jodd

次に、以下のコマンドでプロジェクトをビルドします。

gradlew build

MavenにJoddをインストールすることもできます。使うのは以下のコマンドです。

gradlew install

その他のモジュールや使用例については、Joddの ドキュメント をチェックしてみてください。

人気とライブラリ： これを書いている時点では、Joddは Github で837個のスターを獲得しており、243回フォークされています。Ninjaとはいい勝負ですが、こちらもSparkには及びません。票を入れたい方はGithubのページに行ってみてください。Joddはユーティリティ、フレームワーク、およびツールのコレクションであるため、そのライブラリは独自のものです。

まとめ： Joddは、それぞれがある用途に特化された軽量のフレームワークやツールのコレクションです。ユーザはこれらのライブラリを自分の用途に応じて多様な形で組み合わせることができます。もちろん、機能性も十分です。一方で、各要素に分けて、自分好みの仕様にする責任は自分が背負うことになります。

結論

Javaのマイクロフレームワークは、Javaの強みを維持したまま、その弱点に対処するための試みです。機能を最小限に絞った手法は、非常に軽量なアプリケーションのデプロイを可能にし、開発者に対してJVMの力とより高速な新しい言語の俊敏性を組み合わせる手助けをします。

まだまだ新しい動きのため、何を持ってJavaマイクロフレームワークとするかというのは、意見の分かれるところだと思います。見方によっては、 JHipster 、 Javalite 、 Ratpack 、 Vert.x などもその仲間に入れて、試してみてもいいかもしれません。もし皆さんが以前にマイクロフレームワークを使ったことがあれば、コメント欄でぜひ意見をお聞かせください。

他のテーマにも興味がありますか？ 15 tools to use when deploying new code to production（新しいコードを本番環境にデプロイする時に使う15のツール） もぜひチェックを。

この記事は、JavaとScalaの例外分析・パフォーマンス監視のツール Takapi の blog に投稿されたものです。