かなり最近、私は非常に便利な Web サービス フレームワークであるJersey (JAX-RS aka jsr-311; とそのロック スタート実装) と、気の利いた検証ライブラリHibernate Validator (「Bean Validation API」、jsr-303) を手に入れました。
これらの jsr は両方とも比較的新しいものであり、他に何が欠けているのか疑問に思います。数百の JSR が存在し、さまざまなレベルの進捗状況、アクティビティ、および可能性があることを考えると、それらすべてを追跡することは容易ではありません。
私が言及した 2 を超えて、他の人は他に何を有望で注意を払う価値があると考えていますか?
JSR-291 : Java™ SE の動的コンポーネントのサポート
OSGi モデルに基づいて、それを Java に統合することは非常に興味深いことでした。
しかし、現在のJDK7実装から削除される前にJSR-277、最終的に選択されました（Javaモジュールの依存関係） 。
それまでの間、たくさんの OSGi フレームワークがあります ;)
記事「モジュールの依存関係の表現」で述べたように:
JSR 291 と JSR 277 の主な違いの 1 つは、モジュールの依存関係を表し、満たし、管理する方法です。
[...] より重要な違いは、モジュールのコレクションの動作を予測できる必要性に関連しています。これは、モジュールの依存関係を管理するときに重要です。
JSR 291を使用すると、外部管理システムは各モジュールの依存関係宣言を読み取り、仕様のルールを適用して、これらのモジュールがどのように接続されるか、欠落している依存関係があるかどうか、および欠落している依存関係があるかどうかを判断できます。依存関係を満たすことができます。
JSR 277では、インポート ポリシーが使用される場合の位置がまったく異なります。インポート ポリシーの動作を決定する唯一の方法は、それを実行することです。ただし、その場合でも、インポート ポリシーが実行されるたびに同じ結果が得られるという保証はありません。また、欠落している依存関係がある場合、欠落している依存関係を満たす方法を決定するためにインポート ポリシーを調べることは現実的ではありません。
携帯電話にもっと頻繁に実装してほしいのは、JSR-239 OpenGL-ES Binding (気の利いた NIO バッファーを使用) と JSR-256 Sensor API (少なくとも OSGi と何らかの関係がある) です。