非常に便利なWebサービスフレームワークJersey（JAX-RS aka jsr-311;およびそのロック開始実装）と素晴らしい検証ライブラリHibernate Validator（ "Bean Validation API"、jsr-303）を取り上げました。最も有望な新しいJSRですか？
これらのjsrsは両方とも相対的に新しいものであり、数多くのJSRがあり、さまざまなレベルの進歩、活動、潜在的可能性があることを考えると、追跡が容易ではないモール。
2を超えると、他の人が有望で、注意を払う価値があると考えていることは何ですか？
JSR-291：OSGiのモデルに基づいたJava™SE
の動的コンポーネントのサポート、Javaで統合持っていることは非常に興味深いものだったでしょう。
しかし、JSR-277（Javaモジュールの依存関係）... before being droppedが現在のJDK7の実装から選択されました。
一方、plenty of OSGi frameworks out there to play withがある;）
記事 "モジュールの依存関係の表現" で述べたように：277であるJSR 291とJSRとの間の主な相違点の
つモジュールの依存関係を表現、満足、管理する方法。
[...]より重要な違いは、モジュールのコレクションの動作を予測できる必要性に関連しています。これはモジュールの依存関係を管理する際に重要です。 で
JSR 291、外部管理システムは、任意であるかどうかを、各モジュールに依存性宣言を読み、これらのモジュールはアップ配線される方法を決定するために、明細書にルールを適用することが可能です依存関係が存在しない場合、どのようにそのような依存関係を満たすことができるかを示します。
JSR の場合、インポートポリシーを使用すると、位置が大きく異なります。 インポートポリシーの動作を判断する唯一の方法は、を実行することです。しかし、それでも、輸入政策が実行されるたびに同じ結果が出るという保証はありません。依存性が欠如している場合にも、行方不明の依存関係は、私は携帯電話でより頻繁に実装を参照してくださいしたいと思います
ものですJSRを満たすことができるかを決定するために、インポート方針を検討することは不可能です-239 OpenGL-ESバインディング（Nifty NIOバッファを使用）とJSR-256 Sensor API（少なくともOSGiとの関係があります）。
私はOSGiに似ていますが、今のところ軽く使っています（そして、いくつかのlibsを適切なOSGiバンドルとして実行するだけです）。 私はまた、JSRプロセスからの見えるNIH症候群（すなわち、OSGiは代替案に先立つが、そのドメイン内ではほとんど無視された）がなぜ疑問に思っています。ああ、それは以前に起こったことです（log4j対J.U.Lなど） – StaxMan