私は自分自身をjavaに教えることを試みている長い時間ASP.NET開発者です。私はJettyをダウンロードし、基本的なWebアプリケーションのセットアップを取得しました。 Head First ServletsとJSPのチュートリアルでは、コンパイル時にコンテナのservlet-api.jar（またはJettyの場合はservlet-api-3.0.jar）ファイルを参照するように指示しています。サーブレットクラスを拡張しているので、これはアプリケーションを特定のコンテナのサーブレット実装に結びつけませんか？私がJettyに対して自分のアプリをコンパイルすると、TomcatやEEサーバー（glassfish、jbossなど）の下にアプリを展開できますか？特定のサーブレットコンテナに対してJava Webアプリケーションクラスをコンパイルする必要がありますか？
サーブレット固有のクラスを参照していないため、これは問題ではありません。 servlet-api.jarは、いくつかのインタフェースと抽象クラスの形式で十分に文書化された仕様です。
すべてのコンテナには、このJARのコピーが必要です（異なるJavaバージョンまたはコンパイラを使用してコンパイルされる可能性があります）。仕様を実装しているため、API自体は変更されません。ただし、コンテナ提供のJARを参照する必要はありません。あなたは安全にmavenのバージョンや他のものを見つけることができます。それらはすべて互換性があります。さまざまなライセンスの非互換性のためにバンドルされていないことがあります。
言い換えれば、は一度だけ書き込まれ、どこでも実行されます。もここで適用されます。
あなたはjarにコーディングしていないので、jarに含まれるような仕様にコーディングしています。 Webコンテナを提供するサーバはすべてこの仕様の実装を持ちますが、含まれているjarはまったく無関係です。
仕様にのみコーディングすれば、サーバーの実装に縛られることはありません。
jarは、必要なクラス依存関係を解決するために、コンパイル時および実行時に使用されます。コンパイル時に必要なAPI依存関係を提供する任意のjarを使用できますが、実行時に暗黙的に特定のサーバーによって提供される実装を使用します。スタンドアロンのアプリケーションとは異なり、標準のAPIまたは実装を含めるために独自のwebappの特定の設定を行う必要がないため、暗黙のうちにサーバーはすでにそれを提供します。
あなたはHttpServletを拡張していると仮定しますか？ Jettyには、このクラスやhttpサーブレットのフレームワークに関する一般的なことはありません。特定のコンテナ実装に縛られることはありません。 – skiller3
なぜ各コンテナには独自のサーブレット実装が付属しているのですか？なぜサーブレットAPIはJavaコアライブラリの一部ではなく、スタンドアロンパッケージのどこかにありますか？ – Chris
私が知っている限り、コンテナは独自のサーブレット実装を持っていません。 Jettyの保守担当者は、サーブレット-api-3.0.jarをあなたの便宜のためにダウンロードしてバンドルしました。Jetty（すべてのコンテナと同じように）は実行時にクラスを必要とするためです。クラスは非常に特殊なコンテキストに対応しているため、コアJavaの一部ではありません（世界中で多くのプロダクションサーブレットコードが与えられています） – skiller3