Comments
Description
Transcript
Java への招待 - ASCII Books
目 次 はじめに 15 感謝のことば 21 Chapter 1 Java への招待 22 1.1 プログラミングツールとしての Java 1.2 Java の利点 24 25 1.3 Java のホワイトペーパーの専門用語 1.3.1 シンプル 26 1.3.2 オブジェクト指向 1.3.3 分散 27 1.3.4 堅牢 28 1.3.5 安全 28 27 1.3.6 アーキテクチャ中立 1.3.7 移植可能 30 30 1.3.8 インタープリタ方式 31 ハイパフォーマンス 31 1.3.9 26 1.3.10 マルチスレッド 1.3.11 動的 31 32 1.4 Java とインターネット 32 1.4.1 利用されているアプレット 1.4.2 サーバーサイドの Java 1.5 Java の簡単な歴史 33 34 35 1.6 Java に関する一般的な誤解 37 6 目 次 Chapter 2 Java プログラミング環境 2.1 Java SDK のインストール 2.1.1 実行パスの設定 2.1.2 42 43 44 ライブラリのソースファイルとドキュメントのインストール 2.1.3 本書のサンプルプログラムのインストール 2.1.4 Java ディレクトリのナビゲート 2.2 開発環境 45 46 47 47 2.3 コマンドラインツールの使用 48 2.3.1 トラブルシューティングのヒント 2.4 統合開発環境の使用 50 51 2.4.1 コンパイルエラーの場所の特定 53 2.5 テキストエディタによるプログラムのコンパイルと実行 2.6 グラフィカルアプリケーション 2.7 アプレット 54 57 60 Chapter 3 Java によるプログラミングの基礎構造 3.1 簡単な Java プログラム 3.2 コメント 71 3.3 データ型 71 3.3.1 整数 72 3.3.2 浮動小数点数 3.3.3 文字 3.3.4 3.4 変数 73 74 ブール型 75 75 3.5 代入と初期化 3.5.1 定数 3.6 演算子 68 76 77 78 3.6.1 インクリメント演算子とデクリメント演算子 3.6.2 比較演算子とブール演算子 3.6.3 ビット演算子 80 3.6.4 数学的な関数と定数 3.6.5 数値型の相互変換 80 81 82 79 66 目 次 3.6.6 キャスト 83 3.6.7 かっこと演算子の優先順位 3.7 文字列 84 85 3.7.1 連結 85 3.7.2 部分文字列 3.7.3 85 文字列の編集 86 3.7.4 文字列の等値性のテスト 87 3.7.5 オンラインドキュメントの利用 3.7.6 入力の読み取り 3.8 制御フロー 90 92 3.7.7 出力のフォーマット 94 97 3.8.1 ブロックのスコープ 3.8.2 条件文 97 98 3.8.3 不確定ループ 3.8.4 確定ループ 101 106 3.8.5 複数選択：switch 文 109 3.8.6 制御フローの中断 3.9 大きな数値 3.10 配列 7 111 114 116 3.10.1 配列の初期化と匿名の配列 3.10.2 配列のコピー 118 3.10.3 コマンドラインパラメータ 3.10.4 配列のソート 3.10.5 多次元配列 117 119 120 124 3.10.6 でこぼこの配列 126 Chapter 4 オブジェクトとクラス 130 4.1 オブジェクト指向プログラミングの紹介 4.1.1 OOP の用語 4.1.2 オブジェクト 4.1.3 クラス間の関係 131 133 134 135 4.1.4 OOP と手続き型プログラミング技法の比較 4.2 既存のクラスの使用 137 139 4.2.1 オブジェクトとオブジェクト変数 139 4.2.2 Java ライブラリの GregorianCalendar クラス 142 8 目 次 4.3 新しいクラスの作成 150 4.3.1 Employee クラス 150 4.3.2 複数のソースファイルの使用 4.3.3 153 Employee クラスの分析 154 4.3.4 Employee クラスのコンストラクタ 4.3.5 Employee クラスのメソッド 155 156 4.3.6 プライベートデータへのメソッドのアクセス 4.3.7 プライベートメソッド 160 161 4.3.8 final インスタンスフィールド 161 4.4 スタティックフィールドとスタティックメソッド 4.4.1 スタティックフィールド 4.4.2 定数 162 163 4.4.3 スタティックメソッド 164 4.4.4 ファクトリメソッド 165 4.4.5 main（）メソッド 4.5 メソッドの引数 166 168 4.6 オブジェクトの構築 174 4.6.1 オーバーロード 174 4.6.2 フィールドのデフォルトの初期化 4.6.3 デフォルトコンストラクタ 176 178 4.6.6 他のコンストラクタの呼び出し 4.6.7 175 176 4.6.4 フィールドの明示的な初期化 4.6.5 引数名 初期化ブロック 178 179 4.6.8 オブジェクトの破棄と finalize（）メソッド 4.7 パッケージ 184 4.7.1 パッケージの使用 184 4.8 ドキュメントのコメント 193 4.8.1 コメントの挿入方法 193 4.8.2 クラスのコメント 4.8.3 162 メソッドのコメント 194 195 4.8.4 フィールドのコメント 4.8.5 一般的なコメント 195 196 4.8.6 パッケージと概要のコメント 4.8.7 コメントの抽出方法 4.9 クラスの設計のヒント 197 198 197 183 9 目 次 Chapter 5 継承 202 5.1 クラスの拡張 203 5.1.1 継承の階層 5.1.2 多相性 211 212 5.1.3 動的バインディング 213 5.1.4 継承の禁止：final クラスと final メソッド 5.1.5 キャスト 215 217 5.1.6 抽象クラス 219 5.1.7 protected アクセス 224 5.2 Object：すべてのクラスのスーパークラス 225 5.2.1 equals（）メソッドと toString（）メソッド 5.2.2 汎用プログラミング 5.2.3 配列リスト 233 236 5.2.4 オブジェクトラッパー 5.3 Class クラス 226 243 247 5.4 リフレクション 251 5.4.1 リフレクションを使ってクラスの機能を分析する 252 5.4.2 リフレクションを使って実行時にオブジェクトを分析する 5.4.3 リフレクションを使って汎用的な配列のコードを書く 5.4.4 メソッドポインタ 257 263 266 5.5 継承の設計のヒント 270 Chapter 6 インターフェイスと内部クラス 6.1 インターフェイス 274 276 6.1.1 インターフェイスのプロパティ 281 6.1.2 インターフェイスと抽象クラス 282 6.1.3 インターフェイスとコールバック 6.2 オブジェクトのクローン 6.3 内部クラス 283 286 292 6.3.1 内部クラスによるオブジェクトの状態へのアクセス 6.3.2 内部クラスの特別な構文 298 6.3.3 内部クラスの利便性、必要性、安全性 6.3.4 ローカル内部クラス 6.3.5 スタティック内部クラス 301 307 299 293 10 目 次 6.4 プロキシ 310 6.4.1 プロキシクラスのプロパティ 315 Chapter 7 グラフィックスプログラミング 7.1 Swing の概要 319 7.2 フレームの生成 323 7.3 フレームの配置 326 7.4 パネルへの情報の表示 7.5 2 次元の図形 7.6 色 318 332 337 346 7.6.1 図形の塗りつぶし 7.7 テキストとフォント 7.8 画像 349 351 361 Chapter 8 イベント処理 368 8.1 イベント処理の基礎 370 8.1.1 例：ボタンのクリックの処理 8.1.2 イベントリスナーの選択 372 378 8.1.3 例：ルックアンドフィールの変更 8.1.4 例：ウィンドウイベントの捕捉 8.2 AWT のイベントの階層 382 385 388 8.3 AWT のセマンティックイベントと低水準イベント 8.3.1 イベント処理の要約 8.4 低水準イベントの種類 392 395 8.4.1 フォーカスイベント 395 8.4.2 キーボードイベント 397 8.4.3 イベントの消費 403 8.4.4 マウスイベント 404 8.5 アクション 412 8.6 マルチキャスト 422 8.7 イベントキュー 425 8.7.1 カスタムイベントの追加 426 391 目 次 11 Chapter 9 Swing による ユーザーインターフェイスコンポーネント 9.1 MVC（Model-View-Controller）設計パターン 9.1.1 Swing のボタンの MVC 分析 9.2 レイアウト管理の概要 443 444 9.2.1 ボーダーレイアウト 9.2.2 パネル 446 448 9.3 テキストの入力 450 9.3.1 テキストフィールド 450 9.3.2 入力値のチェック 457 9.3.3 パスワードフィールド 9.3.4 テキスト領域 466 467 9.3.5 ラベルとコンポーネント 471 9.3.6 テキストの選択 473 テキストの編集 474 9.3.7 9.4 選択 476 9.4.1 チェックボックス 9.4.2 438 476 ラジオボタン 9.4.3 ボーダー 480 484 9.4.4 コンボボックス 9.4.5 スライダー 9.5 メニュー 489 492 499 9.5.1 メニューの生成 499 9.5.2 メニュー項目のアイコン 503 9.5.3 チェックボックスとラジオボタンのメニュー項目 9.5.4 ポップアップメニュー 506 9.5.5 キーボードショートカットとアクセラレータ 9.5.6 メニュー項目の有効化と無効化 9.5.7 ツールバー 9.6 高度なレイアウト管理 510 518 521 9.6.1 グリッドレイアウト 524 9.6.2 ボックスレイアウト 529 9.6.3 グリッドバッグレイアウト 9.6.4 508 516 9.5.8 ツールチップ 504 534 gridx、gridy、gridwidth、gridheight 536 436 12 目 次 9.6.5 ウェイトフィールド 9.6.6 fill と anchor 9.6.7 536 537 パディング 537 9.6.8 gridx、gridy、gridwidth、gridheight を指定する別の方法 9.6.9 レイアウトマネージャを使わないレイアウト 9.6.10 レイアウトマネージャのカスタマイズ 9.6.11 移動の順序 537 542 542 547 9.7 ダイアログボックス 549 9.7.1 オプションダイアログ 550 9.7.2 ダイアログの作成 562 9.7.3 データの交換 566 9.7.4 ファイルダイアログ 573 9.7.5 カラーチューザ 585 Chapter 10 アプレット 592 10.1 アプレットの基礎 594 10.1.1 簡単なアプレット 596 アプレットの実行 598 10.1.2 10.1.3 ブラウザによるアプレットの表示 600 10.1.4 アプリケーションをアプレットに変換する 10.1.5 アプレットのライフサイクル 10.1.6 セキュリティの基本 606 607 10.1.7 アプレットのポップアップウィンドウ 10.2 アプレットのタグと属性 609 611 10.2.1 位置指定の属性 612 10.2.2 コードの属性 614 10.2.3 Java を受け入れないビューア用の属性 10.2.4 OBJECT タグ 617 10.2.5 Java Plug-in のタグ 618 10.2.6 アプレットに情報を渡す 10.3 マルチメディア 10.3.1 URL 604 619 625 625 10.3.2 マルチメディアファイルの取得 10.4 アプレットコンテキスト 10.4.1 アプレット間通信 627 628 626 617 目 次 10.4.2 ブラウザの項目の表示 629 10.4.3 Bookmark アプレット 631 10.4.4 アプレット、アプリケーション、その両方 10.5 JAR ファイル 13 634 639 10.5.1 マニフェスト 641 10.5.2 JAR のキャッシュ 642 10.5.3 自己実行型の JAR ファイル 10.5.4 リソース 643 644 10.5.5 オプションパッケージ 10.5.6 シール 648 649 Chapter 11 例外処理とデバッグ 11.1 エラーの処理 652 654 11.1.1 例外の分類 655 11.1.2 メソッドが発行する例外の宣言 11.1.3 例外の発行 659 11.1.4 例外クラスの作成 11.2 例外の捕捉 657 660 661 11.2.1 複数の例外の捕捉 664 11.2.2 例外の再発行 664 11.2.3 Java におけるエラーと例外の処理 11.3 例外処理のヒント 672 11.4 デバッグのテクニック 675 11.4.1 デバッグのヒント 11.4.2 アサート 675 680 11.4.3 コンソールウィンドウの使用 11.4.4 AWT イベントの捕捉 11.4.5 AWT ロボット 684 688 11.4.6 プロファイリング 692 11.4.7 カバレッジテスト 697 11.5 デバッガの使用 11.5.1 JDB デバッガ 11.5.2 Forte デバッガ 667 698 698 704 682 14 目 次 Chapter 12 ストリームとファイル 12.1 ストリーム 706 707 12.1.1 バイトの読み取りと書き込み 12.2 ストリームの完全な解説 710 12.2.1 ストリームフィルタの階層化 12.2.2 データストリーム 12.2.3 708 713 717 ランダムアクセスファイルストリーム 12.3 ZIP ファイルストリーム 12.4 ストリームの使用 720 730 739 12.4.1 デリミタ付きの出力 739 12.4.2 StringTokenizer とデリミタ付きテキスト 12.4.3 デリミタ付きの入力 740 742 12.4.4 ランダムアクセスストリーム 12.5 オブジェクトストリーム 746 753 12.5.1 可変型のオブジェクトの保存 754 12.5.2 オブジェクトのシリアライズにおけるファイル形式 12.5.3 オブジェクトの参照の保存に関する問題 12.5.4 オブジェクトの参照の出力形式 12.5.5 セキュリティ 769 771 12.5.6 バージョン管理 776 12.5.7 シリアライズによるクローンの生成 12.6 ファイル管理 758 762 779 781 Appendix A Java キーワード 索引 791 789 21 感謝のことば 書籍を執筆する作業は、常に途方もない努力を必要とし、書籍の改訂も簡単とは言えない。 特に、Java のように変化の激しい技術についての執筆はなおさらである。書籍を世に出すため には多くの人の努力が必要であり、この場で Core Java チームの全員の貢献に対して感謝の意 を表したい。 Prentice-Hall PTR、Sun Microsystems Press、Navta Inc. の多くのスタッフが貴重な助言 をしてくれ、陰ながら支えてくれた。彼らの努力に感謝の意を表したい。いつもと同様に、 Prentice-Hall PTR の編集者である Greg Doench と彼のアシスタントの Mary Treacy に心か ら感謝を捧げる。2 人は、陰ながら努力してくれたメンバー全員と協力し、執筆原稿を書籍に仕 上げるのに専念してくれた。また、初版の共著者であり、現在は別の事業に従事している Gary Cornell にも感謝する。 初版で多くのエラーを発見し、改善案を提供してくれた多くの読者に感謝する。また、原 稿にくまなく目を通し、エラーを見つけてくれたすばらしいレビューチームに感謝する。Bob Lynch、Bradley A. Smith、Paul E. Sevinc（Teamup AG） 、Mark Morrissey（Oregon Graduate Institute）、Peter Sander（ESSI University、Nice、France）、Chuck Allison（C/C++ Users Journal の編集者）がレビューを行ってくれた。 最後に、なかなか終わりの見えなかったプロジェクトを根気強くサポートしてくれた妻の Hui-Chen と、Thomas と Nina の 2 人の子供たちに、心から愛と感謝と謝罪の意を表したい。 Cay Horstmann 2000 年 11 月 Cupertino にて CHAPTER 1 プログラミングツールとしての Java Java の利点 Java のホワイトペーパーの専門用語 Java とインターネット Java の簡単な歴史 Java に関する一般的な誤解 Javaへの招待 長い間、Java に関する記事の載っていないコンピュータ雑誌はほとんどない状態が続いてい る。ニューヨークタイムズやワシントンポスト、ビジネスウィークなどの、いわゆる主流の新 聞や雑誌でさえ数々の Java 関連記事を取り上げてきた。Java に関する騒ぎはとどまることな く、アメリカの有名なラジオ番組で取り上げられたり、Java を使用した製品のみを対象になん と 1 億ドルもの投資資金が組まれた。CNN、CNBC など日本人でも一度は耳にしたことがある アメリカニュース界のビッグネームも、軒並み Java に取りつかれたかのように騒ぎ立てた。 しかし、本書は、シリアスなプログラマのニーズにこたえることを目標とした。Java はシリ アスなプログラミング言語であるため、内容的にも盛りだくさんになっている。本書では、前 記のような新聞などによる過度な騒動から少し離れた立場で、Java の詳細について簡単に説明 する（もちろん、騒ぎの原因となったインターネットで使用するための付加機能についても取 り上げる） 。さらに、増幅された Java への期待に振り回されないように、現在 Java が現実にで きることとできないことを明確にしていく。 Java の黎明期には、Java に関するうわさと実際ではかなりの食い違いがあったが、Java が進 化していくにつれて、技術の安定性と信頼性も上がり、また期待の度合いも相応なレベルへと 落ち着いてきている。本書を執筆している時点では、Java はクライアントとデータベース、そ してその他のサーバーリソース間の通信を行うミドルウェアとして使用される機会が多くなっ ている。派手さはないが、これは Java にとって重要な分野である。Java の本領は移植性、マ ルチスレッド処理、ネットワーク機能をもって初めて発揮されるからだ。Java はハンドヘルド 機器、インターネットキオスク、カーコンピュータなどで標準となるのにふさわしい内蔵シス テムに大きな影響を及ぼしている。しかし、最初は Java のアプリケーションが現在と比べると パワー不足で遅かったため、それまでに慣れ親しんだ PC プログラムを Java に書き換えるとい う考えはあまり支持されなかった。現行の Java では、こういった問題のいくつかは解決されて 24 Chapter 1 Java への招待 いるが、たいていのユーザーはアプリケーションがどの言語で書かれているかなど気にしない ため、既存のプログラムを Java で書き換えるのはあまり意味がない。Java の恩恵は過去のプ ログラムを書き直すことではなく、新しいものを作り出すことで得られると考える。 1.1 プログラミングツールとしての Java コンピュータ言語として Java はかなり大げさに騒がれている。確かに Java は優れたプログ ラミング言語である。また、それがシリアスなプログラマの眼鏡にかなう言語のうちでも、優 れていることに疑いの余地はない。Java はすばらしいプログラミング言語となる可能性を持っ ていたが、それは少し期を逸したように思う。Java が使われるようになれば、以前から存在す るコードとの互換性などの問題が発生するからだ。また、既存のコードを損なうことなく変更 可能な場合でも、Java と同様に評価の高い言語の作成者が「X については自分が間違っていた。 Y のほうが優れている」と発言することはほとんどない。要するに、時間の経過と共にこういっ た問題が解決されることを期待するが、Java 言語の構造は基本的には今とあまり変わらないと 思われる。 さて、Java の驚異的な進化はどのように起こったのか。それは根底にある Java プログラミ ング言語への変更からではなく、Java ライブラリでの大幅な変更から起こった。時間をかけ て、Sun Microsystems はいくつものライブラリ名の変更（一貫性を持たせるため） 、グラフィッ クスの動作方法の変更（一部をまったく新規に書き直し、イベント処理モデルを変更すること により） 、Java 1.0 にはなかった印刷などの重要な機能の付加など、いろいろな変更を加えてき た。その結果、Java は以前のものと比べてより使い勝手のよいプログラミングツールに変貌し たのである。 NOTE：Microsoft は、Java と似た機能を持つ J++という製品を開発している。J++は、Java のように Java バイトコードを実行するために、Java 仮想マシンと互換性のある仮想マシン により実行されるが、外部コードとのインターフェイスに関して Java とは本質的な違いがあ る。言語の基本構文はほぼ Java と同じである。ただし、Microsoft は、Windows とのインターフェイス 以外では正しく動くかどうか疑わしい機能を持つ言語構造を付加している。Java と J++は構文を共有する だけでなく、基本ライブラリ（文字列、ネットワーク、マルチスレッド、数値計算、その他）も基本的には まったく同じである。しかし、グラフィックス、インターフェイス、リモートオブジェクトのアクセスのた めのライブラリはまったく別のものである。現在、Microsoft は J++の代わりに新しい C#の導入を推奨し 始めている。C#にはやはり Java との類似点が多いが、異なる仮想マシンを使う。本書では、J++および C#については説明しない。 1.2 Java の利点 25 1.2 Java の利点 Java の最も大きな利点は、プラットフォームに依存しない実行環境を提供する実行ライブラ リである。つまり、一度作成したコードを Windows、Solaris、Linux、Macintosh、その他の OS のいずれにおいても使用できる。これはインターネットを介して各種のプラットフォーム にダウンロードされるプログラムには当然必要なことである。 その他のプログラミング上の利点として、Java の構文が C++に似ている点が挙げられる。そ の反対に Visual Basic（VB）プログラマにとっては、Java の構文はわかりにくく見える。 NOTE：読者が C++以外の言語を利用しており、本章でなじみのない用語を見つけた場合は とりあえず読み飛ばしてほしい。Chapter 6 の終わりまでにはそのような用語にも慣れるは ずである。 さらに、Java はオブジェクト指向であるということも大きな利点である。Java は C++に比 べてオブジェクト指向の性質が強く、数値などのいくつかの基本型以外はすべてオブジェクト である（オブジェクト指向プログラミングは、より複雑なプロジェクトを取り扱う際に利点が 多いため、初期の構造化技術に取って代わっている。オブジェクト指向については Chapter 3 から Chapter 6 で詳しく説明する） 。 しかし、C++の表現を進化させたという程度では Java の利点を説明しきれていない。キーポ イントは、Java でバグのないコードを書くのは、C++よりはるかに簡単であるということだ。 なぜだろうか。それは Java の設計者が、C++でバグが多くなる理由を考慮した結果、出現頻 度の高いバグを持つコードを作成しないようにする機能を Java に付加したからである。 ● Java の設計者はプログラム内でのメモリの割り当てと解放を排除した。 Java ではメモリはガーベージコレクタにより自動的に処理される。したがって、メモリ リークを心配する必要はまったくない。 ● 真の意味での配列を取り入れ、ポインタ構造を排除した。 これによりポインタのエラーで 1 つ隣のバイトを書き換えてしまい、メモリ上の重要な領 域を上書きする危険性がなくなる。 ● 代入文と条件文での等値比較の混乱の可能性を排除した。 簡単な例を挙げると if (ntries = 3) ... はコンパイルできない（VB プログラマには問題 ないように思われるだろうが、実はこれは C/C++コードにおける混乱の主な原因である）。 ● 多重継承を排除し、Objective C から引用した新しいインターフェイスの考え方に置き換 えた。 インターフェイスは、多重継承の階層の管理による混乱を防ぎながら、多重継承によって 実現できる機能を提供する（継承が未知の概念である場合は、Chapter 5 を参照）。 26 Chapter 1 Java への招待 NOTE：Java の言語仕様は Java の Web サイトで公開されている（http://java.sun.com/ docs/books/jls/second_edition/html/j.title.doc.html にある）。 1.3 Java のホワイトペーパーの専門用語 Java の設計者は、設計目標を説明した有益なホワイトペーパーを作成した。このホワイト ペーパーでは、Java の機能を次の 11 個の言葉で説明している。 シンプル 移植可能 オブジェクト指向 インタープリタ方式 分散 ハイパフォーマンス 堅牢 マルチスレッド 安全 動的 アーキテクチャに中立 一部は前にも触れた。ここでは、次のように説明を行う。 ● ホワイトペーパーの抜粋を用いて、各用語に関する Java 設計者の解説をまとめる。 ● それぞれの用語に対する著者の意見を、現バージョンの Java に関する経験を基に説明する。 NOTE：本書の執筆時点では、ホワイトペーパーは http://java.sun.com/docs/white/ langenv/にある。 1.3.1 シンプル 我々は、特別なトレーニングなしで簡単にプログラミングできるシステムを作りたい。その ため、C++はあまり適当ではないと判断したが、システムをより包括的にするために Java もで きるだけ C++に近い形で設計した。ただし、Java では、使用頻度が低くてわかりにくく、メ リットよりも苦労が多い C++の機能についてはその多くを省いた。 Java の構文は、確かに C++の構文を整理して無駄を省いたものとなっている。ヘッダファ イル、ポインタ計算（ポインタ構文さえも） 、構造体、共用体、演算子のオーバーロード、仮想 基本クラスなどを必要としない（本書を通して紹介されている Java と C++の相違点を参照）。 しかし、設計者は C++の switch 文などの洗練されていない機能には手を加えなかった。した がって、C++を知っていれば Java への移行は簡単である。 読者が VB などのビジュアルなプログラミング環境に慣れているなら、Java はそれほど単純 には思えないこともある。Java には見慣れない構文も多く存在する（ただし、すぐに慣れてし 1.3 Java のホワイトペーパーの専門用語 27 まう） 。より重要な違いは、Java ではプログラミングの量自体が増えることである。VB の優れ た点は、ビジュアルな設計環境でアプリケーションの基本構造をほぼ自動的に提供することで ある。Java では、同等の機能を実現するには少しではあるが自分でプログラミングを行う必要 がある。ただし、サードパーティベンダーにより「ドラッグアンドドロップ」式のプログラム開 発を行うための開発環境が提供されている。 また、シンプルであるということは小さいということでもある。Java の目標の 1 つに、小さ なコンピュータ上でスタンドアロンで稼働できるソフトウェアの構築を可能にすることがある。 基本的なインタープリタやクラスサポートのサイズは 40K バイトである。それに基本標準ライ ブラリとスレッドサポート（本質的には独立したマイクロカーネルである）を付加すると 175K バイトの増加となる。 これはたいへんな進歩である。しかし、GUI ライブラリはもっとサイズが大きいことに留意 する必要がある。 1.3.2 オブジェクト指向 一言で言うと、オブジェクト指向設計はデータ（＝オブジェクト）とそれらのオブジェクトへ のインターフェイスに焦点を絞ったプログラミング技術である。大工仕事になぞらえると、オ ブジェクト指向な大工はまず作ろうとする椅子に最も意識を注ぎ、次にその椅子を作るために 使用する道具に意識を注ぐ。オブジェクト指向でない大工は主に道具に意識を注ぐ。Java のオ ブジェクト指向の機能は基本的に C++のものである。 オブジェクト指向はここ 30 年間でその価値を証明しており、現代のプログラミング言語と して使用しないことはもはや考えられない。確かに Java のオブジェクト指向の機能は C++と かなり似ている。その中でも Java と C++の主な違いは多重継承にあり、Java と Java メタク ラスモデルでは C++より優れた解決策を提供している。リフレクションメカニズム（Chapter 5 を参照）とオブジェクトのシリアライズ機能（Chapter 12 を参照）は永続オブジェクトといつ でも使えるコンポーネントを統合する GUI ビルダーの実装をより簡単にする。 NOTE：読者が OOP（オブジェクト指向プログラミング）言語の経験がない場合、Chapter 4 から Chapter 6 によく目を通してほしい。これらの章では OOP とは何か、なぜ BASIC や C などの以前からある手続き型言語に比べて複雑なシステムのプログラミングに適している かを説明している。 1.3.3 分散 Java は、HTTP や FTP のような TCP/IP プロトコルを使ってよく行う処理のための数々のラ イブラリを持つ。Java アプリケーションはローカルファイルシステムへアクセスするのと同じ くらい気楽に、URL を通してネットワーク越しにオブジェクトにアクセスすることができる。 28 Chapter 1 Java への招待 Java のネットワーク機能は強力であり、実に簡単に使用できる。Java 以外の言語でインター ネットプログラミングを試みたことのある読者であれば、たとえばソケット接続のオープンな どの面倒な作業をいかに Java が単純にしているかを見て歓喜することだろう。さらに、サーブ レットと呼ばれる便利な機能が Java によるサーバーサイドの処理を非常に効率的にする。数々 の有名な Web サーバーがサーブレットをサポートしている（ネットワークに関しては本書の Vol.2 で網羅する） 。さらにリモートメソッドの呼び出し機能は分散オブジェクト間の通信を可 能にする（これも Vol.2 で網羅する）。 1.3.4 堅牢 Java は、いろいろな面で高い信頼性が求められるプログラムを書くのに適した言語である。 Java は、潜在的な問題の早期チェック、実行時に行われる動的なチェック、エラーになりがち な状態を取り除くことなどに力を入れている。Java と C/C++で 1 つ大きく違うのは、Java が メモリの上書きとデータの破壊を起こす可能性のないポインタモデルを備えていることである。 この機能もまた非常に便利である。Java のコンパイラは、他の言語では実行時になって初め て現れる多くの問題を検出する。ポインタ関連のバグで引き起こされるメモリの破壊を追跡す るのに何時間も費やしたプログラマにとって、Java のこの機能は非常に有益である。 ポインタを明示的に使用しない VB や COBOL のような言語に慣れ親しんでいる読者は、な ぜこの機能がそれほど重要なのかを不思議に感じると思う。しかし、C 言語のプログラマはそ れほど恵まれていない。C 言語では文字列、配列、オブジェクト、またはファイルでさえもア クセスするのにポインタが必要である。VB ではこれらのエンティティのいずれにもポインタ を使わず、メモリの割り当てについて気をもむ必要もない。一方で、ポインタを持たない言語 では実装が難しいデータ構造も数多く存在する。Java はこの 2 つの問題に解決策を提供する。 文字列や配列など日常的に使用される構造についてはポインタを必要としないが、リンクリス トなどのようにポインタを必要とするものについては、Java が大いに威力を発揮する。また、 不正なポインタにアクセスしたり、メモリの割り当てによってエラーが起きたり、メモリリー クを防ぐ手段が必要になることがないため、完全な安全性を保証できる。 1.3.5 安全 Java はネットワークや分散環境での使用を目的としている。このため、Java はセキュリティ に大きく力を入れている。Java を使えばウィルスや不正行為の被害などを受けないシステムの 構築が可能になる。 本書の初版では「絶対ないとは決して言うべきではない」と述べ、それが正しいことを明ら かにした。プリンストン大学のセキュリティに関する権威者のグループが Java 1.0 のセキュリ ティ機能の最初のバグを見つけたのは、JDK 1.0 が出荷されてまもなくのことであった。さら に彼らを含む多くの人がその後のすべての Java のバージョンにおいてセキュリティメカニズム のバグを見つけている。Java のセキュリティに関してはプリンストン大学のグループの Web 1.3 Java のホワイトペーパーの専門用語 29 サイト（http://www.cs.princeton.edu/sip/）および comp.risks というニュースグループを 参照してほしい。幸い、Java の開発チームはセキュリティ関連のバグを「断固として許さない」 という態度をとり、Java アプレットのセキュリティメカニズムで発見されたすべてのバグに対 して即座に修復にかかることを表明している。特に、Java のインタープリタの内部仕様を公表 することによって、Sun Microsystems はユーザーが Java のセキュリティ機能のバグを簡単に 発見できるようにしている。事実、非常に微妙なセキュリティのバグの検出に関して外部団体 の貢献度は非常に大きい。これによりセキュリティのバグができる限り早急に発見されるよう になっている。とにかく Java はセキュリティのメカニズムの裏をかくことを非常に難しくして いる。これまでに発見されたバグもバグかどうかは微妙なもので、その数も比較的少ない。 NOTE：Sun Microsystems のセキュリティ問題についての URL を次に示す。 http://java.sun.com/sfaq/ Java のセキュリティ機能によって Java プログラムで制御されている処理の例を挙げる。 1. 悪名高いインターネットワームがもたらすようなプログラムの実行時侵害 2. Java プログラムの処理領域外でのメモリの破壊 3. Web ブラウザと同様に、セキュリティ制限の厳しいクラスローダーに呼び出される際の ローカルファイルへの読み書き（Web ブラウザはローカルファイルへの読み書きを禁止 するように作られている） これらすべての機能はすでに組み込まれており、そのほとんどは意図したとおりに動いてい るようである。確かに Java は現在のところ最も安全なプログラミング言語である。しかし、警 戒は常に必要である。セキュリティメカニズムでこれまでに見つけられたバグは簡単には見つ からないようなものであり、バグの詳細についてもすべて公開されていないが、Java が完全に 安全であると証明するのは不可能である。 現在までに Java には数多くのセキュリティ機能が追加されている。Java 1.1 以降には署名付 きのクラスの概念が取り入れられている（Vol.2 を参照）。署名付きのクラスによってクラスの 作成者を確認できる。また、署名付きのクラスの作成者を信頼すれば、コンピュータ上でより 多くの特権を与えることができる。 NOTE：Java と競合する Microsoft の ActiveX 技術に基づくコード配布のメカニズムを見る と、セキュリティに関してはデジタル署名のみに頼っている。明らかにこれは十分ではなく、 Microsoft 製品のユーザーであればわかることだが、有名なベンダーからのプログラムでさえ もクラッシュし、大きな被害を受けることがある。Java は ActiveX より強力なセキュリティモデルを備え ており、アプリケーションの実行と停止を制御することにより壊滅的な状態になることを防いでいる。 30 Chapter 1 Java への招待 1.3.6 アーキテクチャ中立 Java のコンパイラはアーキテクチャに中立なオブジェクトファイル形式を生成する。コンパ イルされたコードは、Java の実行環境が存在しさえすればどのようなプロセッサでも実行可能 である。これは、Java のコンパイラが生成する特定のコンピュータアーキテクチャにまったく 影響しないバイトコード命令によって可能となる。これらの命令はどんなコンピュータ上でも 実行中に簡単にネイティブなマシンコードに変換できる。 これは新しいアイデアではない。20 年以上も前に UCSD の Pascal システムはこれと同じこ とを商用の製品で行っており、それ以前にも Niklaus Wirth が最初に Pascal を実装した際に同 じ手法を用いた。バイトコードの使用はパフォーマンスに大きな影響を与えた（しかし、ほと んどの場合、JIT コンパイラによりこれは緩和された） 。Java の設計者はバイトコード命令セッ トの開発においてすばらしい成果を上げた。そのバイトコード命令は今日のほとんどの一般的 なコンピュータアーキテクチャ上で問題なく動いている。また、それらのコードは実際のマシ ン命令に簡単に変換されるように設計されている。 1.3.7 移植可能 C や C++と異なり Java にはその仕様に「実装環境に依存する」側面がない。基本データ型の サイズはデータの計算に合った大きさで指定される。 たとえば、Java における int は常に 32 ビットの整数である。C/C++では int はコンパイラ を作ったベンダーの好みで 16 ビットや 32 ビットの整数または他のサイズになる。int に対す る制限は、short 型の整数に必要なバイト数以上で long 型の整数のバイト数を超えてはならな いという点だけである。数値データ型のサイズが固定されているため、移植する際の頭痛の種 はなくなる。バイナリデータは固定形式で保管されるため、ビッグエンディアンおよびリトル エンディアンの問題は生じない。文字列は標準の Unicode 形式で保管される。 システムの一部を占めるライブラリは移植可能なインターフェイスを設定する。たとえば、 抽象クラスの Window は UNIX、Windows、Macintosh 用の実装が存在する。 実際に試したことがあればわかるが、Windows および Macintosh、さらに 10 種類もの微妙 に異なる UNIX 上でも問題なく動くプログラムを書くためには多大な労力を要する。Java 1.0 では、多大な努力により、ユーザーインターフェイスの共通要素を多くのプラットフォームに マップする簡単なツールキットをリリースした。しかし、残念ながら、結果として多くの作業 を行った後で初めて各種のシステムに受け入れられる程度のライブラリが提供された。しかも、 それぞれのプラットフォームのグラフィックスに関する実装の違いに起因してそれぞれ異なる バグが発生した。とはいえ、これは大きな前進の始まりであった。移植可能であることが、ス ムーズに動くことの何倍にも増して重要なアプリケーションが多数存在し、これらのアプリケー ションは Java の初期のバージョンを使うことによって多大な利益を得た。その後ユーザーイン ターフェイスツールキットは完全に書き直され、現在ではホストのユーザーインターフェイス 1.3 Java のホワイトペーパーの専門用語 31 にはまったく依存しなくなっている。 そのため、Java の初期バージョンに比べると、実行は ずっと安定しており、はるかに魅力的になったように思われる。 1.3.8 インタープリタ方式 Java インタープリタがインストールされているコンピュータ上であれば、Java バイトコー ドを直接実行することができる。プログラミング中に少数のリンクを作成するのはあまり負担 のかからない処理なので、プログラムの開発ははるかに簡単になり、より重要な作業に時間を 費やすことができる。 これはアプリケーションを作成するうえでの大きな利点ではあるが、明らかに少し過大評価 された言い方である。Java SDK に付属している Java コンパイラの処理がかなり遅いことは周 知の事実であるからだ（たとえば、IBM などのサードパーティから提供されているコンパイラ はかなり速い） 。開発環境では、唯一再コンパイル速度のみが向上している。そのため、Visual Basic の開発サイクルの速度に慣れていると、Java 開発環境のパフォーマンスにがっかりする ことになる。 1.3.9 ハイパフォーマンス インタープリタ方式でバイトコードを実行するときのパフォーマンスは、たいていの要求を 満たすが、さらに高いパフォーマンスが要求される場合もある。このような場合、実行時にバ イトコードをマシンコードにすばやく変換することができる。 インタープリタによるバイトコードの実行は、決してハイパフォーマンスとは言えない。た だし、多くのプラットフォーム上でジャストインタイム（JIT）コンパイラによる別の方式のコ ンパイルが可能である。JIT 方式のコンパイルでは、よく利用するコードの実行速度が驚異的 なほど速くなる。これは、一度しかコードの変換を行う必要がないからである。それでもネイ ティブコードのコンパイラよりは少し遅いが、一部のプログラムは JIT コンパイラによって 10 ∼20 倍速くなり、通常の Java インタープリタよりはるかに速い。この技術は継続的に改善さ れており、いずれ従来のコンパイル方法では及ばないほどの結果を生み出す可能性がある。た とえば、JIT コンパイラは最も頻繁に実行されるコードを発見して、その部分のみを最適化す ることもできる。 1.3.10 マルチスレッド マルチスレッドの利点は、インタラクティブな処理が効率的に実行できるようになることと、 リアルタイム処理の効率が上がることである。 読者が他の言語でマルチスレッド処理を試みた経験が一度でもあれば、Java では実に簡単に 実現するのを見て非常に喜ぶことだろう。さらにマルチスレッド処理は、OS がマルチプロセッ サシステムであればその機能も活用できる。一方、プラットフォームによってスレッドの実装 は大幅に異なるため、Java ではスレッドの実装がプラットフォームから完全に独立した形に 32 Chapter 1 Java への招待 なっている。これは異なるコンピュータでマルチスレッド処理を呼び出すコードの書き方のみ を統一することによって実現される。つまり、Java は実行環境の OS から完全に分離された形 でマルチスレッド処理を実装している（スレッドに関しては Vol.2 で詳細に解説する） 。とにか くマルチスレッド処理の存在はサーバーサイドアプリケーションの開発に Java が好んで使用さ れる言語となっている大きな理由の 1 つである。 1.3.11 動的 いろいろな意味で、Java は C や C++よりも動的であると言える。これは Java が進化する環 境に適応できるように設計されているからである。これにより、クライアントにまったく影響 を及ぼすことなく、ライブラリによって自由に新しいメソッドやインスタンス変数を追加する ことができる。Java では実行時に型情報を見つけるのは実に簡単な処理である。 これは実行中のプログラムにコードを追加する必要がある場合などにとても重要な機能とな る。主な例として、ブラウザで実行するためにインターネットからダウンロードされるコード が挙げられる。Java 1.0 でも実行時に型情報を見つけるのは実に簡単であったが、Java の現在 のバージョンではプログラマがオブジェクトの構造と動作をいつでも参照できる。これは Java の GUI ビルダー、スマートデバッガ、プラグイン可能なコンポーネント、オブジェクトデータ ベースなど、実行時にオブジェクトを分析しなければならないシステムにおいては非常に便利 な機能である。 1.4 Java とインターネット ここでの説明は単純である。つまり、ユーザーは Java のバイトコードをインターネットから ダウンロードしてローカルのコンピュータでそのコードを実行するというしくみだ。このよう に Web ページで使用される Java プログラムを、アプレットという。アプレットを使用するた めにはバイトコードを変換する機能を備えた Java 対応の Web ブラウザが必要である。Java の ソースコードのライセンスを所有する Sun Microsystems が、言語と基本ライブラリ構造は絶 対に変更しないことをコミットしているため、Java 対応のブラウザであれば必ず Java アプレッ トを実行できることが保証されている。Netscape 2.x と Netscape 3.x は、Internet Explorer 3.0 と同様に Java 1.02 にのみ対応していることに注意したい。Netscape 4 と Internet Explorer 4.0 は Java 1.1 のそれぞれ別のサブセットに対応している。このような状況が最新の Java を 有効活用するアプレットの開発をどんどん難しくしていく。この問題を改善するために Sun Microsystems は Netscape および Internet Explorer で最新の Java 実行環境を使用可能にする ツールを開発した。このツールを、Java Plug-in という（Chapter 10 を参照）。 Java を取り巻く初期の興奮のほとんどは特殊な用途のソフトウェアを開発して富を得るとい う考えによるものだと思う。そのような考えで、よくできたプログラムを開発する人もいるが、 これをアプレットに変換して、たとえば 1 回の使用料金を設定しても、ユーザーはこのような プログラムを頻繁には使わない。ユーザーが個人でソフトウェアをインターネットからダウン ロードして使用する時代になるという考えもある。これはソフトウェア企業には結構なことだ 1.4 Java とインターネット 33 が、かなりばかげた話である。たとえば、電子メールを送信するたびにスペルチェッカーをダ ウンロードして使用料金を払うなどというのはとうてい受け入れられそうにもない。 当初提案されたもう 1 つのアプレットの使用法は、Java 対応の Web ブラウザを使用して動 的に新しい種類の情報を扱えるようにする、コンテンツおよびプロトコルのハンドラとして使 うというものである。たとえば、非常に大きいサイズの画像ファイルを圧縮するすばらしいア ルゴリズムを発明したとして、その使用料を設定する前に何人かのユーザーにこの技術を試用 してもらいたい場合を考えよう。このような場合、展開処理を実行する Java のコンテンツハ ンドラを書いて圧縮されたファイルと一緒に送ればよいのだ。ただし、Sun Microsystems の HotJava ブラウザはこの機能をサポートしているが、Netscape および Internet Explorer は今 のところこの機能をサポートしていない。 アプレットは Web ページにボタンや入力フィールドを追加するためにも使われる。しかし、 これらのアプレットをダイヤルアップ回線を通してダウンロードするのは時間がかかる。代わ りにほとんど同じ処理を DHTML、HTML フォーム、JavaScript のようなスクリプト言語に よって実現することができる。また、初期のアプレットは回転する地球、踊るアニメキャラク ター、震えるテキストなどのアニメーションに使用されてきた。しかし、アニメーション GIF を使えばこれとほとんど同じ処理が実現可能であり、DHTML をスクリプトと組み合わせると 初期に Java アプレットで実現されていたよりも多くの処理を実行できる。 ブラウザ間の互換性がなかったり、遅いネットワーク接続を通してアプレットのコードをダ ウンロードするのが不便であることを理由に、インターネットの Web ページ上のアプレットと いう考えは大きな成功にはつながらなかった。ただし、イントラネットに関してはまったく状 況が異なる。イントラネットではネットワーク回線の制限に関する問題はほとんどなく、アプ レットのダウンロードにかかる時間も問題にならない。さらにイントラネットでは使用される ブラウザや Java Plug-in を統一できる。プログラムは Web ブラウザ上で提供されるため、従 業員はプログラムの設定を間違えることもなく、システム管理者は社内を歩き回ってクライア ントのソフトウェアをアップグレードする必要もない。最近では多くの企業が在庫管理、休暇 管理、出張申請などを Web ブラウザ上でアプレットとして実行するシステムをリリースして いる。 1.4.1 利用されているアプレット 本書では、サンプルアプレットをいくつか使用している。究極的には、アプレットの最高の 情報源は Web そのものである。Web 上のアプレットには実行画面しか見ることができないも のもあるが、多くのアプレットではソースコードを見ることができる。もう少し Java に慣れた ら、こういったアプレットを利用して Java を勉強するのは実に効果的である。Java アプレッ トのよい参考となるサイトに Gamelan がある。この Web サイトは現在は developer.com サイ トの一部となっているが、http://www.gamelan.com/という URL からもアクセスできる（ちな みに、gamelan［ガムラン］はジャワの特別な打楽器のアンサンブルを意味する。機会があれば 一度鑑賞するとよい。非常にすばらしい音楽である）。 34 Chapter 1 Java への招待 ユーザーがアプレットをダウンロードすると、Web ページに画像を埋め込んだ形で表示さ れる（HTML における IMG タグのことである）。アプレットはページの一部になり、文字はア プレットの中でふわふわと動き回る。ポイントは画像が生きているように動くことだ。画像は ユーザーのコマンドに反応し、表示を変化させ、アプレットを参照しているコンピュータとそ れを提供するコンピュータの間で簡単にデータを送信できる。 図 1-1 は洗練された計算を実行してアプレットに分子を表示させる動的な Web ページのよ い例である。マウスを使って分子を回転させたり、拡大することにより、構造をより深く理解 できる。このような直接的な操作は静的な Web ページでは実行できないが、アプレットにより 可能になる（このアプレットは http://www.openscience.org/jmol/JmolApplet.html で参照 できる）。 図 1-1 Jmol アプレット 1.4.2 サーバーサイドの Java 本書の執筆時点では、クライアント重視のプログラムからサーバーサイドのプログラミング に重点が移り始めている。特に、アプリケーションサーバーは Java 仮想マシン（JVM）の監視 機能を使って、自動負荷調整、データベース接続のプール、オブジェクトの同期、安全なシャッ トダウンと再起動、拡張性の高いサーバーアプリケーションに不可欠だが正しく実装するのが ひどく困難なサービスなどを実行できる。そのため、アプリケーションのプログラマは、これ らの複雑なメカニズムを自分で構築しなくても、購入できるようになった。これにより、プロ グラマの生産性が向上する。プログラマは、サーバーのパフォーマンスの低下を気にせずに、 中核技術やプログラムのビジネスロジックに集中できるからである。 1.5 Java の簡単な歴史 35 1.5 Java の簡単な歴史 ここでは Java の進化の歴史を簡単に紹介する。ここでの説明はさまざまな公開資料に基づ いている（最も重要な資料としては、1995 年 7 月に発行された Sun World オンラインマガジン の Java の生みの親に対するインタビューがある） 。 Java の誕生は 1991 年、Patrick Naughton と James Gosling が率いる Sun Microsystems の 技術者グループがケーブルテレビのスイッチボックスなど消費者向けの機器で使用できるコン パクトなコンピュータ言語の設計を考えたときにさかのぼる。このような機器にはパワーやメ モリがそれほどなく、言語はコンパクトである必要があった。また、さまざまなメーカーが異 なる CPU を採用することが考えられるため、単一のマシン構造に特化した作りにしないことも 重要であった。このプロジェクトには Green というコードネームが付けられた。 このコンパクトな言語の必要性によって、Niklaus Wirth が開発し、初期の PC で使用され た UCSD Pascal の言語モデルが復活されることとなった。Wirth が開発した UCSD Pascal と Green プロジェクトの双方のエンジニアが目指したのは、仮定のマシン用に中間コードを生成 する移殖可能な言語を設計することであった（このマシンを仮想マシン（Virtual Machine）と いう。Java の仮想マシンは JVM と呼ばれる） 。この中間コードは必要なインタープリタを備え ているコンピュータ上ならどこでも実行可能である。このモデルで生成された中間コードは確 実にコンパクトで、インタープリタ自体もかなり小さなものになるため、当初の目標は達成さ れた。 Sun Microsystems の技術者は UNIX 環境に慣れ親しんでいたため、Pascal ではなく C++を 基本にして設計した。これによって Java は、手続き型言語ではなく C++と同様のオブジェク ト指向言語という特徴を備えることになった。しかし、Gosling がインタビューで言っていたよ うに、「結局、言語は単なるツールであって、それが最終目標というわけではない」のである。 つまり、言語によって実現できることがゴールであり、そのゴールを実現しやすい言語がよい 言語と言えるのだ。Gosling はこのような考え方に沿って自分で言語を設計し、これを Oak と 名付けた（これは彼が Sun Microsystems の自分のオフィスの窓の外にある樫の木の枝振りが好 きだったからであると言われている） 。後に、Sun Microsystems は Oak が既存のコンピュータ 言語の名前として使われているのを知り、名前を Java と改めた。 1992 年に Green プロジェクトはその最初の製品である「∗7」を発表した。これは非常に洗練 されたリモートコントロールであった（通常のコンピュータボックスに入った SPARC ステー ションと同じ力を持っていた） 。残念なことに Sun Microsystems では誰もこの製品の生産に興 味を持たず、Green プロジェクトはこの技術を宣伝する別の手段をいくつか考え出した。しか し、一般消費者向けのエレクトロニクス企業はどこも興味を示さなかったのである。そこで彼 らはビデオオンデマンドなどの新しいサービスを提供するケーブルテレビのセットトップボッ クスを設計するプロジェクトに賭けてみることにした。しかし、これでも、どの会社とも契約を 結ぶことができなかった（面白いことにこのとき契約を結ばなかった会社の 1 つは、後に Java を大成功へと導いた Netscape を創設する Jim Clark の会社であった） 。 36 Chapter 1 Java への招待 Green プロジェクトはその形を First Person という会社に改めて、1993 年初頭から 1994 年 半ばまで彼らの技術を買ってくれる企業を探したが、まったく見つからなかった（このグルー プの創始者の 1 人であり、マーケティング活動のほとんどを手がけた Patrick Naughton は、こ の技術を売るために飛行機で 30 万マイルも移動したと言っている）。その後、First Person は 1994 年に解散された。 Sun Microsystems でこのような状況が展開されている間に、インターネットの World Wide Web がどんどん成長していった。この Web の世界で鍵を握るのは、ハイパーテキストを画面 表示に変換するブラウザである。1994 年には、ほとんどのユーザーがイリノイ大学のスーパー コンピュータセンターから 1993 年に発表された Mosaic という無償の Web ブラウザを利用し ていた（Mosaic の一部は Marc Andreessen という大学生がアルバイトで開発した。彼は後の Netscape の創始者の 1 人として富と名声を獲得した）。 Gosling は 1994 年半ばの Sun World のインタビューで、言語開発者が「我々はかなりすごい Web ブラウザを構築できるぞ。Web ブラウザは、現在のクライアント／サーバー環境で我々 が手がけてきたアーキテクチャへの非依存性、リアルタイム、堅牢性、安全性など、ワークス テーションの世界ではあまり重要とされていなかった利点を生かせる数少ないチャンスの 1 つ だ」と気づいたため、その案を採用してブラウザを構築したことを語っている。 実際のブラウザは Patrick Naughton と Jonathan Payne によって開発され、今日存在する HotJava へと発展していった。HotJava ブラウザは Java の威力を見せるために Java によって 書かれていた。しかし、それだけではなく、開発者は現在のアプレットに該当するものの威力 もよく知っていたために、そのブラウザが中間コードを解釈できるようにした。この「技術の 証明」は 1995 年 5 月 23 日の Sun Microsystems World '95 で発表され、現在も衰えることを知 らない Java の大流行をもたらしたのである。 Java がさらに広く使用されるようになったきっかけは、1995 年の秋、Netscape が次期バー ジョンの Netscape ブラウザ （Netscape 2.0） を Java 対応にすると決定したことである。Netscape 2.0 は 1996 年 1 月にリリースされ、それ以降の Netscape ブラウザはすべて Java 対応になっ ている。その他にも IBM、Symantec、Borland なども Java のライセンスを取得して関連製品 を提供している。Microsoft でさえ Java のライセンスを取得し、サポートしている。Internet Explorer は Java 対応になっており、Windows は Java 仮想マシンと共に出荷されている（ただ し、Microsoft は、最も新しいバージョンの Java はサポートしていないうえ、Java の実装は標 準から外れたものになっている）。 Sun Microsystems は、Java の最初のバージョンを 1996 年初めにリリースし、その 2、3 か 月後に Java 1.02 が続いた。これによりユーザーは、すぐに Java 1.02 がシリアスなアプリケー ションの開発向きではないことに気づいた。もちろん、画面の中で振動するテキストは作成で きるが、Java 1.02 では印刷も実行できなかった。簡単に言うと、Java 1.02 はまだ主要な開発言 語としては未完成だったのである。 1996 年の初めの数か月は、Java の将来的な機能に関する発表がちらほらとあっただけだっ た。しかし、1996 年 5 月に San Francisco で開催された JavaOne カンファレンスで、Java の 将来に関する全体像が明らかにされた。JavaOne で、Sun Microsystems が、コードの修正と 1.6 Java に関する一般的な誤解 37 新しいライブラリの開発を続けるという Java の将来的なビジョンを明確に述べたのである。当 時、最悪の場合、これが実現するまでには何年もの月日を要するのではないかと思っていた。 しかし、すべてのビジョンが実現したわけではないが、驚くべきことにそのほとんどが Java 1.1 で、しかもこんなに短い間に実現されたことを現在嬉しく感じている。 1998 年の JavaOne カンファレンスのビッグニュースは、発表間近の Java 1.2 であった。こ の新しいバージョンは、初期のおもちゃのような GUI やグラフィックスのツールキットを置き 換える、洗練され、かつ拡張性の高いもので、以前のバージョンよりも「一度書いて、どこでも 実行」というスローガンにずっと近づいている。1998 年 12 月、リリースされて 3 日後にその名 前が Java 2 に変更された。 それ以来、中核の Java プラットフォームは安定している。Java 2 SDK （Software Development Kit）, Standard Edition Version 1.3（J2SE 1.3）という、覚えやすい名前の現行リリースは、初 期の Java 2 のリリースを改良し、いくつかの新しい機能が追加され、パフォーマンスが改善 され、もちろん非常に多くのバグが修正されている。現在はこの安定した基盤のもと、Java 2 Enterprise Edition（J2EE）や Java 2 Micro Edition（J2ME）のような、高度の Java ライブラリ が開発されている。 1.6 Java に関する一般的な誤解 次に、よく見られる Java に関する間違った見解とそれに対するコメントをまとめる。 ■ Java は HTML の拡張である。 Java はプログラミング言語であり、HTML は Web ページに表示する構造を表す手段である。 Java アプレットを Web ページに載せるための HTML 記述の拡張があるというだけで、Java と HTML にはまったく共通点はない。 ■ Java は簡単に勉強できるプログラミング言語である。 Java のように強力なプログラミング言語の中では、Java ほど簡単なものはない。言語の難 易度を語る場合、おもちゃのようなプログラムを作ることの容易さと本当にシリアスなアプリ ケーションを作成することの難しさを分けて考えなければならない。また、本書の最初の 4 章 だけが Java 言語の構文について説明していることも考えてほしい。残りの章はすべて、Java のライブラリを利用してどのように Java プログラミングを行うかについて解説している。Java ライブラリには何千ものクラスとインターフェイスおよび何万もの関数が含まれている。幸い にも、そのすべてを覚える必要はないが、Java を現実的に使用するとなると驚くほどの数の機 能を記憶しておく必要がある。 ■ Java はプログラミングのための簡単な環境を提供する。 Java SDK は、コマンドラインツールに精通しているユーザーを除けば簡単に利用できる環境 ではない。よくできたデバッガが組み込まれ、統合されたエディタ、コンパイラ、ドラッグア ンドドロップ式のフォームデザイナを持つ統合開発環境もあるが、少し複雑で初めて使用する 際には困ってしまう。これらのツールは数百行にもおよぶコードを自動生成する。初めて Java 38 Chapter 1 Java への招待 を勉強するときに、コンピュータが自動生成した数百行のユーザーインターフェイスのコード に「修正禁止」などというコメントを見つけても喜ぶとは思われない。Java を勉強するときに はやはり自分の一番好きなテキストエディタを使用するのが一番であるということがわかった ため、本書ではその方法を採用している。 ■ Java はすべてのプラットフォームにおける普遍的なプログラミング言語になる。 これは論理的には可能であり、Microsoft 以外のすべてのベンダーが確かに望んでいることで はある。しかし、すでに Web ブラウザやその他のデバイスでは実行できないが、デスクトップ 上で動作する完成されたアプリケーションも数多く存在する。また、これらのアプリケーション は依存するプロセッサとネイティブのユーザーインターフェイスライブラリの実行速度を最大 限に活用しており、他の重要なプラットフォームにも移植されている。このようなアプリケー ションとして、ワードプロセッサ、画像エディタ、Web ブラウザなどがある。これらのアプリ ケーションは C や C++で書かれており、Java で書き直すメリットなどはエンドユーザーには まったく関係がない。また、短期的には Java で書かれたもののほうが実行速度が遅く、威力も 小さく、ファイルの種類も互換性のないものが多いためにかなり不便に感じる。 ■ Java は単なるプログラミング言語である。 Java はすばらしいプログラミング言語である。ほとんどのプログラマは C や C++よりも Java のほうを好む。しかし、これまでのすばらしいプログラミング言語にも、それほど広範囲に支持 を得なかったものも多く、その反対に C++や VB など、短所の多い言語でも広く普及している。 これはなぜだろうか。プログラミング言語の成功はサポートシステムの使い勝手のよさで決 まり、構文の美しさとはあまり関係がないと考える。実装するために必要な機能を持つ便利な 標準ライブラリを備えているだろうか。優れたプログラミング環境やデバッグ環境を提供する ツールを設計するベンダーが存在するだろうか。言語とツールはコンピュータの基本構造に統 合されているだろうか。Java はネットワーク処理やマルチスレッド処理など、以前は難しかっ た機能をクラスライブラリを使用して簡単に実装できるため、サーバー上のアプリケーション の構築で特に成功した。また、Java ならポインタのエラーが減るため、プログラマの生産性の 向上が可能であることも大きな利点だ。しかし、これらの特徴はどれも成功の鍵ではない。 これは特に移植可能なライブラリの登場を脅威に感じているベンダーにとっては非常に重要 なことである。このようなベンダーは Java に「単なるプログラミング言語」であるというレッ テルを貼り、Java から派生した構文および互換性や移植性のないライブラリを使ったシステム を提供して Java を無視しようとする。その結果として、VB と直接競合する製品にはなるが、 Java とはほとんど無関係の言語が誕生するのである。 ■ Java はインタープリタ言語であるため、特定のプラットフォームで稼働するシリアスなアプ リケーション向けには実行速度が遅すぎる。 多くのプログラムは、ユーザーインターフェイスとのやり取りやネットワーク接続からのデー タの待機にほとんどの時間を費やす。また、すべてのプログラムは、アプリケーションが書か れている言語に関係なく、マウスのクリックを適切な時間で検知する。Java SDK で提供されて 1.6 Java に関する一般的な誤解 39 いるインタープリタが CPU の特性を最大限に生かしていないのは事実である。ただし、JIT コ ンパイラが提供されている環境であれば、普通にバイトコードを実行すればパフォーマンスの 問題は起こらない。さらに Java はネットワーク越しのプログラムを書くには最適である。これ までの実績により、たとえ暗号化などの負荷の高い処理でも、Java はネットワーク接続のデー タ転送速度を十分なレベルに保持できることが示されている。つまり、Java の処理がデータの 転送速度より速ければ、C++が多少 Java より速くてもあまり関係ないのだ。Java はプログラ ミングが簡単で、しかも移植可能であり、コンパクトである。そのため、Java はネットワーク サービスを実装するときに最適な言語となる。 ■ すべての Java プログラムは Web ページで実行される。 すべての Java アプレットは Web ブラウザで実行される。「ブラウザで実行される Java プロ グラム」がアプレットの定義である。しかし、Web ブラウザから独立して実行されるスタンド アロンの Java プログラムを書くのももちろん可能であるし、実に便利だ。これらのプログラム は通常アプリケーションと呼ばれ、完全にプラットフォームから独立している。つまり、ある Java アプリケーションを別のプラットフォームに移動してそのまま実行できる。Java は C++ よりも便利でプログラミングエラーの可能性が少ないため、プログラミング言語としてよい選 択肢である。また、JDBC（Vol.2 を参照）などのデータベースのアクセスツールと組み合わせる とさらに強力な選択肢となる。Java は初めて言語を習う人にも明らかによい言語である。 本書のプログラム例はほとんどがスタンドアロンプログラムである。アプレットも実に面白 いが、スタンドアロンの Java プログラムのほうが、実際面では重要かつ便利である。 ■ Java アプレットにはセキュリティ上の大きなリスクがある。 これまでに Java のセキュリティシステムの障害に関するレポートが広く紹介されている。ほ とんどが特定のブラウザの Java の実装に関するものだ。研究者はこれを非常に強力で洗練さ れた Java のセキュリティモデルに対して欠点を掘り出そうとする動きであると見ている。こ ういったレポートの技術的な誤りはただちに修正され、知る限りでは Java のセキュリティモ デルにおいて修正すべき点はまだ 1 つも見つかっていない。これをはっきりと見定めるために は、Windows の実行ファイルや Word のマクロに対するウィルス攻撃によって深刻な障害が数 えきれないほど発生しているわりに、脆弱性を指摘する声が驚くほど少ないことを心にとめて おくべきだ。また、Internet Explorer の ActiveX のメカニズムは非難の対象となるべき特性を 備えているのに、その非難を実に巧妙に逃れてきたことはあまりにも明白である。 中には Java を企業のブラウザで実行不能にして ActiveX コントロールや Word 文書のみを ダウンロードできるようにするシステム管理者まで存在する。これは実にばかげた話で、現在 悪意のある Java アプレットをダウンロードして被害を受ける可能性は、飛行機事故で命を落と す可能性に匹敵するほど少ない。反対に Word 文書を開いて被害を受ける危険は、自動車がた くさん走る高速道路を歩いて横断するときの危険に匹敵する。 ■ JavaScript は Java をシンプルにしたものである。 JavaScript は Web ページで使用できるスクリプト言語で、最初は Netscape によって開発さ 40 Chapter 1 Java への招待 れ、LiveScript と呼ばれていた。JavaScript の構文は Java を彷彿とさせるが、実はまったく関 係がない。JavaScript のサブセットは ECMA-262 として標準化されているが、実際の作業に 必要な拡張機能はまだ標準化されておらず、その結果 Netscape と Internet Explorer の両方で 稼働する JavaScript コードを書くのは面倒な作業となっている。 ■ Perl を使って CGI のスクリプトを書くよりも Java を使用すべきである。 これは半分正しい。もはや Perl を使うべきではなく、サーバーサイドの処理に対して CGI ス クリプトを使うべきではない。Java サーブレットのほうが優れたソリューションである。サー ブレットは CGI スクリプトよりも効率的に動作し、ユーザーはサーブレットを実装するために 真のプログラミング言語である Java を使用できる。 ■ Java はクライアント／サーバーコンピューティングに革命をもたらす。 これは現実的で、実際 Java はクライアント／サーバーコンピューティングで最も活躍してい る。BEA の Weblogic などのように完全に Java で構築されているアプリケーションサーバー も少なくない。Vol.2 で取り上げる JDBC は、Java を使ったクライアント／サーバー開発をよ り容易にする。サードパーティによるツールの開発が継続されており、Net ライブラリがネッ トワークプログラミングをより簡単にしたように、Java によるデータベース開発がさらに簡単 になることが期待される。リモートオブジェクトへのアクセスは C++よりも Java のほうがは るかに簡単である（Vol.2 を参照）。 ■ Java はコンポーネントをベースとしたコンピュータモデルを実現する。 コンポーネントについての論議にはさまざまな意見が飛び交う。GUI プログラムですぐに 使用できる ActiveX コンポーネントなどのビジュアルなコントロールに関して、Java 1.1 は JavaBeans を用意している（Vol.2 を参照） 。Java ビーンは基本的に ActiveX コンポーネントと 同様の処理が可能である。ただし、Java は自動的にクロスプラットフォームになるという違い がある。サーバーサイドでは、再利用可能なエンタープライズビーンをさまざまなアプリケー ションサーバーで利用できる。Wintel プラットフォームにおける ActiveX コンポーネントの市 場のように、Java ビーンのコンポーネントの市場が形成されることも考えられる。 ■ Java を使えば、コンピュータを 500 ドルのインターネット機器と置き換えることができる。 一部ではこれが実現することが強く信じられている。我々としてはローカルストレージを持 たない制限付きのマシンを取り入れて、強力で便利なデスクトップをユーザーが捨て去るとは 考え難い。しかし、「Zero Administration 構想」 （企業ユーザーはコンピュータの管理を自分 では行わないという構想）によりビジネス用のコンピュータを所有するコストを削減しようと いう場合には、Java 対応のネットワークコンピュータが実際的な選択肢となる。 また、我々は、インターネット機器をデスクトップへのデータの移行が可能な付加装置である ととらえている。価格が適正であれば、電子メールやニュースを読める画面を備えたインター ネットアクセス用の機器がほしくなるのではないだろうか。Java のカーネルは非常に小さいた め、電話やその他のインターネット機器には最適である。