InfoQ

News

OSGiの支持者達のJSR 277に対する疑問に対して、Sun Microsystems社は沈黙で答え、ほとんど回答をしていない。

作者 Alex Blewitt, 翻訳者 James Neoman 投稿日 2008年4月8日 午後12時28分

コミュニティ
Java
トピック
エンタープライズアーキテクチャ
タグ
JSR 277,
OSGi

JSR 277(source)は、Sun Microsystems社が主導するグループであり、正当なJava(tm)モジュール・システムを規定している。グループは2005年6月から活動しており、2006年11月には初期ドラフト・レビューを果たした。J2SE 7.0(Dolphin)の一部になることを意図したものではあるが、本当にそうなる前に、まだやり残していることがある。JSR 277にとって幸いにも、today.java.net(source)の議論によると、Dolphinは2009年に延期されることになりそうである。

Javaをオープンソース化し、OpenJDK基盤をつくることが、Sun Microsystems社にとって、かなりの作業であることは明白です。これが、我々にとって悪い知らせになりました。Sun Microsystems社は、一般的に18ヵ月の間隔で新しいJavaのバージョンをリリースしようとしています。Java 6は、2006年秋にリリースされました。したがって、Java 7の当初リリース予定は、2008年春のはずでした。JDK7プロジェクトの最新のビルドに何も主要な新機能が統合されていないことから、ベータ版からまだまだ遠いのは明らかです。Danny Cowardは、Java 7 JSRの仕様策定に関する主要人物ですが、彼は、現在グループは、2009年1月、今からおよそ16ヵ月後にリリースを目指していると言っています。

OSG(source)またはJSR 291(source)は、ほぼ10年の利用実績を持つJava用のモジュール・システムである数多くの商用版とFelix(サイト・英語)、Knopflerfish(サイト・英語)、Equinox(サイト・英語)のような無償で入手可能な実装が存在するJSR 277がJava 7に依存しているのとは異なり、OSGiの実装は、Java 1.3とJ2MEファウンデーションプロフィールで実行できる。OSGiはすでに多くのシステムで内部的に使われているので、OSGiとJSR 277が一緒に動作するのを保証することは、JSR 277が成功するための必要条件である。

JSR 277の専門家グループは、Apache、Google、Red Hat、BEAなどJavaエコシステムの鍵である多くのプレーヤーから構成されている。そういったプレーヤの多くは、既存のJavaモジュール・システムでの経験を持っている。Richard Hall氏はFelix(サイト・英語)の作成者である。IBM社の代表はEquinox(サイト・英語)に取り組んでいる。有力な専門家グループが係わっているにもかかわらず、一般公開されているメーリングリスト(source)で議論がなされることは多くない; 実装は、openjdk.java.net(source)で論議されており、それとは違うメーリングリストmodules-dev(source)では、議論と自動化されたバグ・レポート報告が入り交じっている。

JSRがうまく運営されているかどうかに関して、今まで何回か質問があったことがある。Dalibor Topic氏は、1月に以下のように依頼した(source)

私は、JSR 277に関する明らかに休止中の複数の専門家グループの中の、活動をしていないメンバをJSRをなんとかしたいと思っているメンバと入れ替えることも提案したいと思っています。

  • David Bock
  • Stuart Halloway
  • Doug Lea
  • Ted Neward
  • Samuel Pullara
  • Apacheソフトウェア・ファンデーション
  • Ironflare社
  • Jayasoft社
  • SAS Institute社
彼らは、この5月まで、言い換えれば8ヵ月間もの間、専門家グループのメーリングリスト(source)に一つのメッセージも送ることができなかったのですし、もう彼らをガベージ・コレクションしても問題ないと思います。

 

私は、仕様策定の主導者は、この問題により興味がある専門家をすぐに見つけることができるはずだと確信しています。たとえばこのメーリングリスト(source)の読者はそれに該当すると思います。

Dalibor氏は、的確なことを言っている。JSR 277の専門家グループには、今まで何も意見表明してこなかった人たちが沢山いる。SAP社は5月より後ではあるが、コメントはした(source)。おそらく、それより問題なのは、専門家グループがモジュール・システムそのものの開発についてコメントするよう依頼されていないという事実である。その代わりに、実装の文書化によって設計が進んでいる。

OGSi(source)との互換性に関する提案は、これまでと同様に、まだまだ完成からほど遠い。この6月、JSR 277専門家グループのメーリングリストに、OSGi相互接続の状況を問い合わせる(source)ポストがあった。同じ質問がその後もなされたが、専門家グループは、互換性を持った実装をもう少しで提供できるようになるどころか、試案の実装も提示できていない。専門家グループへのごく最近のポストにおいては、Stanley Ho氏は以下のように言っている(source)

他のモジュール・システムとの相互接続性: 我々が専門家グループで討議したように、JSR 277が他のモジュール・システム(例えばOSGiやNetBeansなど)と相互接続可能にしたいと思っています。現在進行中のプロトタイピングによって、それがどのように動作しなければならないかについて明らかにしたり、全体的なアプローチを検証してきました。試案の準備ができたら、レビューや議論の為に専門家グループに送るつもりです。このJSRを公開レビューにかける前に、相互接続性は是非とも解決しておきたいものです。

JSR 277がJSR 291に準拠するかどうかはまだ解らないし、現時点では、そうではない。進歩の速度が前年と同じくらいならば、来年初めのDolphinのリリースへの取り込みには間に合わない。その一方で、JSR 277プロセスについての疑問は、残ったままである。Peter Kriens氏(source)は、Javaがより中立なやりかたで管理されるならば、違ってくるのではないかと尋ねている(source)

私は、JSR 277+294と比べたとき、どういう理由で、またどのようにOSGiサービス・プラットホームがより野心的で、より多くで優れたソリューションによってモジュラリティーの問題を解決できるかを示せるように、技術的な問題に集中できればと願っています。Sun Microsystems社が、業界からの幾多の圧力にもかかわらず、共同で適切な標準を作り上げるのではなく、技術的な理由もないのに市場を二つに分けようとしているのは大変悲しいことだと思います。私は、OSGiの仕様が完璧であるなどとは主張していません。まだまだやるべき事があります。しかし、今実装しようとしているJSR 277に比べれば、OSGiの仕様は、成熟していて、実績もあり、より市場に受け入れられています。JSR 277の実装までには、まだまだ大きな学習曲線が必要です。Javaコミュニティがより独立なやり方で管理されていた頃であれば、果たしてこのような事になっていたでしょうか?

Neil Bartlett氏(source)は、問題は、仕様策定の進め方にあるのではないか(source)という問いを投げかけている。

もう一年も経とうとしているのに、試案はずっと進行中の状態です。どれくらいの進んだのかも、あとどのくらいかかるのかもわかりません。Sun Microsystems社がまだなにかやっているのは間違いありません。OpenJDKのmodules-devコンポーネントには、まだまだ終わりそうにもない活動のログが続いています。しかし、JSR 277の専門家グループ、理論的には、一般的なモジュール・システムにはもちろんのこと特にOSGiについては世界でも一番詳しい専門家グループ、に意見を聞いたり、手助けを求めたりするつもりはないようです。

1月には、Dalibor Topicが、JSR 277の専門家グループ・メンバに、彼らの多くは全くと言っていいほど活動をしていないので、ガベージコレクションを行おうと提案しました。私も、全く同意します。仕様策定の主導者の決定から始めましょう。

InfoQは、Stanley Ho氏にコメントを求めようとしたが、連絡をとることができなかった。読者の皆さんは、どう思いますか?JSR 277は、OSGi互換なければならないのでしょうか?

原文はこちらです:http://www.infoq.com/news/2008/04/jsr277-silence

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

ジャンル別一覧

BlazeDSとAMFでWebとデスクトップのアプリケーションを構築する

現在のRIAアーキテクチャにおいて、クライアント/サーバーの通信は重要な位置を占めています。本稿では、James WardとShashank TiwariがアドビによるオープンソースのBlazeDSメッセージングサーバーの世界へ飛び込みます。

業務ソフトに手を加えずに暗号化を実現する~秘文の挑戦~

hibun

ウィルス対策ソフトや情報漏えい防止用のソフトは、いわば影の存在です。ユーザの操作性やGUIを工夫する以上に、いかに目立たない存在となるかにその技術を注ぎ込んでいます。ここでは日立ソフトが開発した「秘文」の事例を紹介します。

Google Chartとgchartrbの紹介

Google Chartは、チャートを作成するためのWebサービスです。本稿では、Google Chartのインターフェースと、Rubyコードから簡単にチャートを生成することができるgchartrbライブラリの説明をします。

SOAを超えて: 動的な業務アプリケーションのための新しいエンタープライズアーキテクチャフレームワーク

全二回からなるこの記事では、ダイナミックビジネスアプリケーション(Dynamic Business Applications:DBAs)の開発についての全体的な眺望を、アーキテクチャと方法論の観点から見ていくことになります。我々のゴールは、「ビジネスの変化や、その他に必要とされる変更に対して、いかにして容易に適応できるアプリケーションを構築していくか」を導きだすことです。

ESB接続形態のオルタナティブ

本稿では、Adrien Louis氏がESBベースのSOAに対する2つの接続形態についての賛否について説明しています。その2つとは、会社での単一のESB対「部門毎」に相互接続するESBによるシステムです。

AjaxプログラマのためのJavaOne2008 -GrizzlyでComet!-

誕生から2年を経てCometは「何が出来るのか」という議論から、「いかに実現するか」という議論に関心が移ってきたように見えます。そこで本稿では同じくJavaOneで数多く取り上げられたNetBeans 6.1とGlassFish v3を使いながら、サンプルを交えてCometを解説していく事にします。

SharePoint Webサービスを始めましょう

この記事では、WSS3とMOSS 2007に難しい設定など一切せず、すぐに利用可能なWebサービスと、Javaと.NETからそのWebサービスを消費する方法に目を向けます。

レトロスペクティブのプライムディレクティブに対する問い

この記事の始まりは、知的で思慮深い人たちの魅力的なグループが食事会を終えて話をしているところです。話はレトロスペクティブ(振り返り)プロセスの要であるプライムディレクティブ(最初の指示)に及んでいます。