 火曜コラム |
|
Java戦争は歴史を繰り返すか？ （97/10/14）
ついにSunがJavaに関してMicrosoftを提訴した（詳細はPC Watchの後藤氏のコラムを参照して欲しい）。半分予想された展開ではあるが、なぜこんな事になってしまったのだろうかと改めて考えると、「言語標準化」の歴史を単に繰り返しているように感じられてならない。
――Write Once, Run Anywhere.
これは、Javaの特徴を言い表す言葉ではあるが、特に斬新な考えではない。言い換えると「一度書いたプログラムを何度も書き直したくない」という意味となるこの言葉は、「高級言語(*1)」の発想そのままであり、コンピューター業界が長年にわたり目標としてきた事の一つでもある。
だから正直に言えば、Javaが出てきたとき、一体この言語の何がすごいのか私には理解できなかった。中間言語を作ってプラットフォームに依存しないようにするというのは、教科書にでも出てきそうな基本であるし、オブジェクト指向を取り入れるなんてのは、現代においては基本中の基本。さらに、ネットワークプログラミングを指向する以上、安全性に考慮するのも非常にストレートな発想で、それをSand Boxで実現するというのも、教科書的な回答である。
そして、こうした教科書的言語の最大の問題は、常に理想と現実のバランス。つまり、スピードとプラットフォーム非依存のバランス。セキュリティの堅さとプログラミングの自由度のバランス。こういうことは、既に数十年のコンピューター研究の課程において、既に学習済みの事項だったはずだ。
さらに言えば、こうした「標準言語」は常に「独自拡張」と「標準規格の後追い的な拡張」とのいたちごっこであり、最初から標準でまとまっているということはほとんどなかった。また、標準というものが決まったとしても、標準の部分だけでは実用にならず、実際には拡張部分に依存してしまうということもよくある話である。
*1：コンピューターが直接理解する機械語に対して、人間にわかりやすく記述性を向 上させたプログラミング言語のこと。FORTRAN、Pascal、C、C++などすべてが該当する。
そして、パソコン業界の言語マーケットをその初期から牛耳っていたのはMicrosoftである。BASIC、C、C++、RADツール（Visual Basic）。そのどれも、今トップシェアを誇っているのはMicrosoftである。まさに、上記で説明した言語標準化の流れを熟知している企業である。今回のJavaについても、その経験を生かした形の戦略をとっている。
Javaをサポートすると決めたとたん、だれよりも早くマルチプラットフォームでJavaVMを提供し、しかも高速に動作するようにする。そして、開発ツールも同時にVisual J++という形で提供する。デファクトスタンダードこそ、唯一の標準であるというスタンスだ。同時に、独自拡張も忘れていない。AFCやJ/Directなど、Microsoft専用のクラスライブラリを提唱し、ユーザーの囲い込みを行なう。これも、マーケットを取る上での基本戦略だ。
ここまでは、納得のできる展開である。Write Onece, Run Anywhereを提唱しておきながら、SunはMacintosh用のJDK 1.1を遅々として出さず（最近ではSun自身はMac用のJDKは出さないスタンスのようだ）、結局Windows/Macintoshの両方で動くJDK 1.1相当（完全対応ではないが）のVMを最初に出したのはMicrosoftという現実は、Microsoftにしてみればしてやったりといったところだろう。独自拡張の方も、「拡張」しているだけなら問題はない。それを使うかどうかはプログラマーの問題である。Netscape NavigatorやInternet Explorerの拡張されたHTMLタグを利用するかどうかと同じことである。
しかし、ここまでの展開に気をよくしたのか、Microsoftはその後強気になったようだ。9月末のPDCでは、言語としてのJavaは認めるがOSとしてのJavaは認めないと公言している。しかし、実行環境をJavaVMと規定しているJavaでは「OSとしてのJava」を無視して言語だけを取り入れても何の意味もない。今回問題とされた、JNI、Java RMI、JFCといった機能は「無条件で」取り入れるべきだったのではないだろうか？ Javaのスーパーセットの「Microsoft Java」であればデファクトとする戦略は理解できても、Javaの亜流である「Microsoft Java」をデファクトとする戦略には賛成できない。
もちろんMicrosoftにも言い分はあるだろう。今回のような「Javaが満たすべき要件」を第三者の標準化団体ではなくSun中心の企業グループが決めているというのでは、嫌がらせのように「要件」を変更される可能性もある。何よりも、たとえMicrosoftが市場の支持を得た「デファクトスタンダード」を作っても、それを「Javaの標準」として採用してもらえない可能性が大きい。ここでSunが提唱する規格を「Javaの標準」と認めてしまうと、ずるずるSunに引っ張られるのではないかと考えたのかもしれない。
そこで、Sunにもこの際、第三者の標準化団体にJavaの管理を移管するという「太っ腹」なところを見せてもらいたい。やましいところ（つまり、Javaの標準化を通じて市場操作をしたいという気持ち）がないのなら特に問題は無いはずだ。それでもMicrosoftが「標準」を無視するというのなら、Microsoftは亜流のJava「もどき」として誰にも支持されることなく終わってしまうだろう。
さらに個人的には、Sunにはもっといろいろやってもらいたい。まずともかく、Write Once, Run Anywhereを具体化するために、JavaVMをはじめとする様々なプログラムの「実物」を提供してもらいたい。最初に言ったように、Javaは中間言語を採用していたり、ハードウェアへのアクセスを制限していたりする「仕様上の制約」から、C++などのネイティブな言語に対して、スピードや自由度という意味でハンディキャップがある。これらを意識させない、高速なVM、可能性を感じさせるキラーアプリケーション。こうしたものが、登場して初めて「ブームとしてのJava」が「ソリューションとしてのJava」に昇華するだろう。また、そうしたアプリケーションが多数出てくることで、現在のJavaの不備な点も明確になり、どんどん実用度が増すはずだ。
リーダーシップを取りたいのなら、こうした状況を「傍観」するのではなく、自らが積極的にプロダクツを作っていくべきだろう。Javaに関するSunの最大の失敗は、未完成の商品を、さも完成された「標準環境」のように宣伝してしまったことだと思う。「標準」を尊重する割には、互換性のないバージョンアップは頻繁で、デベロッパーは「Run Anywhere」の恩恵を受けることはできない。しかも、将来の標準のために現在のバージョンの機能を使うなといった、デベロッパーにとっては迷惑この上ない指導を平気でやってしまう。「我々が標準である」と声高に主張するより、「これをターゲットに開発すればRun Anywhereを実現できます」というプロダクツ（仕様ではない）を提供した方が説得力がある。少なくとも、どのプラットフォームでもSunが最初にJavaVMをリリースするぐらいの気合いは見せて欲しい。
結局は、実用度が高く、普及度が高いものが勝利するというのは、いままでの「言語」の歴史が証明しているのだから。
[編集長 山下：ken@impress.co.jp]