編集部からのお知らせ
「ZDNet Japan Summit」参加登録受付中! 
新着記事集:「負荷分散」

サンは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 記事を毎朝メールでまとめ読み(登録無料)

特集

CIO

モバイル

セキュリティ

スペシャル

ホワイトペーパー

新着

ランキング

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

    Google Cloudセキュリティ基盤ガイド、設計から運用までのポイントを網羅

  2. セキュリティ

    仮想化・自動化を活用して次世代データセンターを構築したJR東日本情報システム

  3. ビジネスアプリケーション

    スモールスタート思考で業務を改善! 「社内DX」推進のためのキホンを知る

  4. セキュリティ

    Emotetへの感染を導く攻撃メールが多数報告!侵入を前提に対応するEDRの導入が有力な解決策に

  5. セキュリティ

    偽装ウイルスを見抜けず水際対策の重要性を痛感!竹中工務店が実施した2万台のPCを守る方法とは

NEWSLETTERS

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

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

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