Glyn Normington氏は、JSR 277、JSR 291、JSR 294をカバーするJavaモジュール性の概要を記述した。
彼は、それぞれの違いを述べ、その有用性を加え、続いて何故我々が(OSGiのような)カスタムクラスローダーに対して、JVMでサポートするモジュール性を必要とするのかという疑問に答えている。
Normington氏は、彼の個人的な関わりや偏見とともに3つの仕様を再構成したことで有名である。
彼は3つの仕様について、次のように書いている。
JSR 277は、Java7で静的モジュールのシステムを作ろうとしています。
JSR 291は、既に成熟したOSGiの動的コンポーネントのシステムを参考にし、それを拡張しています。
さらに、Java MEと類似性のあるJSR 232と互換性があります。
JSR 277の派生であるJSR 294は、VMと言語がモジュール性をサポートすることにフォーカスをあてています。
Normington氏は続いて、これらの仕様に関して多くが疑問に思っている、何故OSGiを採用せずに新しい仕様を作成しているのかということにふれている。
彼は、Javaの次のメジャーリリースの前に、JSR277をOSGiのあるバージョンに閉じてしまうことは、OSGiの新バージョンへのアップグレードを妨げるだろうと主張している。
OSGiは、OSGi R5若しくはさらにそれ以降で、追加要求を解決しなければならないアプリケーションの新たな領域へと、急激に広がっています。
Java7など特定のJava SEのバージョンに閉じてしまうことは、OSGiの特定のバージョンをJava 8の前にアップグレードする機会を失うでしょう。
例えば、OSGiの何か新しい機能を必要とするアプリケーションは、必ずしもJava 8の環境へのデプロイに制限したいのではありません。よって、必要に応じてJavaとOSGiのバージョンを組み合わせることができるということは、必要不可欠なのです。
Neil Bartlett氏は、Normington氏の投稿を取り上げ、それはいくつかの疑わしい前提に基づいているように感じた。
結局、OSGiは正常に機能しています！そして、(SunのJVMのいくつかのバグを与えるか受けるかする)それは、クラスローダーの機能拡張を全く必要としないのです。
では、JSR277、294のエキスパートグループがクラスローダーに入れようとしている機能拡張は何か？何故、それらが必要なのか？
これは、OSGiが完全に動的であるのに対し、JSR 277が静的なモジュール性のシステムであり、実質OSGiより意欲的なものではないので、とりわけ奇妙に思えます。
残念なことですが、私は、JSR 277を取り囲んでいる秘密のベールのせいで、彼がこの質問に答えられないのだろうかと疑ってしまいます。
Bartlett氏は続いて、ある技術がJVMに取り入れられると、それをアップグレードする可能性が制限されると記述している。
彼は、何故XercesをベースとしたXMLのAPIがJava1.4に入れられたのか、何故大量のJPAが急速に発展するHibernate3プロジェクトをベースにしたのかについて指摘している。
Normington氏は、JVMの実行の追加レベルを指定することで、カスタムクラスローダー以上の何かの必要性に関するBartlett氏の指摘に答えている。
JSR 294は、クラスローダーがアンエクスポートされたクラスのインスタンスを読み出すことを防ぐだろう。
これは、いくつかのパフォーマンスの最適化に対する可能性だけでなく、不正なアクセスに対するセキュアなコードによるVMの追加したセキュリティへの扉が開く。
（原文は2007年3月14日にリリースされた記事です）