JSR277とOSGiは一つになるか？

作者 Alex Blewitt , 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2008年6月10日

セクション

デベロップメント,

設計/アーキテクチャ

トピック

Java ,

言語 ,

テクノロジー

タグ

JSR 294 ,

JSR 277 ,

JSR 291 ,

JavaOne 2008 ,

OSGi

JSR277とOSGi (別名JSR291)の状況に関する4月のニュース(source)が、JSR277の専門家グループのメーリングリスト(source)で新たな議論の火付け役となった(source)。それは、今のところ今年一番の月間投稿数を記録している。この出来事の主なドライバの一人はBryan Atsatt氏(source)である。彼は、JSR277 (モジュール) とJSR294 (スーパーパッケージ) の両方の専門家グループのメンバである。彼は、JSR277はOSGiにとって最適になりうる(source)と主張する。

最初の仕様は、実際には2つの部分からなります。それは、API/フレームワークと新しい配布形式の実装です。あいにくその区別はひどくあいまいな方法で示されています。さらに悪いことに、新しい配布形式 (".jam"ファイル) が、主役を務めることが多いのです。

それでは、JSR277がどのようにOSGiにとって最適になりうるのでしょうか？それは、SE環境にバンドルを緊密に統合できるようになることによってです。主に4つのメリットが挙げられます。

• 標準的な記憶モデル
• コンパイル時の依存の解決
• モジュールの実装をまたいだクラスやリソースの共有
• コマンドラインの実行

そして、これは既存のOSGiのバンドルとしてすべて動きます。これって素晴らしいでしょう？おそらく、まだ望みはあります。

実際に、Bryan氏はJSR277の専門家グループの最近の多くの投稿のドライバであった。彼は、仕様は実装から分離すべきである(source)という点を挙げた。これらは専門家の草案レビューの発表に入っている。そして、Peter Kriens氏が参加すべき(source)との点も挙げた。

この専門家グループは停滞していて、生命を吹き込まなければなりません。次の具体的なステップを提案します。

1. 専門家グループにPeter Kriens氏を参加させる。Peter氏は、この分野で素晴らしい専門技術を実証しています。私は、彼が直ちに重要で活動的な貢献者になると信じます。 
2. 相互運用の設計、議論、調査のプロセスをSunのオフィスから専門家グループへ移す。
3. ソースツリーの機密情報 (または、少なくとも直近のスナップショット) の読み込みアクセス権を専門家グループに与える。

実際、ほとんどの議論と実装に関する決定はSunの閉じられた扉の向こう側で済んでいて、専門家グループは決定した後で確認するだけのものとして扱われているようである。実はこれらのポイントは両方ともPeter Kriens氏が明らかにした。彼は、現在の状況に巻き込まれたくはなかったのだが(source)。

しかしながら、JSR 277は、今、良い部分2つ(リポジトリと言語モジュール) と悪い部分1つ (JAM) で構成されています。JavaOne 2008の直前に、Stanley氏は簡潔なOSGiの相互運用性のドキュメントを公表しました。このドキュメントは詳細が書かれていないだけでなく、多くの場所で公表されていないEarly Draft #2 (EDR2)を引用していました。私は、専門家グループのメンバ、BJ Hargrave氏 [Equinox開発者] と Richard Hall氏 [Felix開発者]にこのEDR2を見たことがあるか尋ねました。しかし、彼らも知りませんでした。最近、私は、JSR 277のメーリングリストで議論がなされていないことについて不満をもらしました。どうやら作業は内密になされていたようです。

Alex氏とStanley氏のJSR 277の発表の中で、多くの作業は水面下で起こっていることが明らかになりました。メーリングリストでは何もやりとりされていませんでした。聴衆にはまったく明らかにされていませんでしたが、そのプレゼンテーションで言われたことは、ほとんどすべて専門家グループで議論されていないことだったのです。唯一できることがカーテンの後ろでSunがした作業を承認するだけだとしたら、どのように専門家グループに参加できたというのでしょうか?公表されていないEDR2をJSR 277の決定事項としてJavaOneで発表するならば、どれだけ変更の余地があるというのでしょうか?すでにほとんどの作業が済んでいる専門家グループに参加すべきでしょうか？このような状況でどれだけ基本的な変更を実現できるでしょうか?

私たちは、今、まさに正念場にいます。私は、Java言語のモジュールとリポジトリについて議論に参加したいと思います。しかし、合理的な理由もないこの複雑な状況の中で、Javaのモジュールシステムを担うことはできません。私は、Sunがこの最後のステップをも踏み出し、システムを通してOSGiのメタデータを使うずっと簡単なアプローチに賛成して、JAMの採用をやめることを希望します。ここ数ヶ月、いろいろなことがありました！どうかお願いできないでしょうか?

一方、Sunが新しく参加したことでOSGiの相互運用はよい方向に向かっている。Alex Buckley氏(source)が277の専門家グループに参加した(source)。 (そして、高く評価された(source)前述のJSR294の単純化(source)の責任を持つことになった。) ; Mandy Chung氏(source)は、OSGiの相互運用性に取り組む作業(source)を受け持っている。  

少々遅れ気味ではあるが、Sunは耳を傾けているようである。今年のJavaOneで、私たちはOSGiベースのSpring Source Application Platform(サイト・英語)と OSGiで動くGlassfish(source)について報告した(source)。OSGiのベストプラクティスのプレゼンテーション (PDF) (PDF・英語)が新しい興味の火付け役となり、JavaOneの後、バンドルについて議論するフォーラムやブログが増えてきている。私たちは、JSR277 EDR 2(source)がこれらの点をすべて心にとめて、OSGiとJSR 277を一つにするように期待することができる。

原文はこちらです：http://www.infoq.com/news/2008/05/jsr277-osgi

• 次へ >