［要約］
Javaは、一度書けばどこででも動くという特性があり、動作プラットフォーム別にプログラムを書く必要がないということにより注目されている。
しかし、その移植先をデスクトップコンピューターのみと考えている場合にはメリットが少なく、むしろオフコンや汎用機をも視野に入れたときに効果が飛躍的に拡大するものと思われる。
というのは、ＰＣで開発し、ＰＣで動作させるべく考えられていたアプリケーションを、当初の見込みとは異なり、より信頼性とスケーラビリティのあるプラットフォームで動かすニーズが生ずることが起こりうるからだ。そのアプリケーションが対象としている業務が予想を超えて拡大した場合、このような対応ができれば非常にありがたい。
このニーズは現時点では解決方法がないために顕在化することはないがマルチプラットフォームをうたうJavaの普及によって、今後増大してくると思われる。
とはいうもののJavaのよって立つプログラミングパラダイムであるオブジェクト指向は、グラフィカルユーザーインターフェースを作る場合にプログラミングの手間を省く手段としてとらえられているのが一般的であり、基幹業務に不可欠な伝統的なバッチ処理に適用することはあまり考えられてこなかった。しかし、オブジェクト指向をバッチ業務に適用した場合のメリットも大きい。
ユーザーインターフェースのプログラミングを簡略化してきたのがオブジェクト指向の「継承」という特性であるとするならば、バッチ処理に有効なのは「多態性」という特性である。これを活用すればプログラムのメインルーチンは簡素化でき修正の影響範囲も局所化される。
しかし、オブジェクト指向を使ったJavaでバッチ処理を行ったという事例は皆無といってよく、さらにJavaは実行速度に難があるというのが定説である。
そこで、レコードを種類別に集計し、合計表を出力するという典型的なバッチ処理プログラムをJavaとPascal,、VisualBasicを使って作成し、処理速度を比較した。
その結果、JavaはネイティブコンパイラであるPascalの1.5倍程度の処理時間を必要とするに留まり、VisualBasicの4.5倍を大幅に上回った。また、100万件までのデータを処理させたが、大量データ処理時にもパフォーマンスは低下しなかった。
以上より、今後Javaのマルチプラットフォーム化がさらに進めば、上記のようなニーズがどんどん発生し、強力なシステム化ソリューションの手段になる可能性があると思われる。
- はじめに
- 業務プラットフォームとしての大型汎用機
- 汎用機の優位性
- 汎用機におけるプログラミング環境の遅れ
- Javaのメリット〜垂直的ポータビリティについて
- 水平的ポータビリティのメリットは少ない
- 垂直的ポータビリティの重要性
- オブジェクト指向をバッチ処理に適用
- バッチ処理でのオブジェクト指向の優位点
- バッチ処理に有利な多態性
- Javaのバッチ処理、処理速度検証
- テストとその結果
- 比較対象言語
- 処理内容
- テスト環境
- テスト結果
- 終わりに
オブジェクト指向は、グラフィカルユーザーインターフェース（ＧＵＩ）を実現するために必要な大量のプログラミングの手間を軽減してくれるものとして注目を集めていた。
Javaは、一度プログラムを組めば、ＯＳに関係なく動作するという特徴があるため、ソフトハウスが同一機能のアプリケーションをＯＳごとに書き直す手間を省く手段として、まず注目を集めた。
しかしながら、ＧＵＩは、画面部品を貼りつけることによりユーザーインターフェースが完成してゆくコンポーネントウェアによって開発されるのが主流となったし、異なるＯＳで動くという特性もデスクトップＯＳをMicrosoftがほぼ独占したため、事実上意味を持たなくなってきている。
そこで、現在Javaはそのネットワークとの親和性が注目されて、ここ一年ほどはサーバー部分のアプリケーション開発言語としての道が模索されている状態である。
しかし、視点を変えてみると、オブジェクト指向は伝統的なバッチ処理のシステムを作る場合においても大きな効果を持つと思われる。また、Javaの移植性はソフトハウスがパッケージソフトを作る場合ではなく、むしろ各ユーザー企業が独自のカスタムアプリケーションを組む場合にこそ効果が大きいのではないかと思われる。
本論では、まず、汎用機を業務アプリケーションのプラットフォームとして再評価し、続いてJavaの持つ、柔軟な移植性が、業務アプリケーションを作成する場合に効果を発揮することを示す。
続いて、オブジェクト指向を、伝統的バッチ処理に適用した場合のメリットを論ずる。
最後に、Javaのデメリットと考えられている実行速度の問題が、実際どの程度のものなのか、Javaと他のオブジェクト指向言語で、同じ設計のプログラムを組むことによって検証する。
ＬＡＮによるダウンサイジングが提唱された当時、パーソナルコンピューターのコストパフォーマンスの優位性が喧伝された。曰く、大型汎用機に比べてＣＰＵの価格は1/200、ディスクは1/20、メモリは1/60。この数字は９２年のものだが現時点での比率はもっと大きくなっていると思われる。このことから、汎用機をナウマン象にたとえ、ごく一部の特殊用途を除いて西暦２０００年には死滅するという無邪気な予測をする人もいたわけである。
このように、パソコンのハードウェアはコストパフォーマンスを上昇させてきたが、パソコンをソフトウェア込みで見たトータルなコストパフォーマンスはさほどの変化がない。オペレーションシステムやアプリケーションが肥大化し、ハードウェアのコストパフォーマンス上昇分を吸収してしまったからである。
その一方でオペレーションシステムの性能は、使いやすさを追求するあまりであろうか、信頼性の面からは逆に下がってしまった。かといって、汎用機のオペレーティングシステムの特徴である高度なデータセットの管理、タスク分割といった機能は、依然として切り捨てられたままであるため、大量データのハンドリングや集中処理は相変わらず苦手である。そのため汎用機の多重処理を代替するためには、独立したクライアント＝サーバーシステムを多数立ち上げざるを得なくなり、全体の管理や、データ交換などの部分で負担を増加させた。ダウンサイジングといいながら、気がつくと並んだサーバー群は汎用機１台の設置面積を超えるスペースを占めていたという笑い話もある。
これらの管理を自動化したり、セキュリティを高めるために新たなソフトを導入するという動きが見られるが、これは確実にコスト高につながる。その結果、現在では信頼性の要求される大規模システムの部分については汎用機や、オフコンの方が適しているという見直し論がでてくるようになった。９８年のＰＣサーバーの売上高伸び率が前年比８％にとどまり、９７年の４２％を大きく下回っているのも、こういった傾向を反映してのことであろう。（ＩＤＧによる調査速報値）
このように業務プラットフォームとしての汎用機は徐々に復権してきたが、アプリケーションを作り込むプログラマとしてみた場合、汎用機の開発環境は苦痛であるといってもよかろう。ＰＣやＷＳではＧＵＩベースの使いやすい開発ツールが安価に数多く存在するにもかかわらず、汎用機では旧態依然のラインコマンドのエディタとＪＣＬによるコンパイル、リストを見てのデバッグを要求される。テスト環境の作成も比較にならないほど大変であり、多くの開発者が一台の汎用機を共有しているが故に、同一のマシンで他の開発が進んでいる場合には、どうにも動きがとれなくなることが多々ある。もちろん汎用機の開発ツールも進歩しているのであろうが、一般に価格が高く、すんなりと導入するわけにはいかない。これを思うとき、安く優れたＰＣの開発環境でプログラムを書き、汎用機で動かせればさぞ簡単に、素早い開発ができるだろうとプログラマは切望するようになるわけだ。
こういった話は、空想することすら許されないような状況であったが、共通のバイトコードが各種プラットフォームで動作するという触れ込みのJavaのおかげで実現の可能性を帯びてきた。とりわけ、サンフランシスコ＝プロジェクトのようにデスクトップからオフコン、汎用機までJavaで統合しようという計画は我々にそういった希望を与えるものである。そして、このように「小回りが利き、安価な」ＰＣで開発したプログラムを「信頼性が高く、大量データ処理に適した」汎用機で動かすということがやがて主流となる時代が到来するような予感さえしてくるのである。
Javaを設計した会社が、ＵＮＩＸ専業メーカーであるため、ほとんどの人はJavaのポータビリティというとき、水平的なプラットフォーム間でのポータビリティしか想定していないように思われる。これは、マルチプラットフォームといっても、Windowsで動くアプリケーションがMacOSでも、OS/2でも動くといったようにパソコン同士での互換性しか注目されてこなかったという意味である。Solarisでも動く、といっても、実際の用途はデスクトップで使うアプリケーションの範囲に留まるものであった。
ところが、実際のところこういった水平的ポータビリティはカスタムアプリケーションを組むコンピューターのユーザーたる企業の立場としてみればさほどのメリットではない。というのはこれらの企業がシステムを開発する場合は、予め動作プラットフォームが決定されている場合が殆どであるからだ。とりわけ、ＰＣ上で実装するアプリケーションの場合は、事実上Microsoft Windowsが標準となっている以上、あとでそれをMacOSで動かしたいというニーズが出てくる場合はほとんど考えられない。さらに、パッケージソフトを作るソフトハウスにとってもJavaを採用するのは抵抗があるだろう。逆コンパイルが容易で、ソースコードを公開するに等しいからだ。
そして、Windowsに限らずJavaアプリケーションの実行環境を設定するのは決して楽なことではないのだ。コンピューター１台ごとに設定を変更し、独自作成のモジュール群をコピーしていかなければならない。さらに、作成モジュール内部のバージョン管理も頭の痛い問題である。そういった意味では、JavaのポータビリティがＴＣＯを削減するというわけではないといえる。
もちろんJavaアプリケーションをあきらめ、アプレットとしてイントラネットで実行時に配布するという手段はあるが、立ち上げにかかる時間が耐えきれないほど遅くなるのが通常であるし、ローカルファイルにアクセスできないなどの動作上の制限も多い。
更には、Javaのメリットといわれる生産性の高さも、複雑なクラスライブラリを使いこなせて初めて得られるものである。また、オブジェクト指向専用言語としての特性が、このクラスライブラリの使用を強制することを考えると、Javaの修得期間はＣ言語の３倍程度という意見もある。（参考文献[2]pp.ii）これらを考えあわせれば、その生産性のメリットを享受するのは必ずしも容易なことではなさそうである。動作プラットフォームがWindowsに限られるのであれば、Ｃ++BuilderのようなRADツールを採用する方が、トータルでは高い生産性を実現することができるのではなかろうか。
しかし、現実のビジネス上のニーズはむしろプラットフォーム間の垂直的なポータビリティにあると考えることができよう。つまり、ＰＣで稼働するプログラムがＵＮＩＸサーバーでも動き,、オフコンでも動き、さらにはメインフレームでも動作するようにしたいというニーズが今後台頭してくると思われるのだ。
それは、企業がカスタムアプリケーションを組み上げたとき、当初想定していた以外のプラットフォームで動作させたいという要求は認識されている以上に多いと思われるからだ。
例えば、銀行が新しい金融商品の取り扱いを開始することがある。金融ビッグバンの流れの中で生まれるデリバティブ商品の寿命は短いと考えられるため、それらの管理システムはまずパソコン上で作られる（参考文献[3]）。ハード、ソフトのコストが安いからだ。また新しい商品の取り扱いが許可されることがあるが、最近の傾向として発表から実際の取り扱い可能日までの時間は極端に短くなっている。そうなるとその商品の管理システムはパソコンで開発しなければ間に合わない。生産性の高い開発ツールと小回りの利く開発環境が必要とされるからだ。
もちろん、それらのシステムは開発プラットフォームであるパソコン上で動くことになる。しかし、その後の金融情勢によっては一時的なものであったはずの新商品の寿命が思いのほか長くなって、発行件数が増加したり、銀行の戦略的な重要性が増すといった事態が生じることもある。このような場合はパソコンで作った商品管理システムをより高いスケーラビリティや信頼性を持つプラットフォームで運用したいというニーズが当然のように発生すると思われる。
こういったとき、せっかく作った発行管理システムがオフコンや汎用機といった上位プラットフォームで動かないとすれば、既に作ったアプリケーションは廃棄され、新たに開発が必要となる。
また、個別業務ごとにクライアント／サーバーシステムを構築していたが、それらの保有する数値を、リアルタイムに集計して把握したいというニーズが生じてくる場合がある。このようなときは、サーバーを高性能のものに一本化して、その共通化されたプラットフォームの上に各アプリケーションを移植してゆくのが効率がよいと思われるが、個々の業務アプリケーションがそれぞれのプラットフォームに依存していた場合は、そういった統合が困難になる。
結局、時限を区切って、ファイル転送を行い、その都度集計するという方法で、なんとかニーズを満たすという解決策がとられることになるだろうが、このときに「各システムが、そのまま大型サーバーで動いてくれれば」と思わないシステム担当者はいないであろう。
金融ビッグバンによって、次々と新規に業務が生まれ、それらの比重がどんどん変化してゆく、同時にリアルタイムのリスク管理の必要性が高まる、とはいうものの投資額は抑えてゆかねばならない。こういう昨今の情勢において、移植性の高さを念頭に置いてアプリケーションを開発してゆくことは、企業内の基幹部分を担うカスタムアプリケーションについてこそ、必要とされるべきものである。これまでは、アプリケーションの垂直的な移植性を実現する手段が無かったため、こういった要求は表に出ることはなかったが、Javaが登場した今日、これらの潜在的ニーズが一挙に噴出することが予想される。
しかしながら、ここで考えておかなければならないことがある。ＵＮＩＸは、本来タイムシェアリング処理のためのプラットフォームである。つまり、汎用機のオンライン処理部分のみを抜き出したものといってもよい。このようなアーキテクチャーから生まれたJavaが汎用機流のバッチ処理に適用できるか多少の疑問が残る。そもそも、Javaの依って立つプログラミングパラダイムであるオブジェクト指向そのものが、フィヨルド内の船の航行をシミュレートするために作られたアーキテクチャーであり、バッチ処理のことにはあまり気を使われていないといえるのだ。
Javaは動くホームページが作れるという謳い文句で普及してきた言語であるためどうしてもグラフィックを中心とした分野に専門であるという印象が強い。またオブジェクト指向専用言語であり、このオブジェクト指向自体、グラフィックと緊密な関係を持っていると考えられている。
例えば、支配的なオブジェクト指向開発言語となったＣ++の設計者であるストラウストラップ氏は次のように述べている。「対話型グラフィックスのような分野では、オブジェクト指向プログラミングに向かって巨大な視野が開けている。古典的な算術型とそれらに基づく計算といった他の分野ではデータ抽象を超えるような視野はほとんど現れずオブジェクト指向プログラミングをサポートするための機能は必要ないように見える。」（参考文献[4]pp.29） 確かに、ＧＵＩを実現するにあたってオブジェクト指向の果たす役割は大きく、それなくしてはとても満足な生産性が得られないのも事実である。Microsoft
Windows上で空のウィンドウを開くプログラムを直接Ｃで書くとすると、それだけで約90行のコーディングが必要になるのだ。
しかし、だからといって伝統的なバッチ処理にオブジェクト指向を適用してもメリットがほとんどないというわけではない。オブジェクト指向は、プログラムを分割する技法でもあるから、プログラムの見通しを良くするのに有効である。また保守性を高めるのにも役立つと思われる。とりわけ多態性を活用した場合のメリットは大きい。
簡単に言うとこう主張することができるだろう。「ＧＵＩにおけるオブジェクト志向のメリットは継承によるものであったが、バッチ処理におけるメリットは多態性によってもたらされる。」
オブジェクト指向のプログラミングにおいては、データとそれを取り扱う関数が一体化されている。これを言い換えると、データが自分の振るまい方を知っているということである。つまり、プログラムが現在処理しようとしているオブジェクトは、自分自身、自律的に処理されうるため、プログラムの中心部分は、オブジェクトを呼び出すだけのシンプルなものになる。
ここで、オブジェクトの派生の方法と、内部処理の呼び出し方を定型化された手法でプログラミングすれば、異なったオブジェクトに対してでも、同一名称の内部処理を呼び出すことによって、おのおののクラスにそれぞれの振る舞いをさせることが可能となる。これが、バッチ処理に有効ではないかと考えられる多態性である。
この技法を応用すれば、ファイルやデータベースからレコードを読み込み、各レコート種別ごとに場合分けをして、演算、集計するといった処理が極めて簡単になる。読み込んだレコード種別ごとにそれぞれの種類のオブジェクトを生成してゆけば、メインルーチンでは、ただ現在読み込んでいるオブジェクトに同じ命令を出し続けるだけで済むわけだ。
例えば、運用資産の明細のファイルがあり、資産の種類が債券投資、貸出金、株式投資といった具合に分かれており、さらにその種類ごとに処理内容が異なるといったものがあるとする。そこから得られる総金融収益を算出し、集計する処理を行うとしよう。多態性を使ったオブジェクト指向プログラミングでは、運用資産というクラスをます作成し、そこでは収益算出という名前だけの関数を書けばよい。そして、そのクラスから各資産種類のクラスを派生させて、それらサブクラスのレベルで収益算出の関数をコーディングすればよい。そうしておけばメインルーチンは、おのおののレコードを読み込みこむ時に運用資産クラスを通して、各資産種類のオブジェクトを生成し、レコード種別にとらわれることなくひたすら運用資産クラスの収益算出関数をコールし続けてゆくだけになる。
ここで、新しい金融資産が追加になったとしても、新しくクラスを派生させ、レコード読み込みのオブジェクト生成部分をいじるだけで済んでしまうため、修正が局所化、定型化さる。（ストリームを活用すればオブジェクト生成部分の修正すら不要になる。）
また、個別の金融資産の収益計算方法が変更になったとしても、修正対象は該当クラスのみに局所化されるというメリットも大きいと思われる。これはとりわけ例外的な個別処理を必要とするレコードを扱うプログラムにおいて有効性が大きい。メンテナンスの時に見落としやすい個別処理であっても、きちんとオブジェクト指向で設計されていた場合は、はっきり別のクラスとして切り出されるからである。つまり、修正に先立つ影響調査の精度が必然的に上がることになる。
とはいうものの、バッチ処理分野へのオブジェクト指向への適用はほとんど見ることができない。そこで、自分では９７年初頭からオブジェクト指向に拡張されたPascalを用いてオブジェクト指向によるバッチ処理プログラムをいくつか作成してノウハウを蓄積してきた。
その結果、ファイルを読み込んで、ファイルごとにそれぞれの処理をして、結果を出力するという典型的なバッチ処理をプログラミングした場合、オブジェクト指向で設計したほうがむしろわかりやすいとさえ思えるようになった。処理とクラスが１対１に対応するため、ロジックが追いやすく、変更も簡単なのである。
例えば、国内最大手のパソコン通信であるNifty-Serveで得た各種サービスの巡回記録を、モバイルツールで読みやすくするために、HTML形式にコンバートするというプログラムを作成したときは、Nifty-Serve内のサービス呼び出しの階層と、プログラム内のクラス呼び出しの階層をまったく一致させることができた。ちなみにこのプログラムをオンラインソフトとしてプログラム仕様と共に公開したところ、雑誌や書籍にも転載されるなど一定の評価を得ることができた。
このようにオブジェクト指向をバッチ処理に適用することは十分可能なばかりでなく、むしろ適しているとさえ言えるのだ。
しかし、垂直的ポータビリティを実現するためにはJavaで書かなくてはならない。前述のとおり、Javaは元々グラフィックの為の言語として紹介されたがゆえに、レコード処理を繰り返すといった伝統的バッチ処理に向いているかについてはなんとも言えない。また、インタプリタ言語であることから処理速度的には厳しいものがあると思われる。また、オブジェクトを作りっぱなしにできるというプログラマにとってありがたい機能も、大量データ処理という目的のためにはマイナスに働くことが懸念される。ユーザー数に対するスケーラビリティはあるが、データ量に対するスケーラビリティに劣るインターネットで育てられたJavaにとって、大量データの処理で満足な速度が得られるかは気にかけておかねばならない。
しかし、実際にJavaのパフォーマンスを従来型言語とと比較した例は少なく、特にバッチ処理の実プログラムでのパフォーマンス比較というものは見あたらない。
そこで、JavaとネイティブコンパイラであるPascalとパフォーマンスを比較することとした。このとき同じI社がほぼ同じ時期に発表したプログラミングツールを用い、アルゴリズムも同一設計で同一のデータ型を処理するようにし、極力条件を統一した。
プログラムの素材としては、テキストファイルを読み込んで、内容を集計し、計表を出力するというバッチの最も基本的なものである。ただし、パフォーマンス測定が主目的であるため、プログラム外部での時間がかかる印刷処理を避け、結果計表はコンソール画面に出力するものとした。処理内容は、銀行の資産の明細ファイルを読み込んで、ＢＩＳリスクアセットを算出し、種類別に集計して合計を出すというポピュラーなものとした。
ネイティブコンパイラを備えたオブジェクト指向言語としてObjectPascalを選択。参考にWindows上のポピュラーな開発言語であるVisualBasicでも同様のプログラムを作成した。 JavaとPascalについては、設計内容をオブジェクト指向的に一致させた（図１）。VisualBasicについては、伝統的な構造化プログラミングの設計を使用した。
３言語とも、同一の処理を行い、同一のデータを処理する。
処理内容は、レコードを１件ずつ読み込み、レコード区分に従って規定の比率を掛けて、区分別に合計を出すという典型的なバッチのもの。模擬的にBISリスクアセット算出をイメージした。（データは乱数を使って作成した架空の物。）
- ＯＳ WindowsNT WorkStation4.0日本語版ServicePack2適用
- ＣＰＵ Intel PentiumII/350MHz
- メモリ メインメモリ64MB
- Javaのバージョンは1.1.6を使用した
３回実行した平均値を集計。
各実行の間には、無関係なファイルをコピーし、キャッシュメモリをクリア。
結果は表１のようになった。
表１、言語別処理時間一覧（単位は秒）
| 件数＼言語 |
Pascal |
Java |
Visual Basic |
| 5,000 |
0.14 |
1.64 |
1.18 |
| 10,000 |
0.22 |
1.47 |
2.01 |
| 20,000 |
1.12 |
2.60 |
4.31 |
| 50,000 |
3.06 |
4.62 |
10.97 |
| 100,000 |
5.96 |
6.49 |
21.01 |
| 200,000 |
7.39 |
9.70 |
40.91 |
| 500,000 |
14.31 |
22.51 |
異常終了 |
| 1,000,000 |
27.61 |
42.66 |
異常終了 |
Javaの実行時間は、Pascalの1.5倍程度。4.5倍となるVisualBasicの速度を大幅に上回る。
また件数を横軸に、処理時間を縦軸としてグラフを作成した（図２）。Visual
Basicが大量データ処理時に異常終了したため、表示は１０万件までで行っている。
処理件数が大量となっても必要な実行時間はそれに比例しており、懸念された大量処理時のパフォーマンス低下は起こっていないことがわかる。実際、処理件数と処理時間の相関係数を計算すると0.999386と極めて高く、Pascalの0.992843をむしろ上回っている。
これは、連続的に定型のデータを処理するバッチ処理では、その度ごとにメモリー上に展開されているクラスの数がほとんど変動しないので、Javaのパフォーマンスネックと言われている自動ガベージコレクションが悪影響を与えていないためであると考えられる。
実際の処理状態の画面は、図３の通りである。
図３ 各プログラム実行結果（左：Visual
Basic、右上：Pascal、右下：Java）
以上より、Javaの弱点といわれた処理速度の遅さは、大きな問題となるほどのものではないことが判明した。実は、同様のテストをJavaのバージョンを1.02として行ったところPascalに比べて７倍以上の処理時間が必要であったが、バージョン1.1.6によって１．５倍程度に収まるようになった。Javaはまだ発展中の言語であり、バージョンアップによって処理速度が飛躍的に向上しており「Javaは遅い」という観念が見直しを迫られていると言えそうだ。実際、オブジェクトの生成を極端に押さえてアプリケーションを構築すると、同一ロジックのC++よりも早くなるという実験結果もある。（参考文献[5]）
また、同じプログラムをより低速のCPU(AMD k6/225)で動作させた場合と比べて、Javaの処理時間はPascal比短くなる（速くなる）傾向があった。つまり、Javaはネットワークを意識してコンパクトなサイズに収まるよう設計されているので、プログラム全体がメインメモリ（ないしキャッシュメモリ）に展開される確率が高く、CPU速度向上の恩恵を受けやすいという効果もありそうだ。CPUの処理速度は、その他のコンピューターの構成
要素に比べ技術革新が即速度向上につながるため、ますますJavaに有利な環境となる傾向があるといえそうだ。
以上のことより、Javaをバッチ処理に適用した場合も、ほとんど問題は生じないと結論づけることができる。それどころか、Javaはバッチ処理に向いた特性を備えていると推測することさえ可能である。
今後、Javaの実行環境が、各プラットフォームに移植されてゆくに伴い、企業のカスタムアプリケーションのプラットフォームとして、Java環境がより重視され、手軽な環境で開発し、ＰＣから汎用機まで業務規模と発展振りに適したさまざまなプラットフォームで動作させるたいというニーズがどんどん生じてくると思われる。
［参考文献］
- [1]吉田弘一郎「極めるＪａｖａ」、1998技術評論社
- [2] 桑原恒夫「３日で解るＪａｖａ」、1997共立出版社
- [3] F.Partnoy「大破局」、1998徳間書店
- [4]B.Stroustrap「プログラミング言語Ｃ＋＋」、1993トッパン
- [5] 伊賀みどり「Ｊａｖａ ｖｓ Ｃ＋＋速度比較」、JavaPress Vol.3 1998技術評論社
- [6] Tucker!「憂鬱なプログラマのためのオブジェクト指向開発講座」、1998翔泳社
トップへ
目次へ
ホームページへ