JSR 277(Java Module System)とOSGi(JSR 291)の間の重複に関する過去の議論を再開するJSR 316(Java EE 6)の提案によって、OSGiとJSR 277に関する議論が再び激しくなっている。
ピーター・クリエンス(Peter Kriens)は、Java EE 6のプロファイルの利用について検討するブログエントリーの投稿で、Java EE 6の代替の基盤としてコンポーネント化を提示する。クリエンスはまた、Java EE 6の仕様におけるJSR 277の利用について、疑問を述べた。
JSR 316では、JSR 277についてのみ、やや間接的に言及しています。彼らは基本的に、277が現れるまでは、どんな決定も延期するつもりだと言っています。それらの番号から判断すると、277は291より古く成熟しているので正しく見えますね？ただし、1999年に始まり4つのメジャーな改訂を経た非常に成熟した仕様(OSGi)を基にした291がすでに「Final Release」にあり、277はまだ「Early Draft Review」である、という事実を別にすればですが。つまり、JSR 291について言及されない別の理由があるはずですね？277はJSR 291が持っていない機能を提供するのかもしれませんね？しかし、そうではありません。JSR 277の仕様要求を見ても、目標とするレベルがJSR 291(OSGi)と比較して高いとは言えません。動的でない、クラス空間一貫性がない、アンローディングでない、パッケージインポートがない、など。 JSR 277の早期ドラフト(Early Draft)は、まだとても簡素なレベルにあります。291にない唯一の本当の付加機能はリポジトリですが、未解決の問題もたくさんあります。JSR 277が最近になって開設したメーリングリストでの議論を見ると、彼らはモジュラリティの基本的な考えのいくつかについて、まだ揉めているようです。しかし幸いなことに、JSR 277の専門家グループは、277のモジュールシステムをJSR 291(OSGi)と相互運用させることを約束しています。それは、OSGiを選択することを、2008年後半に出てくるJava 7の上でのみ実行できるJSR 277とは異なり、今日の広範なVMの上で(1.2から6まで、組み込みデバイスでも)実行されている付加的な利益を提供するのと同じくらい、安全にします。それでは何故JSR 316は(277を)待つのでしょうか？完全なソリューションが今日、存在して、JSR 277によって明日の互換性も約束されているのに？
アレックス・ブリューイット(Alex Blewitt)もまた、JSR 277を利用するというJava EE 6の決定に疑問を持つ。
提案の状態:プラットフォームの拡張性という目標をより良くサポートするために、モジュールのより一般的なコンセプトを持つことは有益でしょう。. そのような作業が、JSR 277(Java Module System)で、Java SE 7をターゲットに進行中です。私たちはその技術がJava EE 7の基盤になると予想するため、将来のリリースと少しでも矛盾する可能性のある技術は、仕様を延期するつもりです。言い換えると、彼らはJSR 291よりもJSR 277を選んだので、Java 7でJSR 277がリリースされるまでは、他の何も検討するつもりがないということです。.
エリック・ニューカマー(Eric Newcomer)はまた、SunがOSGiを採用するべきだと考えるかどうかについて、InfoQから質問を受けている。
もちろん。世界中のすべてに気付かせるつもりです。より大きな疑問はJavaの将来にあります。SunがOSGiを採用するにせよ、それと争い続けるにせよ。もし彼らがOSGiと争い続けたら、Javaにどのような影響を与えるでしょうか。 私の最近の、そしていくらか限られたOSGiでの経験から、それはさまざまな点 - モジュラリティ、バージョニング、改善されたクラスローディング - で、Javaを大幅に改善するように見えます。
SunはJSR 291に反対票を投じました。それはいずれにせよ通過しましたが。OSGiは正式にJSEの一部になります。 しかしそれは、Sunの見解のいくらかを表しています。SunはJava 7の基盤としてOSGiを採用する絶好の機会を持っています。しかし、公式声明こそありませんが、彼らはOSGiを採用するよりも、重複させる方向に傾いているように見えます。 SunはJava 7の基盤としてOSGiを採用する絶好の機会を持っています。しかし、公式声明こそありませんが、彼らはOSGiを採用するよりも、重複させる方向に傾いているように見えます。私はSunがなるべく早くOSGiの考えに気付くことを望みます。 たぶんSunはOSGiに反対し続けるよりも、そうするべきでしょう。これまでのところ、OSGiはうまくいっているのですから。
JSR 291の専門家グループのメンバーであるハニ・スレイマン(Hani Suleiman)は、この議論に対して異なる見解を持っている。
～JSR 277は(ある程度)共通しています。それはJDKの側から問題に取り組み、OSGIおよび他のソリューション(maven、ivy、など)をとても扱いやすくします。バンドルされたモジュールは、JVMのレベルで一級市民になります。
それ以上に、それ(をどのように活用するか)は彼らが望む任意の付加価値を提供する(OSGiまたはその他の)フレームワーク次第です。277はそれを制限しません。OSGiの人たちは、標準のベースラインが彼らの実装でないことに混乱しているだけで、実際には他のことも考慮しています。
Hibernateに例えるなら、JBossがJPAの仕様を非難し続けることを想像してください。それは、車輪の再発明だ、代わりにみんなでHibernateを標準化するべきだ、と言うことです。それがOSGiの人たちがしていることです。
その他に、ニール・バートレット(Neil Bartlett)などは、JSR 277の専門家グループの議論について関心を高めている。
JSR 277の専門家グループのメーリングリストを見てください。現在それは一般に公開されています(読むだけですが)。そして、2人のOSGiの専門家 - グリン・ノーミントン(Glyn Normington)とリチャード・ホール(Richard Hall) - の考えを理解することは、とても大変です。それは決して、彼らの努力が足りないからではありません。JSR 277のドラフト仕様には多くの領域があり、現在のたたき台はOSGiと相いれないのです: Sunは、JSR 291(OSGi)の経験から何かを学ぶことを、頑なに拒否しています。
OSGiの人たちは、単に私たちのお気に入りのモジュールシステムが選ばれなかったために、不平を言っているのではありません。 それは子供じみているでしょう。私たちがこれほど大騒ぎしている本当の理由は、JSR 277がモジュールシステムとして失敗に向かっているからです！壊れたモジュールシステムをJVMに入れることは、エンタープライズJavaのコミュニティにとって、大きなダメージとなるでしょう。
議論の発端についての別の見解は、クリス・キュスティーヌ(Chris Custine)より提示されている。
私はSunとOSGiの間の大きな衝突は、とても単純なコントロールとライセンスについての政治的な争いだと思います。技術なんてばかばかしい！またしてもJavaの政策は、賢明な人たちの間に普通に広まっているであろう、常識と論理を無視しています。私は、Javaが革新と進化の能力を復活させることに、とても期待していました。しかしこれは、私が心配していたようなことです…JSR 277の専門家グループのメンバーであり、JSR 291の仕様策定者でもあるグリン・ノーミントンは、議論に関するより慎重な見解の提示を試みている。 機能の比較に加えて、ノーミントンはまた、この議論の全体を取り囲んでいる問題の詳細について述べた。彼は言う「これらのJSRの目標はかなり異なります。基本的な概念は似ていますが。JSR 277と294がJava SEプラットフォームに基本的なサポートを組み込むのに対して、JSR 291はJavaプラットフォームの上に構築される純粋なJava(pure Java)です」 ノーミントンはJSR 277の中でOSGiを再利用するのは容易ではないと述べる。彼はまた、決定が下される前の検討で、JSR 277を捨て去るという考えを却下する。
理想のソリューションは、はっきりしています: JSR 277はJSR 291を取り入れ、JSR 294の言語とVMのサポートに支えられて、JSR 277のリポジトリのアーキテクチャを追加するべきです。これは数年でJSR 277の進歩を加速し、JSR 277とJSR 291の間の完全な相互運用を保障するでしょう。
しかし、この理想は実現するには、Sunが方針を転換する必要があります。 もしかしたら、Sunは最終的に決定するJavaの成功に、十分な努力を払っているかもしれません。もしかしたら、Javaのコミュニティは後で振り返り、ウィンストン・チャーチルを引用するかもしれません。「いつもSunが正しいことをすると期待できた。すべての代案が尽きた後に」
この問題に対する最良のソリューションは何かについて、コミュニティには多くの議論が確かにある。あなたはどう考えるでしょうか？