InfoQ

News

JSR 277とJSR 291 プロトタイプの欠如によるインターオペラビリティの危機

作者 Rob Thornton, 翻訳者 編集部 投稿日 2007年9月14日 午前3時1分

コミュニティ
Java
トピック
JCP Standards,
コミュニティ
タグ
JCP,
JSR 277,
OSGi,
JSR 291
最新のJSR 277(source)とJSR291(source)とOSGi(source)に対する激しい議論が先週、JSR 291のスペックリード、またJSR 277のExpert GroupメンバーでもあるGlyn Normington氏の投稿により(source)表面化した。彼はExpert Groupが試案をまだ提示できていないので、それに関して議論し変更を加える余地も無くそれにただただ刻印を押すことになるだろう。

先週NormingtonとBryan Atsatt氏(JSR 277 Exper Groupメンバー)は、JSRのメーリングリストに対して試案の状況とそれをいつ閲覧することができるのかという質問を投げかけた。JSR 291のスペックリードであるStanley Ho氏は下記のように答えている。(source)

現在まだそれは進行中のプロセスにあり、それがどのように作動するかを解明するのと全体的なアプローチを評価するプロトタイプが行われている。私は Expert Groupに対してそれが出来た時に閲覧して話し合うよう試案の提案を送るつもりだ。インターオペラビリティに関してはJSRが公式レビューを行う前絶対に提示したい内容だ。

Normington氏は277と291がどのように統合するかに関して懸念を示している。Normington氏は下記のように述べている。

Expert Groupと他の広い範囲のコミュニティにとってこれは全く可視化していない。これはモジュールプロジェクトとしては多少奇妙だがOpenJDK上でセッ トアップされているので、その種のプロトタイプが初期段階のフィードバックのためにブランチやサブディレクトリに行くことを想定していただろう。

OSGiの専門家であるRichard Hall氏と自分、そしてJSR277Expert Grouptと291Expert Group内の人々が現在それを助けることができないから心配なのだ。試案ができるまでには重要な変更を加えるのは手遅れになっているかもしれない。

Alex Miller氏はそれがプラットフォームに与える影響に関して考えるよう、Javaコミュニティ全体に呼びかける事を強調した。(source)

正しいやり方で行えば私たちを助け、Java同等のCPANかRuby Gemsを作らせてくれる。間違ったやり方でやればデプロイメントとバージョンマネジメント、JARを今よりも遥かに悪化させるだろう。私たちの言語、ラ イブラリ、ツールに深く影響してくるのでこれは正しく行うのは必須なのである。

またMiller氏はJava Posse(サイト・英語)に対してJSRの状況をもっと深く見るよう呼びかけている。彼らは最近数回それを口にしておりディスカッショングループ(サイト・英語)にてその話題に火がついていた。Neil Bartlett氏は、もしインターオペラビリティがSunが主張しているよりも困難という理由で試案が遅れたらと思いをめぐらせている。

OSGiモジュールがJSR277モジュールとすっきりと相互運用するだろうか。私はJSR 277のExpert Groupメーリングリストを追ってきたが、それに希望があるようには思えない。JavaOneでは全てのExpertGroupメンバーが一体となり、またStanley HO氏はSunがインターオペラビリティの試案のデザインを提供するであろう事をExpert Groupに約束した。しかしながら他のExpert Groupのメンバーと共有できるものはまだ何もなく、彼らが試案デザインに参加するのさえ拒否している。私が不信に思う点-これはOSGiに参加した人々全員に共通しているのだが、二つのモジュールシステムデザインは全く違いすぎてSunは現在、どのようにしてインターオペラビリティ試案を打ち出すのか全く分からず苦戦しているということだ。

この討論の経歴はInfoQの以前のニュースにて参照して欲しい。(ニュース・英語)

原文はこちらです:http://www.infoq.com/news/2007/09/jsr-277-strawman
ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

特集コンテンツ一覧

トップスポーツチームの監督に教わる秘訣

この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。

事例研究:Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト

この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。

Agile2008チーム参加レポート - 帰国そして変化

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。

SilverlightとJavaのインターオペラビリティ

マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。

Agile2008 チーム参加レポート - カンファレンス参加編

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。サブミッションが選択された人、そうでない人も含めて、個々の目的意識の確認、膨大なプログラムから聞きたいセッションの選択、旅行の準備、プレゼンテーションの準備の期間を終えて、無事当日を迎えました。

Agile2008 チーム参加レポート - 動機/準備編

筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。

Javaトラブルシューティングメルマガ総集編 2008/08~09

エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。

モデル駆動アプローチがうまく機能しない(しなくなる)8 つの理由

この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。