米持幸寿のJava Issue

20世紀Javaの歴史と21世紀への5つの提案

米持幸寿
日本アイ・ビー・エム
2001/1/16

20世紀のJavaの歴史

　めでたく21世紀の幕が開けた。われらが愛するJavaは、20世紀の終わりに生まれ、非常に広く受け入れられたコンピュータプログラミング言語とその実行／開発環境仕様である。

　プログラミング言語や開発環境にフォーカスして、筆者の独断と偏見によってこの半世紀のコンピュータとJavaの歴史を振り返った後、21世紀にJavaがどうなっていくのか、大胆に予測し、5つの提案をしようと思う。

◆コンピュータの歴史はまだたったの56年◆

　コンピュータの歴史は、IBMが1944年に「Harvard MARK I」を開発したことに始まり、半世紀あまりが過ぎようとしている。たったの半世紀でここまで進化したコンピュータ技術は賞賛に値するだろう。このころのコンピュータは専用機的な使い方が非常に多かった。軍事用、会計用といった具合だ。ノイマンがプログラミング方式の理論を発表したのはこの次の年、1945年であり、われらプログラマーにとっての道が開けたときだ。

　初期のコンピュータのプログラミング言語は当然のことながらマシン語であり、1952年ごろからはアセンブリ言語であった。アセンブリ言語はコンピュータの動作概念を理解するのに非常に有効な言語であり、筆者がどんな新進のプログラマーでも一度はやってみてよいと思うプログラミング言語である。しかも、一度ハンドアセンブルしてみるとよい。きっと、コンピュータの動きやコンパイラの概念が手に取るように分かるようになる。
　アセンブリ言語は当然のことながらアーキテクチャに完全に依存したプログラミング言語であり、移植性は完全にといってよいほどない。システムの概念はインプットとアウトプットで構成され、プログラムは上から下に処理される。このような処理を処理指向などという。

　その後、FORTRAN（1954）、ALGOLやLISP（1958）、COBOL（1959）などが技術計算用／商業用プログラミングにおいて主流の地位を確保する。これらはアーキテクチャにある程度非依存であり、高水準言語と呼ばれた。これらは当時多く使われていたUNIVACやIBMのメインフレームで使われることを考えて作られた言語である。COBOLの時代になると、商業システムにも広くコンピュータが使われるようになったため、開発時の生産性の向上や、見積もりを正確にするために構造化とかデータ指向といった努力がいろいろと行われた。これらをサポートするためにCOBOLは構造化用に仕様が変更されたりした。

　当時のプログラミングは、現代のプログラマーには想像もつかないような世界だった。フローチャートなどの処理の流れ図が出来上がるとコーディング用紙にエンピツでプログラムを書き、紙上でデバッグを行う。ある程度出来上がるとパンチ機を使ってパンチカードにそれを打ち込む。コンパイラにかけるには、このカードの塊（カードデックといった）の前後にジョブ制御カードを付けてカードリーダーにかけ、ジョブを実行する。コンパイル結果はプリンタや別のカードパンチ機に出力されるので、その結果を見てプログラムを修正する。というような気の遠くなるような作業だったのである（懐かしい、といったあなた、年がばれますよ）。

◆UNIXとPCの登場◆

　1968年にUNIXが登場。そして1972年ごろ、UNIXを書き換えるためにC言語が登場する。バイブルといわれる「プログラミング言語Ｃ」の第一版が出版されたのは1982年である。著者カーニハンとリッチーの頭文字をとってK&Rといわれている名著である。
　1974年にBasic言語をビル・ゲイツがパソコン用8080チップに移植したのは有名な話で、これによりパソコンのプログラミング言語はよくも悪くもBasic言語一色になった。Basic言語はその後、ウィンドウシステムの登場によりQuick Basic、Visual Basicなどに発展する。

　1981年にIBM PC、1984年にIBM PC/ATが登場。同時にMS-DOSがひのき舞台に上がる。MS-DOSはアセンブリ言語で出来ていたが、プログラミング環境としてはC言語もBasic言語もあったし、商用にはFORTRANやCOBOLなどのレガシーな言語も対応していた。特に、本格的なDOSアプリケーションを開発する言語として「マクロアセンブラ（MASM）」や「MS-C」などは重要な位置付けを占めていた。このころから、多くのプログラミング開発製品に統合開発環境（IDE）という考え方が広まってくる。エディタ、ソースコード管理、コンパイラ、デバッガなどを統合したプログラミング支援環境である。

◆GUIとオブジェクト指向◆

　米アップルでは1983年のLisaに始まり、1984年Macintoshが登場、PCにGUIという時代がやってくる。続いて、1985年に米IBMと米マイクロソフトが共同でWindowsを開発。1987年 Windows 2.0、1990年 Windows 3.0、1992年 Windows 3.1と発展し、IBM系パソコンにもGUIの時代がやってくる。同時期にインテル系OSで初の32bits OSであるOS/2にも、プレゼンテーションマネージャというGUIが登場している。Linuxが登場したのもこの時期である。1995年のWindows 95の大騒ぎはいまだ記憶に新しい。UNIX上でのX-WindowシステムはMITによって1986年にバージョン1.0が公開されている。

　Macintosh、Windows、OS/2、X-Windowに共通なのは、プログラミング環境として基本的にはC言語を採用したことである。UNIXの影響が大きかったのも確かだが、TCP/IPの普及によりクライアント／サーバ型システムにトポロジーの変化が起こり、C言語プログラマーが爆発的に増加したのである。

　同時に（特に日本国内において）Visual Basicプログラマーが増加した。これはWindows人気もさることながら、部門ごとに開発されるGUIに利用者要望を反映させるための手段の1つであった。

　GUIが登場したことによりオブジェクト指向の機運が高まった。GUIのシステムはオブジェクト指向とよくマッチした。1970年代からSmallTalkは発展を続けてきた。これに続き、いくつかのプログラミング言語がオブジェクト指向の機能を取り入れた。最も広く普及したオブジェクト指向言語であるC++が登場したのはわりと早く1983年である。

◆インターネットとJava◆

　UNIXとともに広まったTCP/IPのネットワークが、インターネットに発展し、商用化されたのは1995年だが、これとほぼ同時に登場したのがJavaである。Javaはいうまでもなく米サン・マイクロシステムズによって発表された仕様であり、インターネットでの利用を強く意識している。Javaをプログラミング言語として見た場合にはC++言語の発展版のように思えるが、Javaがそれまでの言語と最も違うのは、マルチプラットフォームで動かすことを最初から考慮し、実行環境や開発環境などが仕様として存在している点にある。そして、それらが実際に受け入れられ、多くのプラットフォームで移植性の高いプログラミング環境が実現されていることが、高く評価されている一因になっている。つまり、Javaはこれまでのプログラミング言語の集大成といえるのだ。ライブラリ方式、構造化、オブジェクト指向などの思想はすべて盛り込まれているし、ファイルI/O、ネットワーク、RDB、多言語、ウィンドウGUIなどがすべて言語仕様そのものに含まれている。プログラミング言語仕様自体にこのような考慮がなされたものは、実はこれまでなかったのである。

　Javaが登場してからの歴史を簡単に振り返っておこう。

1995/05	Java発表	Sun Developer's Conference
1996/03	JDK 1.0.1 リリース	最初のJava
1996/05	JDK 1.0.2 リリース	発展版
1996/12	JDK 1.1 発表	実用的な発展版
1997/02	JDK 1.1 リリース	文字変換、JavaBeans、新イベントモデル
1998/12	Java2(JDK1.2)リリース	Swing、 Java2D、 Accessibility、 Drag&Drop、 コレクション、 IMF など
2000/07	Java2(JDK1.3)リリース	J2ME、 J2SE、 J2EE ブランド化、HotSpot が標準

　ご覧いただいて分かるように、Javaは発表されて以来、ほぼ毎年新しいバージョンをリリースしてきている。しかし、この2〜3年、言語仕様にはめだった変更がされなくなってきている。

　プログラミング言語仕様の変更はプログラマーを悩ませることは皆さんも実感していることだろう。Javaのプログラミング言語仕様（特に基本ライブラリ）が安定してきたことは望ましいことである。今後も、あまり基本的な部分には変更がされないか、現状を継承した形で発展するようになることを望みたい。

◆サーバサイドJavaとモバイルJava◆

　Javaの利用形態は、当初Javaに期待されていたものとは違う方向へ進んだようだ。Javaが発表された当時期待されていたのは、Windows以外のシステムでのソフトウェア不足の解消とブラウザ上でのクライアントプログラムの実行、つまりアプレットである。しかし、複数の実装やバージョン間での互換性の問題、起動時やGUIのパフォーマンスなどの問題などによりあまり人気が出なかった。C言語やBasic言語で作られたオンラインプログラムの数に比べて現在でもJavaプログラムが圧倒的に少ないのがそれを示している。

　そのためか、別の、より発展的な事態がJavaには起きた。Javaを単にウィンドウシステムのプログラミング言語からより広い世界へ持ち込む動きが出てきたのである。1つはJavaServlet、EJBに代表されるサーバサイドJavaであり、もう1つはKVMやJ2MEに代表されるモバイル機器での利用である。現状ではGUIプログラミングよりもサーバサイドJavaが元気なように見える。

　さて、前世紀の話はこれぐらいにして、今後のJavaがどのような方向へ進んでいくのか、占いつつ筆者の希望を述べてみよう。

21世紀への５つの提言

●提案１　クライアントJavaの復権

　仕様変更が少なくなってきたことによってJavaはいままで以上に受け入れられやすくなってきている。今後はJava2の仕様が流動的でなく、パフォーマンスが改善されてきたことによりGUIの世界にもJavaが帰ってくることだろう。HotSpotによりパフォーマンスが改善されたことも好ましい。

　最近、書店のプログラミング関連書籍のコーナーを見たときにJava2DやSwingといったクライアントJavaの書籍が増えていたのもそれを予感させる。もうすぐ携帯電話にもJavaVMが搭載され、地図が見られるようになる。そこで動くソフトウェアはさまざまな可能性を持っている。それを支えるのはJavaである。つまり、携帯電話やPDAを中心にGUIの世界でのJavaが見直されはじめるのだ。

　さらに、XMLをからめたBtoBの台頭もこれを後押しするだろう。1つにはWeb Servicesがある。Web Servicesでは、ソフトウェアがインターネット上にあるXML（SOAP）ベースのサービスにアクセスに行ける。これはサーバアプリケーションでもよいが、よりドラスティックな変革を起こすのはインターネット上のサービスを直接受けられるクライアントプログラムだ。いままでイントラネットで特定サーバを相手に行うのが当たり前だったクライアント／サーバ型トポロジーをインターネットに持ち出せるのだ。これを作るならJavaしかない。Linuxがクライアントサイドで使われるようになれば、そこにもクライアントJavaのうま味が出てくる。

　そこで、Javaプログラマーの皆さんに提案なのだが、オンラインソフトをJavaでたくさん作っていこうではないか。そして「実行環境：Java2（1.3以降）」などと書くのである。そうすることによって、Javaの認知度がますます上がるはずだ。

　筆者は、自分で撮ったデジカメデータを収録してあるCD-ROMに自作のJava2対応の閲覧ソフトを入れてあるが、OSを選ばずにどこでも再生できるので非常に便利である（まずそれをオンラインで公開すべき？）。今後発売されるマルチメディアCD-ROMやDVD-ROMはこうなってほしいものである。

●提案2　プログラマー不足の解消

　言語が限られていたFORTRANやCOBOLの時代は「どのプログラミング言語を使うか」を考えるのはシステム屋であった。しかし、現在のように選択肢の多い時代にはプログラマーがそれを決める。プログラマーは「自分で使いたい言語」を覚える。オンラインソフトは自然とその言語で作られたものが増える。書籍も「売れるから」その関連書籍が増える。企業系システム構築時にも「プログラマーがたくさん確保できる」言語が自然と使われる。この循環となるのである。現在、Javaプログラマーは必要十分だろうか？

　実は筆者は案外これに関しては楽観視している。いままで幾つかのプロジェクトで「Javaプログラマーがいない」といいながら開発が始まってしまったアプリケーションは、それでもうまく引き継ぎできた。実は、新卒の新入社員がJavaを学校で習ってきた、というのである。各学校教員の皆様、Javaをカリキュラムに取り入れてほしい。そのとき、オブジェクト指向と、ネットワークの知識は必須なのでぜひカリキュラムに含めてほしい。

●提案3　別の言語からJavaバイトコードへ

　皆さんはREXXとか、NetRexxというのをご存じだろうか。IBMメインフレームでVMというOSをやったことのある人なら、REXXというスクリプティング言語を知っているはずだ。これと同じ文法でプログラムを記述すると、Javaバイトコードを吐き出してくれるのがNetRexxである。同様に、SmallTalkのプログラムをJavaバイトコードにコンパイルするコンパイラも存在する。

　まだまだ巷にはCOBOLプログラマーが非常にたくさんいるのを皆さんもお気付きだろう。プログラミング言語は人間の言葉と似たところがあって、一度ある言語に慣れてしまうとなかなか別の言語に移れなくなる。老練なプログラマーならなおさらである（筆者のように半端者はすぐに浮気可能）。そこで、開発環境ソフトを作っているメーカーに提案がある。オブジェクト分析（インターフェイス、クラス、メソッドなどの定義）が終わった時点でJavaのスケルトンが書き出されたら、「メソッドの内部ロジックはCOBOLで記述してよし」というコンパイラを出してはいかがだろうか。これで、Javaの開発案件にCOBOLプログラマーという貴重な人材を適用することが可能になる。Javaは中間コードなのだから、文法が少しくらい違っても大丈夫なはずである。

●提案4　難しさに対する代償

　「Java案件は難しくてプログラマーが不足しているうえに短期間で低料金でやらなければならない」という矛盾にでくわしたことはないだろうか。

　Webアプリケーションを作るなら「Perl+CGI」で作った方が楽だし、見積もりは多めに出せる。その分、実入りも多くてゆっくり作業できる。だからPerl+CGIにした、なんてのはどう考えてもわれわれJava陣営にとってなんとも旗色が悪い。おまけに、Javaをやっている人をはた目に見ている人が「Javaは大変そうだからやらない」なんていい出すと困ってしまう。

　難しい高度なテクノロジを使って、短期間で、一定の機能を実現し、将来性もあるシステムを作るのだから、その分割増料金をいただきたいものである。そういう「テクノロジ料金」とか、「成果物の価値料金」みたいなのを考えてくれる人はいないだろうか。

●提案5　本番系デバッグ機能の充実

　UNIXやPCの台頭によって、プログラムのデバッグは「再現＋実行時デバッガ」が当たり前になった。「そんなのできて当たり前じゃん、できなきゃ困るよ」という人、実は、これでは足りないのだ。

　長い間、基幹業務を支え続けているメインフレームOSには「問題が起きたら、起きた後に資料を取得して分析することで、ある程度デバッグが可能」という機能が豊富に付いている。デバッガで行うような実行位置の追跡調査（トレースという）も、処理中にオン／オフが可能だ。これはデバッガにかけるのではない。システムは常にデバッガの上で動いているのだ。システムが異常終了する場合にも、分析に十分に耐えられるメモリダンプが取得される。取得がうまくいかないケースの方が少ない。システムがハングアップしたときでさえも、任意にメモリダンプを取得することができる。しかも、そのトラブルが二度と再現しないような場合にも分析が可能だ。

　このような機能は「絶対止められない」ような基幹業務システムには必須の要件であるがJavaにはこのような機能はない。トラブルが起きたら「再現して」デバッガにかければ分かる、なんてのは、基幹業務システムには通用しないのである。JVMがハングアップしたとき、それがデッドロック状態なのか、ループしているのか、メモリダンプを取得して分析したり、実行中になんらかのアクションで追跡できるような機能が求められる。

　エンタープライズシステムに使われるJavaVMにもこのような問題判別機能が必要不可欠であると筆者は考えている。各メーカーではぜひこれに挑戦していただきたい。

　ということで、21世紀早々、筆者のとても自分勝手な希望を書き並べてみた。皆さんもさまざまな希望や期待をいだいていることだろう。そんなときはぜひそれを掲示板に公開していただきたい。

Index

第1回 ソフトウェアの部品化は現実になる？(2000/12/19) 第2回 Javaの歴史と21世紀への5つの提言(2001/1/16) 第3回 Javaの開発にUMLは必要？(2001/3/2) 第4回 ここはJavaプログラマの天国？(2001/4/24) 第5回 Javaコンソーシアムが卒業式 (2001/7/6) 第6回 EJB部品の流通をめぐる動き(2001/12/6) 第7回 開発ツールのプラットフォーム“エクリプス”とは？ （2002/1/17)

プロフィール

米持幸寿 1987年、日本アイ・ビー・エム入社。 ＩＢＭメインフレームOSであるVSE、およびVM関連ソフトウェアプロダクト の保守、 システム無人化ソフトウェア開発を手がける。現在はJava、XML、EJBに関わるプロモーション活動を行っている。 [筆者執筆記事一覧] ・JavaとXMLはなぜ仲良し？ ・Java Servlet徹底解説(JSPとの連携) ・Java Servlet徹底解説(EJBとの連携)

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）