InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

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

作者 Alex Blewitt , 翻訳者 James Neoman 投稿日 2008年4月8日

セクション
デベロップメント,
エンタープライズ・アーキテクチャ
トピック
Java ,
エンタープライズアーキテクチャ
タグ
OSGi ,
JSR 277

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

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。