BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース JSR 277とJSR 291 プロトタイプの欠如によるインターオペラビリティの危機

JSR 277と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

この記事に星をつける

おすすめ度
スタイル

BT