第一の点: 標準

JSP で宣伝されている利点の一つは、「標準」であるということです、 そして相当な数の人々がそれを重視していますが、 そうするあまり、「標準」でない技術はどれも拒否してしまいます。 この利点に関して、真実を追求するとわかることですが、 用語に正確にしたがえば (これが重要です)、 JSP は、「Sun標準仕様」であり、厳密には「標準」ではないのです。 このことは重要です。なぜなら、JSP が実は Microsoft の ASP や PHP Group の PHP と同様、「標準」でないからです。言い換えれば、 あなたがたまたま使っているツールはどれでも「標準」になるかもしれません。 JSP を定義しているのは、Java Community Process (JCP) 内の小さなグループです。 実際問題として、JCP に加わるにはかなり高い障壁があります。 なぜなら、NDA (機密保持契約) にサインをした上で、 プロジェクトリードによる加入の承認を受けなければならず、 場合によっては料金を払わなければならないのです。 極論すれば、JSP 仕様は実は Sun が所有する製品であるということになります。 ここで重要なこととして、この文書の元の作者 (Jon Stevens) はサーブレットとJSP の仕様を策定する JSR-053 のメンバーであることを注記しておきます。 JSR-053 の内部では、すべてがオープンになっていないことは明白ですし、 決定は密室で行われます。もちろん参加者が反対することは出来ますが、 それでも決定の背景には Sun の影響力があります。

第二の点: 複雑さ

JSP は仕様であると同時に実装でもあります。 この仕様には、いろいろな企業（それにオープンソース）による実装があります。 JSP 仕様は、それほど簡単に実装できるものではありません。 関連する複雑なシステムがたくさんあり、その幾つかでは性能を最適化するために、 サーブレットエンジンに特別な仕掛けさえ必要です。 JSP 仕様は比較的新しいです（まだ 1.x フェーズです）。つまり、 この仕様ではきちんと定義されていないところが何箇所もあり、 そうした箇所の個別の詳細の一部については実装にまかせられているということです。 これはつまり、多くの部分で間違いがあるだけでなく、JSP テンプレートコードが実装によって動作が異なる可能性があるということです。 このことは、複数のコンテナにまたがる JSP ベースのアプリケーションをテストする際に、 悪夢を引き起こします。特に難解なバグ (極端な条件でのみ現れるバグ) がコンテナによっては発生したりしなかったりすると最悪です。 Jakarta プロジェクトを立ち上げ、Sun に Jasper (JSP の参照実装) のソースコードを提供させた元々の理由の一つに、 ソースコードの単一の基準を採用するようにベンダーを推奨することがありました。 残念なことに、そうはなりませんでした。互換性テストスイートはありますが、 ベンダーがテストに合格することを必須とする方針は決まっていません。 また、テストに合格しないベンダーを打ちのめすべく公にさらす場所もありません。

最後の点: Velocity

Velocity がどんなものになるかは、このプロジェクトの開発者が決めます。彼らは、Velocity へのどんな変更点も既存のテンプレートをダメにしないことを確認する回帰テストで使用する、 包括的なテストスイートを作成しました。もし、あなたやあなたの会社が Velocity の開発に参加し、その方向性の決定に手を貸したいのであれば、 メーリングリストに加わって、開発作業に貢献するだけでOKです。これはつまり、 どんな企業も Velocity の仕様を独占できないということであり、Velocity ならどんなサーブレットエンジンでも同じテンプレートが動作するということでもあります。

[どちらを選ぶかは] あなたが判断してください。

[ 組み込みでの使用 <- 前 | 次 -> ホスティング ]