Google App Engineが当初使っていたウェブサーバ/サーブレットコンテナはApache Tomcatだった。しかし最終的にJettyへと変更された。開発コミュニティではこの決定により、なぜ変えたのか、Tomcatでなにか問題があったのか、と多くの人が問いを投げかけた。InfoQはJettyの開発元企業であるWebtideのチームにインタビューをする機会を得て、今回の決定の事情について詳細を聞いた。
InfoQ：GoogleがTomcatや他の選択肢でなくJettyをApp Engineに選んだのはなぜでしょうか。
GoogleがJettyを選んだ理由と思われる特質はサイズと柔軟性です。クラウドではサイズが重要です。Jettyのインスタンスを（Googleがしているように）数万動かすとすると、各サーバが1MB小さければ全体で数十GBのメモリを節約すること（あるいは他のアプリケーションに多くのメモリをまわすこと）ができます。
またJettyはプラガブルで拡張可能なように設計されていて、Googleが高度にカスタマイズすることが可能でした。Googleはこれまで独自のHTTPコネクタや認証やセッションクラスタリングをプラグインしてきました。おもしろいことに、このようなクラウドに適した特質は、電話機やセットトップボックス（テレビにつなぐ機器）のような小さなデバイスに組み込むのにも非常に適しています。
InfoQ：JettyがJavaの高性能サーブレットコンテナとなっている理由はなんでしょうか。
わたしたちがJettyを開発する際には、Jettyを（たとえ実際はそうであっても）フルアプリケーションサーバにしようとは考えません。各機能はプラガブルであるように設計され、そのためもし不要になった時にはメモリに読まれることもリクエスト処理の呼び出しチェインに含まれることもありません。もしセッションが不要であれば、セッションハンドラを除いてセッションクッキーを探すサイクルの無駄をなくすことができます。1秒間に何千ものリクエストを処理する時には些細な参照でもコストがかかるものになってしまいます。
また、わたしたちは設計によるコードの最適化を軽視せず、誰かがJava VMの最適化やガベージコレクションが今こうなっていると教えてくれてもそれを鵜呑みにはしません。それは正しいかもしれませんが、注意深く書かれたコードの方がより最適化されていることもありますし、そのようなコードの方が一番オブジェクトの生成を節約できます。たとえば、Jettyでは並列処理をおこなっていますが、標準の並列データ構造はあまり使っていません。それらはオブジェクトを生成しすぎます。例としては、並列LinkedListを使うかわりに並列ロックの循環配列を対で使うことで、オブジェクト生成なしでもノンブロッキングの並列性が利用できています。
InfoQ：Jettyがディベロッパにとって便利なサーバである理由（テストなど）はなんでしょうか。
JettyはGWT、scala/lift、Grails、JRubyなど多くのフレームワークですでに採用されています。これらの技術を使う時はJettyを意識しないで利用できます。Jetty-Mavenプラグインという素晴らしいツールがありますが、これはコンポーネントをwarファイルにしなくてもウェブアプリケーションを実行できるようにしてくれます。ソースファイルを直接編集してテストすることが、warファイルのビルドなしでできるのです。またJettyに備わっている機能により、IDEやデバッガやプロファイラが直接実行できるメインのコードを書く作業も軽減されます。
InfoQ：Jettyのクライアント-サーバリクエストの処理で、ユニークな点はありますか？
今のJettyは第2世代の非同期型サーバです。リクエストを非同期に処理できるようになって2年たちましたが、これはコアアーキテクチャの一部となっています。他のコンテナも非同期サーブレットのサポートを付け加えようとしていますが、それが思っていたほど簡単、あるいはシンプルなものでないことにも気付き出しているのでないでしょうか。Jettyの非同期HTTPエンジンは非同期HTTPクライアントでも再利用できるので、スケーラブルにリクエストを生成したりレスポンスを処理することができます。
またさっきお話したように、リクエスト処理も拡張可能でプラガブルな処理機構をベースにしているので、ウェブアプリケーションの持つ各機能を外したり利用したり拡張したりすることができます。
InfoQ：Jettyが使われている大規模あるいは小規模な例は他にありますか？
ZimbraやYahooでは何百万、何千万のユーザに提供しているウェブメールにJettyが使われています。何百万ものディベロッパのデスクトップで動くEcipse IDEにもJettyが組み込まれています。1000ノードからなるクラスタ上で稼働し、1テラバイトのデータをソートする記録では世界一を保持しているhadoop map/reduceクラスタでもJettyが使われています。J2MEと接続したりネイティブにクロスコンパイルされたJettyもあるため携帯電話、企業内ルータ、Java Cardで動かすこともできます。Jettyを活用したプロジェクト例はhttp://docs.codehaus.org/display/JETTY/Jetty+Poweredをご覧下さい。
InfoQ：Jettyの今後あるいはロードマップはどういった感じでしょうか。
ロードマップの直近ではJetty 7.0.0がリリースされます。これはEclipse Foundationへの移転を完了するためのものです。Jetty 7ではServlet 3.0の多くの機能をサポートするようになりますが、Java 6の新しいAPIは使わないのでJava 6が必要になることはありません。Jetty 7の後にはJetty 8をリリースしますが、この系統でServlet 3.0とJava 6に準拠するようになります。Jettyはイノベーションを続けますし、Web 2.0の世界で現れる他のイノベーションも追っていきます。今おこなっているFirefox 3.5のクロスドメインAjaxへの対応ではcometdが使われます。また直にWebSocketやBWTP（Bidirectional Web Transfer Protocol）へも対応するようにします。Google Waveやそれに関連するプロトコルに対応することも検討事項で高い順位にあります。
InfoQ：GoogleとJettyに関して他に計画はありますか？
Googleは自分たちの計画を完全に仕舞いこんでいるので、わたしたちにはまったく判りません。App EngineのディベロッパたちとJavaOneで少し話したことはあります。わたしたちは彼らからのどんなフィードバックにもオープンで、Jettyの組み込みや拡張について改善する方法を受け入れています。
続いておこなわれた話の中で、SpringSourceがJettyでなくTomcatを選択するのに決めたことについて聞いてみた。
InfoQ：SpringSourceがGrailsのデフォルトコンテナをJettyからTomcatに変更しようとしていることについて何かお考えですか。
原因として考えたのは、問題があった時にGrailsの主要ディベロッパたちがTomcatoの内部ディベロッパたちからより”サービス”を受けられると考えたから、ということです。今回のことはSpringSourceがサポートサービスをユーザに売れるプラットフォームへGrailsを向かわせようとしているだけではないか、そう勘ぐっています。同じようなことが何年か前、JBossがJettyからTomcatへ変更した時にありました。その時JBossはTomcatディベロッパたちを雇い、Mort Bay（Jettyのコンサルティングをおこなっている企業）との商業協定を終了させました。このような商業協定が技術的な決定より影響を与えることは嘆かわしいことですが、インフラとなるプロジェクト群がアプリケーションサーバを中心としたグループへと集約されつつある時期なのだと思います。
GrailsはJettyとTomcat、両方との連携をサポートし続けますが、Tomcatをホストするモードがデフォルトの設定になることでしょう。
この結論、特にSpringSourceがTomcatを利用し関係を深めることについては的を射たものに思える。