The first point: Standards − 第一の点: 標準

One of the touted advantages of JSP is that it is a "standard" and quite a few people like to hold this in high regard. So much so that they refuse to use any technology that is not "standard." Digging into the reality of this statement reveals that the important correct terminology is that JSP is a "Sun Standard Specification" and not strictly a "standard." This is important because JSP is really no more "standard" than Microsoft ASP or the PHP Group's PHP product. In other words, whatever tool you happen to be using becomes the "standard." JSP で宣伝されている利点の一つは、「標準」であるということです、 そして相当な数の人々がそれを重視していますが、 そうするあまり、「標準」でない技術はどれも拒否してしまいます。 この利点に関して、真実を追求するとわかることですが、 用語に正確にしたがえば (これが重要です)、 JSP は、「Sun標準仕様」であり、厳密には「標準」ではないのです。 このことは重要です。なぜなら、JSP が実は Microsoft の ASP や PHP Group の PHP と同様、「標準」でないからです。言い換えれば、 あなたがたまたま使っているツールはどれでも「標準」になるかもしれません。 A small group within the Java Community Process (JCP) defines what JSP is. The fact of the matter is that there is a fairly high barrier to joining the JCP because an NDA must be signed, the project leads must approve your entry and in some cases a fee must be paid. One could even stretch as far as to say that the JSP specification is really a proprietary product of Sun! JSP を定義しているのは、Java Community Process (JCP) 内の小さなグループです。 実際問題として、JCP に加わるにはかなり高い障壁があります。 なぜなら、NDA (機密保持契約) にサインをした上で、 プロジェクトリードによる加入の承認を受けなければならず、 場合によっては料金を払わなければならないのです。 極論すれば、JSP 仕様は実は Sun が所有する製品であるということになります。 It is important to note at this point that the primary author of this document (Jon Stevens) is a member of the JSR-053 which defines the Servlet and JSP specification's. ここで重要なこととして、この文書の元の作者 (Jon Stevens) はサーブレットとJSP の仕様を策定する JSR-053 のメンバーであることを注記しておきます。 Inside JSR-053, it is clear that not everything is done in the open and decisions are made behind closed doors. Of course the participants could object, but Sun still is the binding force behind the decisions. JSR-053 の内部では、すべてがオープンになっていないことは明白ですし、 決定は密室で行われます。もちろん参加者が反対することは出来ますが、 それでも決定の背景には Sun の影響力があります。

The next point: Complexity − 第二の点: 複雑さ

JSP is both a specification as well as an implementation. There are various corporations (as well as Open Source) implementations of the specification. The JSP specification is not a particularly easy thing to implement. There are many complex systems involved, some of which even require special hooks into the Servlet Engine in order to obtain optimal performance. JSP は仕様であると同時に実装でもあります。 この仕様には、いろいろな企業（それにオープンソース）による実装があります。 JSP 仕様は、それほど簡単に実装できるものではありません。 関連する複雑なシステムがたくさんあり、その幾つかでは性能を最適化するために、 サーブレットエンジンに特別な仕掛けさえ必要です。 The JSP specification is relatively new (it is still in a 1.x phase). This means that the specification also has several places in it that are not as well defined as others, leaving some of the specific details to be determined by the implementation. Not only does this mean that there is plenty of places to make mistakes, but it also means that JSP template code has the possibility of not behaving the same across implementations. This makes testing JSP based applications across several different containers a nightmare. Especially if there are essoteric bugs (meaning bugs that only show up under extreme conditions) in one and not in the other. JSP 仕様は比較的新しいです（まだ 1.x フェーズです）。つまり、 この仕様ではきちんと定義されていないところが何箇所もあり、 そうした箇所の個別の詳細の一部については実装にまかせられているということです。 これはつまり、多くの部分で間違いがあるだけでなく、JSP テンプレートコードが実装によって動作が異なる可能性があるということです。 このことは、複数のコンテナにまたがる JSP ベースのアプリケーションをテストする際に、 悪夢を引き起こします。特に難解なバグ (極端な条件でのみ現れるバグ) がコンテナによっては発生したりしなかったりすると最悪です。 Part of the founding reason for creating the Jakarta Project and having Sun release the source code to Jasper (the JSP reference implementation) is to encourage vendors to adopt a single base for their source code. Unfortunately, this has not happened. There is compatibility testing suites available, however there is no policy in place requiring vendors to pass the tests. Nor is there a place that shows vendors who do not pass the tests in order to publicly humiliate them into submission. Jakarta プロジェクトを立ち上げ、Sun に Jasper (JSP の参照実装) のソースコードを提供させた元々の理由の一つに、 ソースコードの単一の基準を採用するようにベンダーを推奨することがありました。 残念なことに、そうはなりませんでした。互換性テストスイートはありますが、 ベンダーがテストに合格することを必須とする方針は決まっていません。 また、テストに合格しないベンダーを打ちのめすべく公にさらす場所もありません。

The final point: Velocity − 最後の点: Velocity

The definition of what Velocity is is set forth by the developers on the project. They have created a comprehensive testing suite that is used for regression testing to ensure that all changes to Velocity will not break existing templates. If you or your company ever wants to join the development of Velocity and help determine its direction that can be done easily by simply joining a mailing list and contributing to the development effort. This means that no one corporation will ever own the Velocity specification and it also means that Velocity will always work with your templates within any servlet engine. Velocity がどんなものになるかは、このプロジェクトの開発者が決めます。彼らは、Velocity へのどんな変更点も既存のテンプレートをダメにしないことを確認する回帰テストで使用する、 包括的なテストスイートを作成しました。もし、あなたやあなたの会社が Velocity の開発に参加し、その方向性の決定に手を貸したいのであれば、 メーリングリストに加わって、開発作業に貢献するだけでOKです。これはつまり、 どんな企業も Velocity の仕様を独占できないということであり、Velocity ならどんなサーブレットエンジンでも同じテンプレートが動作するということでもあります。

You make the decision.

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

[ Embedded Usage <- Previous | Next -> Hosting ]

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