ディベート：JCPはJavaの未来においてどんな役割を果たすのか？

作者 Ryan Slobojan, 翻訳者 編集部 投稿日 2007年12月13日 午前12時7分

コミュニティ

Java

トピック

コミュニティ,

JCP Standards,

ガバナンス

タグ

JSR 277,

JCP,

OSGi

最近Alex Blewitt氏(ブログ・英語)はJava Community Process(JCP)を”頭がないのにそれに気づかず走り回っている鶏”に例え、それが既に死んでいる状態にあると記載した。これはJCPの実用性とそれがJavaの未来において、どのような役割を果たすのかという事に関して論議を巻き起こした。

彼のブログ掲載(source)で、Alex Blewitt氏はJavaとJCPに関する懸念を表した。

• JCPはほとんど除かれずたくさん追加され、より大きなJVMサイズとなってしまった
• 今やVMはどのような環境でも動く必要があり、何も動作対象外としてはいけない。コンシューマJRE(source)は出発点なのだが、それはそれらを前もって行うよりもむしろjarのダウンロードを遅らせる－それでもまだJREは全体的にダウンロードされている
• 使用されないものはダウンロードされなくなるので、Javaは動的な、オンデマンドコンポーネントダウンロードを許容するモジュールシステムが必要である
• モジュールシステムとJava上の機能が今日存在しているが、既存のソリューションより拡張した、また機能性の低い新しい何かがJava 7用に作られている。そしてそれはほとんどの実装者によって置き換えられるだろう（java.util.loggingとXMIパーサーに似ている）
• Javaの進化（付加と同様に削減も）における責務がほとんどない
• マイクロソフトは言語の最前線においてJavaを打ち負かしている。.Netはたくさんのデベロッパたちによって日常的に使われている言語をいくつか所有していて、JavaはJava以外”小さなハエ”であるのに加えそれのみしか持っていない。Javaはジェネリック、持続性、価値ある機能のような言語機能に関して遅れを取り戻そうとしている
• ScalaのようなクロスVM言語に対する隙間はいくつかあるのだが、将来的な道筋はグーグルのGWTとAndroidアプローチである可能性が高い。 Java言語を再利用してJava APIのサブセットをターゲットとし、ほっておいたら招かれる余分な重荷を防ぐためにその製品をJCPの外で開発するようになる
  
• J2MEは問題である。デバイスの中で巨大な隔たりがあり、J2MEはBluetooth、USBかもしくは電話の呼び出しのような実用的な物事を処理できないのである
• JSRはずっしりと重く、既に拡張しているプラットフォームに輪をかけて拡張性を加える。JCPは軽量のモジュラーアプローチとその外で起こる真のイノベーションを防ぐ
  

Blewitt氏はまた下記のように述べている。

JCPはコミュニティは重要ではない。コントロールが重要なのである。JSRをどれでも良いから読み通すと”なぜ既存のシステムのよって提示されていないのだろう？”という事に関するセクションがある。それを読むとマーケティングのエクササイズになる。そこには常に本当の理由はないのだが、’私達はそれをより良く・異なる方法で・より小規模で・より速く 行うことができるのである。’。この状況において本当に起こるのはスペックリード達が既存のものの上に構築することに関してまったく興味が示さないということだ。彼らは彼ら自身のコードベースバージョンを作りたいのである（それが本物もしくは提案されたものであるかに関わらず）。そしてその彼らの根拠は本質的に’なぜなら私達はそれを書いていないから’というものなのである。通称’エキスパートグループ’はデベロッパたち（通常JSRのサブミッタ）の単なるレビュープロセスをする人以外の何者でもなく、実際開発されるコードにはなんの影響も及ぼさないのである（通常JSRのサブミッタはエキスパートグ ループのヘルプを得るよりもむしろコードのデベロッパを提供することによって、プロセスのIPを全て所有することができる。）。言い換えると、それはあなたがやりたいことをなんでもできるという認可された恵みなのであるが。

他の人々はグーグルがJava開発をリードするべきで(source)、そうでなければJavaは真のパラレル言語によって置き換えられるだろう(source)とコメントしている。しかしながらモジュール性がプラットフォームの崩壊を招く(source)と心配している人々もいる。

上記の掲載がされた同日に、JSR 275（メジャーとユニット）(参考記事)のリーダーの一人であるJean-Marie Dautelle氏は、JCPのコミュニティからフィードバックと質問(source)を引用した。

• Alexander Hristov氏(source)はパブリックディベート、オープンメーリングリストとオープンミーティングを要望した
• Robert Cooper氏はJCPのCはコミュニティを意味していて、またその委員会と企業の利益はコミュニティの利益よりも重要であるように見えたことを指摘した(source)
• Terrence Barr氏は個人と小規模の会社からの参加の必要性と、よりオープンソースな互換性（より少ないNDAや専売特許のコンポーネント）、そしてJSFエキスパートグループメンバシップと公衆の意見の受け入れに対するよりオープンなアプローチを要望した(source)。
• Brendon McLean氏 はJSR296(source)（Hans Muller氏によって運営されている(source)）はJSRが上手くいった良い例と考え(source)、JSRに常にドメインエキスパートを含むことを勧めた。そうすればオープン ソースソリューションがいつも重要な意見を述べることができ、オープン性とコミュニティの参加においてJSRは296のリーダーに従うのである。
• Patrick Wright氏は企業の参加と共に個人と小規模のグループからの参加とSpringとJCPによるApache Commonsのようなデファクトスタンダードの認識を加えた(source)。

またDautelle氏の疑問によってJSR 310（日付のAPI)(source)のリーダーの一人であるStephen Colebourne氏(ブログ・英語)からとても長い返答が得られた(source)。 Colebourneは下記のように問うている。

この疑問はJavaにおけるより広範囲なガバナンスへの問題へと発展する。Javaは今やオープンソースだが、それがどのように動作するかもしくはJCPに影響をもたらすかという明確な説明がないのである。

特にJavaの開発とその将来的な方向を見ているのは一体誰なのだろうか？それはSunの誰かなのだろうか？隠された魔法のプロセス？それとも当たって砕けろなのか？

Colebourne氏はJavaが7に移行するのを誰が決めるのか、どのようにコアライブラリの変化が起こるのか、そしてなぜJSR 277モジュールマネジメントシステムが今されているように扱われているのか、彼はいくつかの問題を提示した。

1. SunはJCPの法的契約を無視している（例：wrt Apache Harmony）(source)。これは信頼性を全て破壊する。
2. JCPはまだ大会社のメンバからの提案書に調印するために存在している。基本的に会社は既存のコードを提出し、エキスパートグループはそれを評価するために存在している。
3. JCPもSunもどちらもJavaの方向性を示していない。Javaがどこに向かっているのかそしてそれが何を成し遂げようとしているのか、それも5年10年単位で、明確なビジョンが必要なのである。
4. JCPが重複しているJSRを排除する予定はない。更に悪いことに、それは成功への道を憚るオプションを許容しているのである。
5. 個人が意見を述べる権利がなさすぎる。彼らは大きな会社を忠実に保つイノベーションと妨害を提供しがちである。

Colebourne氏はまたJavaのこの先5年、10年のビジョンを打ち出すようなアーキテクチャグループ、より大規模でより自主的なJCP Executive Committee、JSRメンバへの支払い、Apache Harmonyへの適切なTCKのようないくつかのソリューションを提案した。提示されたもう一つのオプションはJCPの排除でkernel上で構築され たOSGiベースのモジュールVMとしてのJavaの再定義であった。そうすればベンダーは好きなようにミックスしてマッチすることができ、また市場はその勝者を決定する。Patrick Wright氏はApache-Sun HarmonyのディベートにおいてApacheのみが自身の説を語っている事を指摘していくつかの点において反対している(source)。またWright氏は5 年、10年単位のビジョンがこの移り変わりの速い言語開発の世界においてどれくらいの価値が得られるのかという事を問うている。

Peter Kriens氏(ブログ・英語)もまたディベートにおいてColebourne氏の分析に賛同し、またソリューションには反対し(source)優位に立っていた(source)。Kriens氏はまた新しい疑問を提示した。実装と仕様どちらがより重要なのか？Kriens氏は仕様は異なる条件を狙う複数の実装を許容し、また複数の組織のニーズを均等にすることによって中立性を保ち、遅い標準化のプロセスはソリューションを熟考する時間を与え、知的財産権利に関する問題を処理するのがより簡単である事を指摘した。Dalibor Topic氏(ブログ・英語)はJCPとOSGi両方(source)が大きな会社に支配されすぎているため、その仕様が独占特許のコンポーネントによって邪魔されているが、しかしながらそれは両方とも所有するに値するものであると返答している。Kriens氏はまた大規模な会社のサポートは仕様が成功するのに重要な要素で、Sunが JCPにおいて不均等な統制を行っている一方OSGiのメンバは平等に扱われると返答している。

あなたはどう思うだろうか？

原文はこちらです：http://www.infoq.com/news/2007/12/jcp-debate

• 次へ >