編集部からのお知らせ
解説集:台頭するロボット市場のいま
解説集:データ活用で考えるデータの選び方

サンはJavaの何をオープンソース化したのか(2/3)

David Berlind(ZDNet.com)

2005-07-05 19:12

 まずは、Javaプラットフォームとの互換性が認定された製品の話をしよう。IBMやBEAのようなBig Java準拠のソフトウェアを開発する企業の場合、製品を市場で通用させるためにはJ2EEバージョン1.4との互換性を確保しなければならない。バージョン番号が違えば、対応するJSRも変わる。JSR 151(J2EE 1.4)の前には、JSR 58(J2EE 1.3)があった。私が理解するところでは、J2EE 1.4はJ2EEエディションの最後のバージョンになる。Sunは今後のリリースからJ2EEの「2」を取り払って、「Java Enterprise Edition」という名称を使っていくのである。J2EE 1.4の後継で、以前J2EE 1.5と呼ばれていたバージョンは、単にJava EE 5(JSR 244)と呼ばれるようになる。Javaアプリケーションサーバのベンダーが現在J2EE 1.4(JSR 151)に焦点を合わせていることからも分かるように、Java EE 5の仕様はまだ最終的に固まっていない。固まっていたら、ベンダーはみんなそちらの仕様に準拠した製品を作ることに奔走しているはずだ。JSR 244のサイトによると、Java EE 5は「2005年の後半にリリースされる予定」だそうだ。そんな細かいことはどうでもいいじゃないか、と思う人もいるかもしれない。

 さて、ここで本題。SunがJavaOneで何を発表したかである。SunはJavaそのものをオープンソース化したわけではない。Sunがオープンソースにしたのは、まだ最終確定されていないJava EE 5の実装である。現在出回っているJ2EE 1.4の実装ではない。もちろん、J2EE、あるいはJava EE実装の核を成すJREでもない。JREこそ間違いなくIBMがオープンソース化を強く望んでいるものだ。

 このことがどういう結果をもたらすか。まず、面白いことになっていくのは間違いない。たとえば、以前にもオープンソース化されたソースコードが土台になってデファクトスタンダードが確立したケースがあるように、SunがJava EE 5の「参照実装」をオープンソース化することによって、この参照実装がJava EE 5の舞台の中心になっていくかもしれない。(JBOSSのCEO、Marc Fleuryに尋ねたわけではないが)JBOSSを例に挙げるなら、多くのリソースを注ぎ込んで、あえて独自のJava EE 5実装を開発するのは得策だろうか。そうではなく、Sunがオープンソース化したものを土台にしてそれに独自の機能を追加し、サポートサービスを提供する方がいいのではないか。あるいは、小さなソフトウェア会社がソリューションの一部としてJava EE 5の実装を再配布したい場合はどうなるのだろう。他の3つのオープンソース実装(JBOSS、JOnAS、ApacheのGeronimo)のどれかを使うべきだろうか、それとも(事実であるかないかには関わらず)「至上のもの」と見なされるSunの参照実装を使うべきだろうか。なんと言っても、後者はJavaの開発企業が作ったものだし、Sunのエンジニアたちは世界でも指折りの優秀な人たちだ。Sunのエンジニアのほうが、IBMのエンジニアやJOnASやJBOSSを開発しているエンジニアたちよりも優れていると言っているわけではない。だが、最終的な製品にそれほどはっきりした差が現れるだろうか(差が見られるのは、Java EEベンダーがBig Javaのクラスタやグリッドを構築したりするなど、特殊なケースのみだろう)。

 重要なことを省略していると思う人がいるといけないので、さらにもう1つ。Sunが参照実装をオープンソース化したからといって、突然、Java EEソリューションを配布するソフトウェアベンダーが雨後のたけのこのように出てくるわけではない。ここにも1つ状況を複雑にしている要素がある。たとえば、私がDavid's Softwareという会社を設立して、Sunのオープンソース化されたJava EE 5の実装を(オープンソースであるにも関わらず)まったく変更せずに配布し始めたとしよう。互換認定を受けるにはかなりのコストがかかるが、私の場合、Sunはこのプロセスを免除してくれるかもしれない。(コードを変更しない限り)その製品はすでに認定されていることになるので、新たに認定を受ける必要はないはずだ。Sunが再認定を要求するなら、それは彼らの判断の誤りだ。

 認定を受けても、それですべてが終わったわけではない。たとえば、認定テストにお金がかかるだけでなく、たいていの場合、Javaの商標をソフトウェアに付けるためのコストも発生する(中には、このマークが付いていることにこだわるユーザーもいる)。これはあまり知られていないこと(これを汚い秘密という人もいる)だが、販売資料やウェブサイト、ソフトウェアでJavaの商標を使用するには、Sunのライセンスを受ける必要がある。他の人が作った、すでに認定されているコードを利用する者も例外ではない。例を挙げよう。ObjectWebコンソーシアムはつい最近、JOnASでJ2EE 1.4互換の認定を受けた。Javaの商標のライセンスも確保した。ところが、JOnASの含まれるアプリケーションサーバを提供するRed Hatは、J2EE、あるいはJavaアプリケーションサーバを売っていると言うことはできない。Red Hatの文書を見てみればわかる。絶対に商標権を侵害しないように、すべての言い回しが慎重に考えぬかれている。Red Hatは、「Javaアプリケーションを実行するためのアプリケーションサーバ」と言うことはできるが、「わが社はJ2EE 1.4準拠のアプリケーションサーバを提供します」とは言えない。そんなことをしようものなら、目を光らせているSunの弁護士が訴状を突きつけてくることは間違いない。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

Special PR

特集

CIO

セキュリティ

スペシャル

ホワイトペーパー

新着

ランキング

  1. クラウドコンピューティング

    AI導入に立ちはだかる「データ」「複雑さ」「コスト」「人材」の壁をどう乗り切ればいいのか?

  2. クラウドコンピューティング

    【IDC調査】2026年には75%のアプリがAIを実装!導入で遅れた企業はどう“逆転”すべきか?

  3. 運用管理

    経産省調査で明らかに:未だにレガシーシステムを抱える企業が8割!オープン化でよくある課題とは?

  4. 運用管理

    AWS東京リージョンの大規模障害に学ぶ、パブリッククラウド上のシステムの迅速な復旧方法

  5. windows-server

    【ユースケース】ソフトウェア開発にDell EMCインフラ+コンテナを使うメリット

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNet Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]