|
|
1998/9/17
●Javaはマルチプラットフォームに対応したソフトウエアを作成可能なソフトウエアの実行環境です。ネットワークに強いライブラリを持つなど、1つのまとまったソフトウエア実行環境がOSを超えて構築されています。
●この章では、Javaについての一般的な知識に加えて、JavaがMacintosh環境でどのように利用できるのかを説明します。
●Javaのメリット、これまでの経緯、そして現在何に注目されているかもまとめておきます。Javaの開発で知っておきたい基本的なことも説明しましょう。
●Macintosh環境でのJavaの実行方法や開発環境について、MRJやSDKの内容、そして開発ツールの比較などから解説します。
●Macintoshで開発する意味についても最後にまとめておきます。
Javaについての一般的なことをひととおりまとめておきましょう。Javaはどのようなメリットがあり、なぜこれほど注目されているかを解説します。これからJavaをやってみたいという方や、現状を知りたい場合には目を通して下さい。すでに基本的なことをご存知の場合は、1-4節「Mac OSのJava実行環境」からご覧になられると良いでしょう。
Javaという単語が示している本来の意味はプログラミング言語です。つまりJavaはCやC++の流れをくむプログラミング言語なのですが、昨今のニュースなどで扱われるJavaという言葉は、もっと広い意味で使われています。Javaというプログラミング言語をベースにして作成されるソフトウエアの利用形態全般を指して、現在では「Java」と呼んでいると言って良いでしょう。Javaは単にアプリケーションを作る1つの言語という枠組みを超え、異なるOSの上でも同一のソフトウエアが機能するなど、従来にはない機能をもったソフトウエア環境なのです。その意味では、OSであるとも言えます。既存のOSの上に構築された独自のOSでもありますし、JavaOSとして独立したOSも開発されています。
Javaが本格的に世の中に登場したのは、1996年の初頭です。Java開発の素材や実行環境のおおもととなるJDK 1.0のリリースが、96年の1月なのです。その時期、JavaはWebブラウザで動くソフトウエアであるアプレットにフォーカスしていました。Webというシステムは、世界中の文書をリンクしてつなぐなど、従来のペーパーによる文書とは異なる独自の特徴を持ち、こうした文書をブラウザさえあれば、OSやパソコンの機種に関係なく参照できました。また、文書自体はHTMLとして、テキストで記述できる手軽さもあります。しかし、Webの本来の機能だけを使った文書は、文字やグラフィックスをレイアウトする機能しか利用できません。当然、HTML文書としての作成機能にはあきたらず、たとえば動きを付けたり、ユーザーの操作を受け付けるなど、もっといろいろなことをWebという基盤をもとにやりたくなってきます。そのためにいろいろな仕掛けが考えられたのですが、その中でもJavaは汎用的なプログラミングが可能なことで、大きな可能性に期待が集まりました。一言で言えば、Webブラウザで表示した文書内で、ソフトウエアが機能するわけです。
ただし、97年頃からは、整備されていないライブラリから来るJavaのシステムとしての完成度の低さがネックとなり、またShockwave、Flashといった、インタラクティブで動きのあるWebページをより作りやすくするシステムが次々と登場したことによって、このような用途での注目は現在では浴びていません。FlashやShockwaveはWebブラウザではプラグインが必要ですが、OSあるいはブラウザにバンドルされる傾向にあり、Web上でのマルチメディアプレゼンテーションの標準プラットフォームになりつつあります。
このような状況を背景にJavaは当初注目されるきっかけとなったインターネットの分野にとどまらず、もっと広い範囲で利用できるのではないかと期待されてきました。たとえば、業務システム開発や、あるいは組み込みシステムなどでの利用に注目が集まっています。また、分散オブジェクト開発のツールとしてもJavaは有力視されています。
つまりJavaはプログラミング言語なのですが、見方を変えればJavaはOSそのものです。既存のOSに組み込まれた独自のOSなのです。既存の特定のOSを超えてJavaという独自のOSで機能するソフトウエアを作るということが可能なのです。もはやJavaはインターネットという枠組みを超えて大きく広り新たな発展をし始めていると言えるでしょう。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-1 Javaの役割の拡大
まず、Javaをプログラミング言語として見てみましょう。Javaをプログラミング開発言語として見た場合、従来の開発言語とどこが違い、どんな点にメリットがあるかを検討しましょう。
JavaはC++をベースに開発されたもので、基本的な記述方法は、CあるいはC++と共通な部分があります。特に変数や繰り返し、条件分岐などの基本的な部分はほとんど同じと言ってよいでしょう。そのため、CやC++の経験者にとって、Javaはそれほど違和感がありません。
Javaプログラミングの特徴を一言で言えば、オブジェクト指向プログラミングを全面的に取り入れているということでしょう。
Cはオブジェクト指向プログラミングの機能はほとんどないと言えるのですが、C++はオブジェクト指向プログラミングの中心的な開発言語となっており、開発ではもっともよく利用されています。しかしながら、C++は拡張を繰り返したために、高機能ではあるものの、非常に複雑で難しい言語になってしまいました。JavaはC++よりもずっとシンプルでわかりやすい構成になるように改良されています。その反面C++よろは機能がないと言うこともできますが、C++にあってJavaにはない機能を補いう補う包括的な機能もあり、JavaはC++と概ね同等のことができると言えます。また、シンプルな言語体系の方が理解しやすく、また、プログラム自体も筋の通ったものになりやすい傾向があります。こうした言語としての分かりやすさ、そこから派生して生産性の高い言語であるというのがJavaの特徴です。
Javaの特徴は、データを一般的に「オブジェクト」として扱うことです。オブジェクトは言い換えれば構造を自由に定義できる柔軟なデータです。逆に言えば、Javaではオブジェクトとして定義しないとプログラム中でのデータの利用は非常にやりにくくなります。オブジェクトとして一元的にいろいろな形式のデータを保管したり処理をするというのがともかく基本になります。
JavaではC言語での「ポインタ」というデータはないのですが、「オブジェクトへの参照」というデータを変数に代入しておくことはできます。
Cでは、「ポインタ」というデータのアドレスを利用して、データにアクセスするような手法がよく利用されていました。しかし、ポインタはプログラムを分かりにくくすると同時に、誤って関係のない部分をアクセスして書き直し、暴走する原因にもなっていました。しかしながら、Javaはそうした心配はありません。
Javaのオブジェクト参照は、物理的にはオブジェクトを保存したメモリへのアドレスということになるのですが、Javaではオブジェクトへの参照は演算対象になりません。オブジェクトへの参照は他の変数に代入することしかできないので、ポインタ演算のようなことはできません。オブジェクトへの参照が保存されているということを概念的に理解していればいいのです。
Javaにも配列はありますが、CやC++と使い方は異なり、オブジェクト的に扱えるようになっています。
こうした特徴をメリットと見るか、デメリットと見るかはもちろん意見が分かれるでしょうが、やはりメリットと見るべきでしょう。分かりやすく安全なソフトウエアにつながるからです。しかしながら、オブジェクト指向を全面的に採用しているために、うまくオブジェクトを定義しないと、プログラム自体が混乱するということもあります。
Javaでソフトウエアを組む場合、言語本来の機能だけを使って組むわけではありません。Javaに限らずOSをベースにしたプログラム開発では、OSの機能やライブラリなどを利用したプログラミングが必要です。したがって、プログラミングにあたってはJavaの文法うんぬんよりも、ライブラリの使い方の知識の方が膨大になり、必要となります。
Javaでもやはりライブラリが用意されています。特にコアになる基本的なライブラリは、Javaの供給元であるSun Microsystemsより供給されており、標準化されています。これらJavaで使えるライブラリは、すべてがクラスとして定義されたオブジェクト指向のライブラリになっています。つまり、ライブラリを利用する上では、オブジェクト指向プログラミングをしなければならないのです。ここでも、全面的にオブジェクト指向が取り入れられていることになります。この基本的なライブラリについては、後で検討しましょう。
プログラムでは何らかの形で必ずメモリを必要とします。特にCやC++ではメモリを確保し、そして解放するということを行わないと正しくメモリが利用できません。メモリの取得はともかく、確実に解放するというのは、プログラムする上ではかなり難しい作業です。処理途中のエラーなどで、確保されたメモリが使われずに放置されることは実際によくあることです。
Javaではメモリの解放という作業は不要で、全面的に自動的に行われます。取得は明示的に行いますが、不要になったかどうかはそのオブジェクトを利用しているかどうかがチェックされ、いらなくなったら自動的に解放するということを行っています。そのため、プログラマはともかく必要なときにメモリを確保しさえすれば良いのです。結果的に、プログラムは非常に作りやすくなります。
CあるいはC++でのプログラミングと、Visual BasicなどBASIC言語あるいはマクロ系のプログラミングとの1つの決定的な違いに、メモリ利用をプログラミングしないといけないかどうかがあります。BASIC言語はそれが不要なために、気軽にプログラミングができるという面もあります。JavaではそうしたBASIC言語的な気軽さと、CやC++に匹敵するオブジェクト指向あるいは高性能なソフトウエアをつくり出すという両方のいいところを併せた特徴を持っていると言えるでしょう。
なお、不要になったメモリ領域を解放することは「ガベージコレクション」と呼ばれます。この作業自体は自動的に行われますが、そのために時間を使ってしまい、ソフトウエア全体のパフォーマンスが低下するというデメリットもあります。
Javaの基本的なライブラリには、スレッドを利用したマルチタスクの機能が組み込まれており、気軽にマルチタスク処理を組み込むことができます。これを利用して非同期処理を組み込むことができますし、アニメーションのような画像処理も比較的手軽にできるようになっています。
Javaをソフトウエアの実行環境としてみてみます。やはりいちばんの特徴は「マルチプラットフォーム」でしょう。Javaのデビューのときにもっとも注目されたのがこの点で、同じソフトウエアがWindowsでもMac OSでも、UNIXでも実行できるということです。
C言語で標準ライブラリだけを使ったプログラムなら、若干修正の必要はありますが、どのOSでも機能します。しかしながら、Windowsでコンパイルして作ったEXEファイルは、Mac OSやUNIXでは実行できません。また逆も同様です。
Javaのソフトウエアは、Windowsで作った実行可能なファイルを、Windowsではもちろん、Mac OSでもUNIXでもそのまま実行することができます。「プログラムのソースに手を加えずに、各OSごとにコンパイルして実行プログラムを作成できる」というレベルではないのです。Mac OSで作った実行プログラムでも、原理的にはWindowsでもUNIXでも機能するというのがJavaで言う「クロスプラットフォーム」という特徴なのです。このような特徴を「バイナリ互換」とも呼んでいます。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-2 Javaにおけるバイナリ互換
通常、CPUやOSが違うと、実行可能なバイナリの形式も異なり、共通には使えません。ではJavaならなぜできるかと言えば、簡単に言えば、OSやCPUとは別に共通の「Java実行環境」を構築しているからです。つまり、WindowsやMac OSには、Javaを実行するためのコンピュータが内蔵されています。そのコンピュータはソフトウエアで実現されており、バーチャルマシン（VM：Virtual Machine）あるいはVMなどと呼ばれています。
このVMがOSに内蔵されていれば、同一のバイナリファイルが、どのOSででも実行できるのです。もちろん、各OSにVMが用意されていないとJavaは実行できませんが、現実にはWindowsもMac OSも、VMをブラウザメーカーあるいはOSメーカーによって積極的に構築されており、結果的に世の中に存在するほとんどのパソコンで、JavaのVMが機能しているという状況になっています。
また、VMそのものに加えて、各VMの実行環境で、クラスライブラリが提供されています。VMとセットにして提供されるべき基本的なクラスライブラリがしっかり定義されており、それが十分にOS機能を果たしているため、JavaはOSに依存しない共通の基盤を持ったOSとして機能することになるのです。
なお、VMは完全に1から構築されたものではなく、部分的に各OSの機能を利用します。たとえば、Javaのソフトウエアがウィンドウを表示したりキー入力を受け付けるときには、実際には背後で稼動しているOSの機能を流用します。つまりクラスライブラリの見えない部分でOSの機能を利用しているのです。このようにJavaには稼動しているOSの機能を利用するメカニズムも用意されています。ただし、一般のプログラマはその部分を扱う必要はなく、クラスライブラリの機能だけを見ていればいいでしょう。
ちなみに先程触れたように、Javaはデビュー時にはWebブラウザでの利用にフォーカスされていたため、Webブラウザ自体にVMが組み込まれました。Netscape Communicator/Navigatorでは、ブラウザ自身が用意したVMしか利用できません。Internet Explorerはブラウザ向けに用意したものとOSに組み込んだものを切り替えることができます。NetscapeのVMのうち、Macintosh版はVer.4.5でも最新版Javaのライブラリ機能にすべては対応していません。NetscapeもいずれはOSのVMを利用するような形態になる予定です。
JavaはVM上で機能することから、OSに依存しないソフトウエアを、しかもバイナリ互換で作成できるのが大きなメリットです。しかし、逆にこのことがデメリットにもなっています。VMを実現するには、Javaプログラムのバイナリコードを実行するCPUをエミュレーションすることになり、どうしても実行速度は遅くなります。つまり、バイナリーコードを実際にCPUが実行するのではなく、搭載しているCPU上のプログラムを使ってあたかもJava対応CPUが機能しているかのように見せ掛けているわけです。
ただ、VMであるために、通常のアプリケーションなどに比べて実行速度が低かった点については年々解決されてきています。1つの技術は「JIT（Just In-Time）コンパイラ」と呼ばれるもので、Symantec社の製品が有名です。これは、Javaのバイナリーコードを実行直前に、稼動しているCPU向けに書き直して、そのパソコンで動いているCPUのコードに翻訳して実行するというものです。実際にはCPU本来のバイナリで実行するので、スピードは速くなります。たとえば、Mac OSだと、Javaのバイナリコードが、PowerPCの実行可能なコードに翻訳されて実行するわけです。最近のVMにはJITも標準で組み込まれるようになり、実行速度は目に見えて改善されています。ただし、JITの場合は、実行前にコードを翻訳する時間が必要になり、CPUがあまり高いパフォーマンスでない場合には、ソフトウエアの起動に時間がかかるようになってしまいます。
さらに、99年には、HotSpotと呼ばれる記述が実用化される予定です。これは言うならば動的コンパイラであり、実行時間がかかる処理を順次稼動しているCPUのコードにコンパイルするような処理を実現します。また、メモリー利用や複数のタスクの実行機能などに改良が加えられ、とにかく効率の良いソフトウエアの処理が実現するはずです。
近い将来、このようにエミュレーションで動くVMであるために実行速度が遅いというJavaの現状のデメリットは、解決されると期待して良さそうです。
Javaで作成したソフトウエアは、動的なリンク機能により、実行するときに必要なライブラリを探して結合することができます。CやC++でも動的ライブラリは不可能ではないのですが、一般にはそうした機能はOSの機能などとして提供されています。通常、コンパイラとしてはあらかじめライブラリを取り込んで、実行ファイルを作ります。
Javaは、コアになるクラスライブラリについては、コンパイルしてバイナリを作成するときには一体化しません。実際に実行する段階で、その場にあるライブラリの本体を呼び出して結合し、実行します。従来のアプリケーションでは、ライブラリを実行ファイルに含める必要があったため、シンプルなアプリケーションでもそれなりに大きなサイズになっていました。しかしながら、Javaではライブラリをいっしょにしなくてもいいので、シンプルなものは非常に小さいサイズのファイルで事が足ります。
こうした機能はインターネットを経由して取り込まれたアプレットの実行において、ダウンロード時間の節約になるというメリットにもつながります。いずれにしても、重複したライブラリ利用は避けることができるというわけです。
先にJavaの言語としての特徴として、「ポインタ」がないことを説明しました。C言語のようにポインタ演算でデータの位置を決める場合、バグやプログラマが想定していない状況が起きた結果、データ範囲外を読み書きしてしまう可能性が出てきます。そうすると、ソフトウエアの動作が不安定になることがあります。Java言語ではデータの範囲外をアクセスするようなプログラミングはほとんど不可能なので、関係ないところを読み書きするようなプログラムは書くことができません。これだけでも、データやロードしたソフトウエア自体を保護する機能が働いていると言えるでしょう。
また、Javaの実行環境では「セキュリティ」という考え方が導入されています。VMの動作として実行可能な範囲を制限できるのです。たとえば、ファイルの読み書きの処理は、Webページに組み込まれるアプレットではできない処理です。仮にできるようになっていれば、Webページを読むと、ハードディスクの中身を書き換えるというアプレットも作成できますが、悪意を持ったソフトであれば被害も大きくなります。また、悪意はなくても動作が不安定だと何をするか分かりません。そこでWebブラウザで開いたWebページにあるアプレットは、そのページ内、あるいは同一サーバーに対してのみ処理ができるという制約が付けられています。こうした制約を施すというセキュリティがあるために、Javaで作成したアプレットは安全なソフトウエアとして機能することが保証できるのです。
Javaではいろいろな形態のソフトウエアが作成可能ですが、現状では、アプリケーションとアプレットというのが一般的な形です。最近はサーバーで機能するサーブレットも作成できるようになってきています。また、コンポーネントとしてのJavaBeansも注目を集めています。これらについて説明をしましょう。
アプレットはJavaの登場時から存在するソフトウエアの形態で、Webページに埋め込んで利用されるものです。以下に説明するように、従来にはない形態のソフトウエアであったために、Javaに注目が集まったと言っても過言ではありません。
アプレットは、拡張子が.classというファイルに保存されたJavaの実行形式のバイナリファイルを、Webページ内で機能させたものです。なお、アプレットは.classファイルにあるのが一般的ですが、アーカイブファイルの.jarファイルに存在することもあります。WebページはHTMLテキストでその内容を記述できますが、APPLETタグを利用して、アプレットをWebページに埋め込みます。見かけ上はJPEGなどのグラフィックスと同じように長方形の範囲を確保し、その中でソフトウエアの実行が行われます。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-3 Webページに埋め込まれたアプレット。下半分のボックスがアプレットで、テキスト入力枠や、ボタンなどが配置されている
アプレットの.classファイルは、HTMLファイルと同じサーバーに置かれます。画像ファイルもサーバーに置かれますが、それと同じイメージで考えて下さい。HTMLテキストの中にAPPLETタグがあると、サーバーからクライアントのブラウザにアプレットがダウンロードされます。そして、Webページを参照しているクライアントの中にあるVMを利用して、アプレットが実行されます。
このとき、WebブラウザがMac OSで機能していても、Windowsで機能していても、サーバーから同一の.classファイルがクライアントにやってきます。VMという共通の基盤が各OSあるいはブラウザに用意されているので、同じ.classファイルが違うOSで機能するということになるのです。
サーバー上で公開されているアプレットは、場合によっては不特定多数のクライアントで実行されます。そこでセキュリティを確保するために、アプレットで利用できるVMの機能は制限されています。その制限はブラウザである程度はコントロールできますが、中にはファイル処理など絶対にできないこともあります。
また、アプレットはJavaの場合、極めて簡単にプログラミングできる点も見逃せません。アプレットの原形にあたるクラスが用意されているので、そのクラスを継承し
て、望む機能を追加するだけでアプレットは作成できます。サーバーからのダウンロードするなどのややこしいことは全部WebブラウザとVMがやってくれます。
Javaでも一般的なアプリケーションを作成できます。Mac OSでは、ダブルクリックして実行可能なごく普通のアプリケーションを作成できます。Windowsでは、EXEファイルを作成することが可能です。ただし、一般にはそのOSで実行可能になっているファイルをそのまま別のOSに持って行っても実行することはできないでしょう。たとえJavaのバイナリ部分はどのOSで動いたとしても、アプリケーションとして実行させる部分はファイルに含まれることになり、それがOSごとに違うからです。
だからといって、OSごとにアプリケーションを1から作る必要があるわけではありません。Java VMは共通なので、Javaのソースコードは、Mac OS、Windows用で同一のものを利用できます。それをもとに、Mac OS用のアプリケーションを作ったり、Windows用のアプリケーションを作るということをすればいいわけです。ただし、1つの開発ツールでMac OS用とWindows用の実行可能ファイル作成ができるとは限らず、それぞれ別の開発環境を使わないといけないかもしれません。
なお、Javaのソースコードをコンパイルした結果は.classファイルに保存されますが、ファイルの拡張子についてはこのようにアプレットだけでなくアプリケーションも同様です。
Mac OSにもWindowsでも、.class形式のアプリケーションを実行するツールは存在します。それらのツールを利用すると、同一の.classファイルのアプリケーションが、Mac OSでもWindowsでも実行できます。
Webページで、入力するテキストボックスなどがあって、閲覧者の入力を受け付けるものも見られます。そのようなページの多くは「ボタンをクリックすると入力データがサーバーに送付され、サーバー側でプログラムを実行して、入力データをデータベースに保存する」などの処理を行うようなメカニズムをCGI（Common Gateway Inteface）で実現しています。このような、ユーザーのリクエストによってサーバー上で実行するようなソフトウエアも、Javaで作成できるようになっています。こうしたソフトウエアを「サーブレット」と呼んでいます。
サーブレットを実行するには、サーバーにVMが組み込まれていることに加えて、Webサーバーがサーブレット実行の機能を持って行なければなりません。一般には、Webサーバーがサーブレットを実行するという手順になります。もともとサーブレットを実行可能なWebサーバーもありますが、サーバーのプラグインとしてサーブレットの実行環境が提供されている場合もあります。現状ではむしろ後者の方が一般的なサーブレット実行の方法になるでしょう。
ソフトウエアを部品化することを「コンポーネント化」などと言いますが、Javaでは、JavaBeansという枠組みで、基本的なコンポーネント化の機能をサポートしています。JavaBeansに従ったソフトウエアの部品を「Bean」と呼んでいます。
通常Beanだけでは必要な機能は満たされません。Beanを組み合わせることによって、アプレットやアプリケーションを作ります。このとき、グラフィカルな開発環境などで部品として取り扱い可能な形式はJavaBeansとして仕様が定められています。開発環境で部品と部品を線でつないで、アクションに対する処理を選択するようなことを可能にするのがJavaBeansの1つの目的です。
さらに、たとえばサーバーで機能するソフトウエアを作るためのEnterprise JavaBeansのような規格も作られています。サーバーで実行されるソフトウエアはクライアントからのリクエストに応じた形式で必要な処理を行うので、その意味ではシステム全体から見ればソフトウエアの部品のように見えるわけです。こうした部品を作る枠組みがEnterprise JavaBeansということになります。
Javaを特徴付けるものとして、そのクラスライブラリがあります。クラスライブラリは誰もが自由に作ることができますが、基本になる部分はSun Microsystemsで開発され公開されています。基本部分は、いわばOSとしての機能と言っても良い部分です。
Javaが初期の頃は、基本クラスライブラリの機能が、一般的なOSに比べて目に見えて貧弱でした。しかしながら、Javaのリリースが進むにつれて、一般のOSにかなり近付いてきています。また、ネットワーク機能のように、一般のOSよりもより使いやすく充実した機能もあります。
こうした基本クラスライブラリは、アプリケーションやアプレットなどJavaソフトウエアを作るフレームワーク（枠組み、あるいはひな形）となります。もちろん、こうしたクラスライブラリを無視して独自に構築してもいいのですが、普通はそうはしません。与えられたクラスライブラリをいかにうまく利用するかと言うのがプログラミングの基本になります。基本クラスライブラリの内容についての概略を説明しましょう。
なお、いくつかのクラスを集めたものを「パッケージ」と呼んでいます。パッケージは概念的なものと思ってもいいのですが、実際には特定のクラスを集めるものとしてプログラム上で定義されているものです。
クラスライブラリの中には、Webブラウザに組み込むアプレットの原形であるAppletクラスが定義されています。アプレットとして機能するために必要なさまざまなものがすでに用意されています。アプレットは、このクラスを継承して作成します。極端に言えば、アプレットの中身をどうするかという記述だけを加えればアプレットは作成できてしまいます。しかも、テキストボックスやドロップダウンリストなどのユーザーインタフェースを構築するオブジェクトは、次に説明するAWTで定義されており、アプレットには簡単に追加できます。また、再描画処理も簡単に記述できます。このようにアプレット作成にはかなり最適化されているのは、当たり前と言えば当たり前なのですが、Javaの特徴としては顕著な部分です。
Javaでは基本的なデータとして整数のint型などは使えるのですが、データはオブジェクトとしてある意味では一般化した使い方をします。クラスライブラリでは基本的なデータ型のオブジェクトに加えて、オブジェクトを複数まとめるような使い方をするためのクラス定義などもあり、オブジェクトを利用するための基本的な機能も提供しています。
グラフィックス処理の中心になるのが、AWT（Abstruct Windowing Toolkit）と呼ばれるパッケージで、文字通りウィンドウ処理を行うものですが、現実にはもっとたくさんのことができると考えてよいでしょう。グラフィックス処理や基本的なGUIの一切を取り仕切るパッケージです。
まず、AWTにはウィンドウ表示のもとになる、一般的な画面表示領域を定義するクラスがあります。また、その中にオブジェクトを表示領域に簡単に加えることができるようなメカニズムを持ったクラスも定義されます。これらを利用して、テキストボックスやドロップダウンリストなどのクラスも定義されており、ユーザーインタフェースのオブジェクトを簡単に処理できるようになっています。
ただし、グラフィックス描画については、ごく基本的なことしか行なえません。複雑なグラフィック処理については、Java 2Dと呼ばれるSun Microsystemsより提供されるパッケージでサポートしています。
Javaのライブラリは「イベント」として、何か変化があったことを別のオブジェクトに伝達する手段を備えています。ユーザーインタフェースオブジェクトを使うときには、必ず利用することになるでしょう。たとえば、ユーザーがボタンを押したり、リストを選択したときなどにイベントが発生します。このイベントの扱いが、初期のJavaと、97年頃にリリースされたJDK 1.1とではやや異なっています。当然、後から出た方がより高機能なのですが、Macintosh版のNetscapeでは未だに新しいイベント処理がVMに組み込まれていません。ここは注意が必要なところです。
98年頃より、Swingという名称のパッケージ群がSun Microsystemsより提供され始めており、より高度なユーザーインタフェース構築のための機能が利用できるようになってきています。AWTでは限られていたオブジェクトの種類も、Swingでは豊富に利用できます。正しくは、SwingはJFC（Java Foundation Classes）というライブラリの一部分で、JFCにはさらにドラッグ&ドロップの扱いなども組み込まれます。
また、マルチメディアでは、ビデオ画像などを扱うJava Mediaや、3Dオブジェクトを扱うJava 3Dなども利用されはじめています。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-4 Swingのコンポーネントをデモンストレーションするアプリケーション
Javaにはファイルの処理を行うパッケージも用意されています。このパッケージには単純なバイト単位の入出力だけでなく、行単位の入出力を行う機能なども用意されていますが、どちらかと言えば基本的な機能が中心です。ドライブの情報などもアプリケーションなどでは知りたいところですが、そうしたOSに依存するような情報については標準のライブラリでは得ることができません。従ってパッケージで行なえるのは一般的なファイル処理に限られます。また、アプレットではファイル入出力がまったく利用できない点も注意が必要です。ただし、将来的には適切なセキュリティをかけた上で、アプレットでもファイル処理ができるようになるとされています。
Javaのライブラリを、一般のOSから見たときに大きく特徴付けているのがネットワーク関連のパッケージでしょう。Javaが注目され始めた当初はアプレットによってWebページで動く画面が作成できる点が強調されていましたが、TCP/IPをベースに通信するソフトウエアを簡単に作成できるという隠れた面も見逃せません。そのことがJavaがネットワークに強いと評価される大きな要因です。TCP/IPのソケットを簡単に用意でき、しかも、行単位の入出力などもできるので、電子メールを送付するようなプログラムくらいなら簡単に作成できます。
また、電子メールで言えば、JavaMailというパッケージにより、電子メールのやりとりも比較的簡単にプログラミングができます。ネットワーク、特にインターネットを使うプログラムとなると、Javaはだんぜん強味を発揮するようになります
データベースにアクセスするためのパッケージとして、JDBC（Java DataBase Connectivity）が用意されています。JDBC用のドライバを利用すれば、Javaのソフトウエアからデータベースエンジンにアクセスできます。SQL言語レベルの処理はもちろん、テーブルのデータをオブジェクトとして扱って処理するようなことも可能です。
Javaは分散オブジェクト環境での開発も視野に入っており、特に大規模な業務システムでの利用も始められているようです。オブジェクト間の通信では、CORBAをベースにすることもできるようになってます。また、RMI（Remote Method Invocation）として、別のマシンにあるオブジェクトのメソッドを呼び出すようなメカニズムも、分散オブジェクト環境を実現するのに使われています。そして、JavaIDLというパッケージで、CORBAなどのオブジェクトリクエストブローカー（オブジェクト間通信を行う基本システム）を利用した分散オブジェクト構築までが可能になっています。
JDKはJava Development Kitの略で、Sun Microsystemsによって開発されたJava開発のための基本となる素材を集めたものです。JDKがJava環境の正式なリリースで、その中には、開発ツール、基本クラスライブラリ、ドキュメントなどが含まれています。JDKはそのバージョンとともに記述されるのが一般的で、バージョンによりサポートされている機能が異なります。いずれにしても、JDKというのは、Java開発の中ではよく出てくる言葉です。
JDKには基本クラスライブラリが含まれており、JDKを入手することによって、クラスライブラリが手に入ります。従って、そのクラスライブラリを使ったプログラムの作成もできます。あるいは、配付されたクラスライブラリを利用するソフトウエアの実行もできるようになるというわけです。
Java開発ツールのメーカーは、JDKをライセンスされており、自社の開発ソフトにJDKとしてリリースされたクラスライブラリを含めることができます。しかしながら、一般にはJDKに対応した開発ソフトが発売されるのは、そのJDKがリリースされてから時間が経過した後です。Sun Microsystems以外のメーカーより供給される開発ツールを使いながらなおかつJDKも入手する理由として、新しくリリースされるクラスライブラリをなるべく早く手に入れたいということが挙げられます。
また、JDKにはJavaのコンパイラなど、開発に必要なツールが含まれています。市販の開発ツールを利用するまでもなく、JDKだけでプログラムを実行可能な形式にすることができます。SunのWebページなどからダウンロードできるので、事実上フリーの開発ツールとしてJDKが存在すると言えば良いでしょうか。
JDKはコンパイラだけでなく、いろいろなツールを含んでいます。アーカイブファイルの処理をするものもありますし、分散オブジェクト開発用のツールなどもあります。さらに、作成したプログラムの解説ドキュメントを作成するJavaDocと呼ばれるツールもJDKに含まれます。クラスライブラリの解説ドキュメントを見たことがあるかもしれませんが、プログラム中のクラス定義から、そのクラスにあるメソッドなどの使い方を解説したHTML文書を作成する機能もあります。
初期の頃は、Macintosh版のJDKもありましたが、現在は、AppleがリリースするMRJ SDK（1-5「Mac OSでのJava開発環境」を参照）がそれに取って変わっています。Sunは、Solaris版とWindows版のJDKをリリースしており、それとは別に、SunとAppleが協力して、JDK相当のMRJ SDKをリリースしています。MRJについては後で詳しく説明しましょう。
Mac OSではMRJというJavaの実行環境がOSに統合されて提供されています。MRJについて説明しましょう。また、Mac OSで動作するMRJ以外のJava VMについても説明します。
Mac OS Runtime for Java（MRJ）は、Appleが提供するJavaの実行環境です。MRJはOSに統合される形でJavaのVMを提供しており、これがMac OSでの代表的なVMであると言えるでしょう。正式版としては、Ver.2.0がリリースされていますが、Early ReleaseとしてVer.2.1の配付が98年5月より始まっています。Early Releaseは一種のベータテスト的なもので、開発途中の状態で公開することで、対応ソフトの開発を促がそうという意味あいがあります。略して「EA版」あるいは「MRJ Ver.2.1ea2」のように呼ばれます。後者は、MRJのVer.2.1のEarly Release 2版であるという意味です。
Ver.2.0の稼動環境は、Mac OS 8以降で、8MB以上の空きメモリが必要となっています。ただし、System 7.6.1以上でもカスタムインストールで必要なシステム機能を組み込めば機能することになっています。Ver.2.0は、PowerPCでも68040でも利用できます。
Ver.2.1のEarly Release版は、System 7.6.1以上とVer.2.0より古いシステムも対応OSに含めていますが、PowerPCのみの対応となっています。さらに、32MB以上のRAM搭載機で、仮想記憶をオンにして、メモリを33MB以上にしておくという条件を満たさなければ鳴りません。
MRJのインストールは、一般的なインストーラを使って行なえます。Early Release版はおそらくはインターネットを通じて入手できるでしょう。MRJ 2.0については、Mac OS 8あるいは8.1には、CD-ROMの「Mac OS特別付録」フォルダの中にある「Macintosh Runtime for Java」フォルダの中にインストーラがありますので、それをダブルクリックしてインストールします。
Mac OS 8以上で使うときには、そのままインストールを行えばよいでしょう。MRJ Ver.2.0をSystem 7.6.1にインストールするときには、Appearance Managerなど、カスタムインストールで必要な機能拡張ソフトも同時に組み込む必要があります。何を組み込めばいいかはインストーラと一緒に配付されるドキュメントで必ずチェックしてください。
インストールした結果、システムフォルダの「機能拡張」フォルダに、MRJLibrariesフォルダが作成されます。実行に必要なファイルがそのフォルダに納められます。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-5 インストールされたMRJLibrariesフォルダの内容
なお、MRJ 2.1ではMRJLibrariesフォルダの中身以外にも、機能拡張フォルダのMRJSubPortsというファイルも実行に必要になります。
MRJはいくつかの主要部分がありますが、JavaのVMを実現するライブラリが最も重要になります。これはおそらく、MRJLibrariesフォルダのMRJLibというファイルがその役割を持っているものだと思われます。このファイルは種類が「ライブラリ」です。たとえば、Internet ExplorerがJavaアプレットを実行するときにMRJを使う場合には、内部的にMRJLibを呼び出してJava VMの実行環境を整え、そこからJavaのアプレットを呼び出しているものと思われます。また、ダブルクリックして実行可能なアプリケーション形式のJavaソフトウエアでは、このライブラリを利用するようなプログラムがアプリケーションに組み込まれる模様です。つまり、アプリケーションの起動時にライブラリをロードして、Java VMの実行環境を整えた上で、Javaプログラムの実行を始めるのです。
Javaのアプリケーションの多くは、Javaのクラスライブラリを使いますが、MRJでは、MRJLibrariesフォルダにあるMRJClassesフォルダの中にある.zipファイルを参照することになります。MRJは実行時に、クラスライブラリの存在するフォルダをこのMRJClassesフォルダであると認識しています。JDKClasses.zipには、JDKで提供される基本的なクラスがアーカイブされ圧縮されて入っています。JavaのVMは圧縮してアーカイブしたようなファイルからも、その中身のクラスを利用できます。MRJClasses.zipには、MRJだけで提供されるクラスが含まれています。
以上が、Javaソフトウエアを実行するのに必要なシステム機能です。ファイルの数は少ないのですが、いずれもMBサイズの非常に大きなファイルとなっています。
いくつかのバージョンのMRJを切り替えて使いたいのであれば、「機能拡張」フォルダのMRJLibrariesフォルダを差し替えることで可能です。たとえば、MRJ 2.0をインストールしているとしましょう。そのときのMRJLibrariesフォルダをどこか別のところにコピーしておきます。そして、MRJ 2.1ea2をインストールしたとします。このとき、MRJLibrariesフォルダはMRJ 2.1ea2が入っています。この状態で、MRJ 2.0を使いたい場合、まず、2.1ea2のMRJLibrariesフォルダをどこか別のところに移動し、あらかじめ取っておいた2.0のMRJLibrariesフォルダを「機能拡張」フォルダに戻します。Early ReleaseのMRJでは動作が不安定だったり、あるいは仕様変更によってそれまでに作っていたソフトウエアが機能しなくなることもあります。その場合、こうした方法でMRJを切り替えて、Javaのソフトウエアを利用したり、あるいは開発作業を行う必要が出てくるでしょう。
WebブラウザのInternet Explorerでは、Webページ内のJavaアプレットを実行するVMを、MRJのものとMicrosoftが提供するVMとで切り替えることができるようになっています。「編集」メニューの「初期設定」を選択して、「初期設定」ダイアログボックスを表示します。左側のリストでJavaの項目を選択すると、Javaについての設定ができるようになっています。ここで、VMを切り替えることができます。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-6 使用するJava VMを選択する
「Apple MRJ」を選択すると、システムに組み込まれているMRJを利用してアプレットを実行します。
「Microsoft Virtual Machine」を選択すると、Internet Explorer自体で用意しているVMでJavaのアプレットを実行します。「機能拡張」フォルダにMS Library Folderというフォルダがあり、そこにMicrosoft VM Library (PPC)というファイルがあります。そのライブラリがJava VMだと思われます。さらにClasses (4.01)フォルダに、classes.ms.zipやextra.converters.zipがありますが、ここに基本のクラスライブラリが入っている模様です。
MicrosoftのVMとMRJの性能をくらべれば、MRJの方がベンチマークテストでは高得点を出します。しかしながら、MRJ Ver.2.0と比べると、画像やダイアログボックスのような処理は、どちらかと言えばMicrosoft VMの方が高い得点になります。また、いくつかのアプレットを動かしてみた感じでは、Microsoft VMの方が安定しているように思われる場合もありました。実際には切り替えて違いを見てみる必要が出てくるでしょう。
このように、Internet Explorerを使う上では2つのVMがありますが、将来的にはMRJに一本化される予定になっています。MicrosoftのVMの技術とMRJを統合化するというアナウンスがすでに出ています。
アプレットを開発しているときには、後で説明するApplet Runnerを利用してデバッグなどをします。しかしながら、ある程度完成した後は、Webページ内で、他の要素との兼ね合いもチェックする必要が出てくるので、Webページにおいて実行してみたいときもあるでしょう。その場合、Internet ExplorerでファイルとしてアクセスできるローカルのHTMLファイルを開き、その状態でアプレットを開くことができます。HTMLページを作成するときには確認のために、HTMLファイルをInternet Explorerにドラッグ&ドロップして開いて見ますが、その方法でもアプレットは起動します。しかしながら、アプレットが存在するフォルダまでのフルパス名の中に漢字あるいは2バイトコードのフォルダ名が存在すると、うまくアプレットが機能せずにエラーになります。アプレットのクラスが見つからないというエラーなので、おそらくは2バイトコードを含んだパスの文字列を、Internet ExplorerがJava VMにうまく伝達できていないのだと思われます。MRJでもMicrosoftのVMでも同じ現象になります。フォルダ名は1バイト文字だけにしておくなどの対処が必要でしょう。
Netscape Communicator/NavigatorにもJavaのVMが組み込まれていますが、これは固定されたものです。Netscapeを使うときには、MRJをVMとして使うことはできません。NetscapeのVMのMacintosh版は、JDKのすべての機能をサポートしていないことに注意が必要です。JDK 1.1で導入されたイベントモデルやJDBCなどいくつかサポートしていない機能があります。そのため、JDK 1.1が基本となっている現状では、Javaアプレットの実行環境としては適していないブラウザと言わざるを得ません。
以下に説明するJava Plug-InのMacintosh版が登場すれば、NetscapeでもMRJを使うということが可能になるかもしれませんが、Ver.4.5の段階ではまだリリースされていません。いろいろな意味でNetscapeはブラウザとしての評価は高いのですが、Macintosh上でのJava開発あるいは実行環境として見たときには、JDK 1.1への完全対応がなされていないことで選択肢からははずれてしまいます。
WebブラウザでのJavaアプレットの実行では、Netscapeのように独自にVMを包含していると、JDKの新しいバージョンへの対応が遅れるなど、実行環境の整備に手間取ることもありました。そこで、Javaの実行環境自体をWebブラウザのプラグインとして提供することも始まっています。Windows版やSolaris版はすでにSunよりリリースされています。Macintosh版はAppleからリリースされることになっていますが、98年9月現在、リリースされていません。Java Plug-Inは、以前はJava Activatorという名前で開発されていたものです。
Java Plug-Inは、Sunより配付されているJDKあるいはJRE（Java Runtime Environment：JDKのうちのJava VMの部分だけで構成されるもの）をVMとして利用します。そして、Javaのアプレットを使うには、プラグインを使う形式でHTMLを記述するため、従来からのAPPLETタグではなく、OBJECTタグで利用します。そのため、タグの書き直しを行うユーティリティもSun Microsystemsより配付されています。
Java Plug-Inを使えば、Webブラウザに搭載されているVMではなく、別途供給するJREを使います。JREはJDKからJavaの実行のために必要な部分だけを取り出したようなもので、通常はJDKに合わせて最新版が利用できます。VMの最新版を利用しやすいことや、ブラウザが用意するVMごとの違いによる問題は回避できることなどから、Plug-Inを前提に開発を行うということも行われ始めています。
Javaにはコンソールを実現するライブラリがあり、これを使うと行単位の入出力画面の利用が可能になっています。あるいはファイルなどを入出力とすることもできます。コンソールは、MS-DOSや昔の端末のように、行に入力したり、あるいは出力を行単位で行うと言った機能です。テキストの入出力しかできません。MS-DOSやUNIXでは、標準入出力として、コンソール形式のデータ入力や出力を、プログラムの上では簡単に実現できるような仕組みが用意されています。Javaのライブラリでも同様なことを実現しています。
UNIXやMS-DOSのコマンドでは、標準入出力の利用がメインになりますが、WindowsやMac OSのようなGUIのOSでは、マウスによるポイントやウィンドウ上のグラフィック表示などが主体になります。Javaのコンソールについても、主要な入出力形態というよりも、補助的な扱いです。しかも、一般的には出力だけに利用されます。たとえば、処理途中のデータを確認するといったデバッグ的な使い方や、Javaの特徴的なエラー処理である例外が発生したときのメッセージ用として利用されます。このように、コンソール出力は開発のためのデータやエラーメッセージ用に利用されるので、開発者はその機能と使い方を知っておく必要があります。
Mac OSでは、VMごとにコンソールの形式が違います。Webブラウザには、Webブラウザ自身がJavaコンソールを表示する機能を持っています。通常はメニューを選択してコンソールを表示します。Internet Explorer 4.01では、「表示」メニューの「Javaメッセージ」を選択します。Netscape Navigatorでは、Navitagorメニュー（船の舵のアイコン）の「Javaコンソール」を選択します。バージョンや対応言語によってもメニュー項目は変わります。いずれにしても、Webブラウザではコンソールはメニュー操作をしないと表示されず、勝手に表示されるわけではありません。
一方、Webブラウザ上ではなくアプリケーションとして機能していたり、あるいはApplet Runnerでアプレットを実行していると、プログラム中でコンソールへの出力があれば、自動的にウィンドウが開かれて、そこに出力結果が表示されます。つまり、独立したコンソールウィンドウが自動的に表示されるというわけです。
Macintosh環境で、Javaのソフトウエアを開発する場合に、どのような素材が利用でき、利用可能な開発ツールがどのようなものかについて説明しましょう。
MRJ SDKはAppleからリリースされているJavaの開発キットで、WindowsやSolarisでのJDKと同等の意味を持つ、基本的な開発ツールです。Javaの実行環境であるMRJと開発環境であるMRJ SDKは別のものだということをまずしっかり認識しておいてください。Macintosh向けの基本クラスのリリースも、MRJ SDKで行われますが、必ずしも実行環境のMRJよりも先に出るとは限りません。最近は概ねMRJの少し後にMRJ SDKがリリースされるというのが傾向です。MRJ SDKは、以下に示すように、プログラミングのための素材を提供することが主な用途だと言えるでしょう。
MRJ SDKは、インストーラを起動すればインストールができます。通常は、同一バージョンの実行環境であるMRJをインストールした上で、追加でインストールします。SDKには実行環境は含まれていません。MRJ SDKをインストールすると、「MRJ SDK 2.1」のようなフォルダが作成されます。以下、その中身を見ていくことにしましょう。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-7 MRJ SDK 2.1ea2の内容
本稿執筆時点（1998年9月15日）には、正式リリース版としては、MRJ SDK 2.0.1がリリースされています。また、早期公開されている実行環境のMRJ Ver.2.1 Early Release 2に対して、開発環境としてはMRJ SDK Ver.2.1ea2がリリースされています。これらは、AppleのWebページからダウンロードできます。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-8 MRJとMRJ SDKの関係
Applet Runnerは、文字通り、アプレットとして作られたソフトウエアを実行するためのアプリケーションです。JDKに含まれるものの中では、appletviewerに対応するのがApplet Runnerです。これは独立したアプリケーションとして機能し、そこでアプレットを実行することができます。通常はアプレットはWebページの中に埋め込まれて実行されますが、Applet Runnerでは、1つのアプレットが1つのウィンドウを使って実行することができます。アプレットを実用的に使う環境というよりもむしろ、テスト的に実行したり、デバッグのためにアプレットを実行するために使います。従って、Applet Runnerは開発ツールの1つと位置付けることができます。
Applet RunnerはMRJ 2.0までは、実行環境のMRJといっしょに配付され、「Appleエクストラ」フォルダ（あるいはApple Extraフォルダ）の中のMac OS Runtime for JavaフォルダにApple Applet Runnerフォルダとしてインストールされていました。このフォルダの中に、Apple Applet Runnerがあります（Applet Runnerとして参照します）。なお、MRJ 2.1からは、Applet Runnerは、MRJ SDKのなかで配付されるようになりました。
なお、実行環境のMRJと、Applet Runnerのバージョンを合わせておかないと、うまく機能しないこともあります。たとえば、MRJ 2.0をインストールしているときには、MRJ 2.0に付属のApplet Runnerを使います。MRJ 2.1を使うときにはMRJ SDK 2.1にあるApplet Runnerを使います。開発ツールによっては、実行やデバッグ時に自動的にApplet Runnerを起動しますが、このとき、いくつかのバージョンのApplet Runnerが同時にハードディスクに存在すると、どれが起動するか分かりません。必要に応じて使用したいバージョンのApplet Runner以外を削除しておく必要があるでしょう。もちろん、消してしまうのが問題な場合は圧縮をかけておき、圧縮ファイルだけを残しておくことで対処すればよいでしょう。
作成したアプレットは、Javaのソースコードから生成した、拡張子が.classのバイナリファイルです。.javaの拡張子の付いたソースファイルから、.classファイルがコンパイラによって作られます。このアプレットを実際に起動するためにはAPPLETタグを含んだHTML文書が必要です。アプレットを開発するときには、HTML文書も一緒に作るのが一般的です。
Applet Runnerでも、.classファイルを直接実行するわけではありません。Applet Runner
中で、classファイルをアプレットとして起動するタグの入ったHTMLファイルを指定すると、そのアプレットを実行できるのです。Applet RunnerのFileメニューのOpen Local HTML File、あるいはCommand+Oと操作して、HTMLファイルを指定してもいいのですが、Finder上でHTMLファイルをApplet Runnerにドラッグ&ドロップしてもかまいません。また、ネットワーク上のアプレットを起動するには、FileメニューのOpen URL（Command+N）でURLを指定して開きます。
通常、HTMLファイルの中にあるAPPLETタグ内で、アプレットのファイルへの相対パスがパラメータとして記述されているはずです。その記述に従って、.classファイルのアプレットがApplet Runnerによってロードされて実行されます。
HTMLファイル内に複数のアプレットの組み込みがあってもかまいません。その場合、Applet Runnerではそれぞれのアプレットに別々のウィンドウを割り当てて実行を開始します。なお、HTMLファイルのAPPLETタグ以外の部分は、Applet Runnerでは無視されますが、HEADやBODYなどHTMLの基本的な骨格部分は、通常はHTMLファイルに含めておきます。ネットワーク上のアプレットを実行する場合も、それを組み込んであるHTMLファイルを指定します。
いずれにしても、HTMLファイル自身はApplet Runnerでは表示されません。Applet Runnerは、HTMLファイルの中のAppletタグの部分だけを取り出し、その他の部分は無視します。
Applet RunnerのAppletメニューからは、アプレットを再ロードしたり、再起動したり、あるいは実行を停止すると言った、アプレットの実行をコントロールするメニュー項目が並んでいます。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-9 Applet Runnerで実行したアプレットと、Appletメニュー
Applet Runnerは、JDKにサンプルとして添付されているアプレットをすぐに実行できるようになっています。Appletsメニューに、サンプルアプレットの名前が並んでいますが、階層メニューによって、さらにアプレットを実行するHTML文書を選択できるようになっています。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-10 Applet Runnerでサンプルを実行する（MRJ 2.0）
これらのアプレットは、Apple Applet Runnerと同じフォルダの中にあるAppletsフォルダにあらかじめ入れられているものです。なお、MRJ SDK 2.1のApplet Runnerには、JDKのサンプルはほとんど入っていません。
Apple Applet Runnerで、FileメニューからProperties（Command+;）を選択することで、アプレットの実行環境に関する設定が行なえます。この操作で表示される以下の図のダイアログボックスは、アプレット実行環境のセキュリティについての設定が行なえるようになっています。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-11 Applet Runnerのセキュリティ設定
Network Accessは、アプレットからアクセス可能なネットワーク上のサーバーなどについての制約です。既定値はApplet Hostになっており、この状態では、アプレットが存在するのと同じホストとしか通信ができなくなっています。一般にWebブラウザではこれと同じ制約になっているので、通常はこのままで良いでしょう。
Filesystem Accessは、アプレットから利用可能なファイル処理の範囲です。既定値のLocal Appletsは、Applet Runnerを実行しているパソコンと同じパソコンにあるアプレットを実行した場合、ファイルの処理ができることを意味しています。しかしながら、Webブラウザでは、一般にはファイル処理は一切できないようにセキュリティが設定されています。もちろん、そうしたことを知った上でApplet Runnerでファイル処理をしてもいいのですが、ともかく、ファイル処理についてのセキュリティは、Applet RunnerとWebブラウザで異なっていることは意識しておかなければならないでしょう。
チェックボックスが2つありますが、これらは、通常はオンにしておきます。Restric Package Accessを設定しておくと信頼性の低いアプレット（開発したアプレットをネットワークを通じてダウンロードしたもの）は、Javaの基本クラスライブラリにアクセスできなくなります。また、基本クラスの存在するパッケージの中に、独自に定義したクラスを含めることはできないようになっており、そうした制約を付けておくのがRestrict Package Definitionの設定です。いずれも、一般的なWebブラウザの動作に合わせて、オンにしておきます。
ほかに、プロキシサーバーやファイアーウォールの設定があります。ネットワーク環境でこれらの設定が必要な場合は、ここで設定を行います。
MRJToolkitは、実行環境であるMRJでは、JavaからMac OSの機能を利用する部分を示します。MRJ SDK 2.1ea2の段階で公開されている機能は、Finder上でファイルをドラッグ&ドロップすることで起動可能なアプリケーションを作る、すなわち、Open DocumentのAppleEventに対応可能にする機能が公開されています。他にも、ファイルタイプやクリエイターの取得および設定、リソースの処理など、Javaの基本機能にはないもので、Macintoshのアプリケーションとして最低限備えておくべき機能を提供しています。実行環境としてのMRJにはこうした機能が組み込まれています。従って、MRJToolkitの機能を使うように、Javaのプログラムを組めばよいということになります。
MRJ SDKには、MRJToolkitフォルダがありますが、そこには、これらの機能をJavaのプログラムで使う方法を示したドキュメントと、サンプルのプログラムが入っています。サンプルのプログラムは、Metrowerks社の開発ツールのCode Warriorで作られています。
JDirectは、Javaのソフトウエアから、CやC++で作られたライブラリなどの呼び出しを行うような機能を提供します。Mac OSのシステムコールは基本的にはCの関数として定義されていますが、JavaからこうしたMac OSのシステムコールを呼び出すことがJDirectでは可能になります。こうしたことは、システム本来の機能を呼び出すことから「ネイティブコール」などと呼ばれています。JDirectにより、Javaのプログラムから、Mac OSのシステムルーチンを利用できますが、独自にC言語などで作成したライブラリを呼び出すことにも使えます。実行環境としてのMRJにJDirectの機能が含まれています。
Javaの基本ライブラリとして、JNI（Java Native Interface）という、JDirectのような機能が定義されています。Windows版のMicrosoftのVMでは、良く似た名前のJ/Directという機能でネイティブコールを実現しています。このように、ネイティブコールの手法は本来のSunの定義されたものとは違うものが出てきており、それもSunのMicrosoftへの訴訟の焦点になっています。
たとえJNIでネイティブコールが一本化されても、Mac OS向けのソースコードはWindowsでは機能しませんし、逆も同様です。ネイティブな部分なので、当然共通性はないわけです。ネイティブコール方式が一本化されたとしても、ターゲットのOSごとにAPIコールは違うことが一般的なので、OSごとに別々に開発することになります。OSごとに異なるネイティブインタフェースのシステムが機能しているからといって、根本的に開発が容易になるというわけではないのです。
実行環境としてのMRJにはJDirectの機能が組み込まれています。MRJ SDKのJDirectフォルダには、ネイティブコールを行う方法を記載したドキュメントとサンプルのプログラムが含まれています。
それではMRJToolkitに存在しないシステム機能は、JDirectを使って利用するのでしょうか。確かにそうすることもできます。しかしながら、システムコールはハンドルやポインタと言ったJavaには存在しないデータを使います。JDirectはそれらのデータを使う工夫もありますが、うまくシステムコールを利用するようにJavaでプログラミングを行うというのも大変な作業になります。実際には、そうしたことをする必要がないように、MRJは構築されている模様です。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-12 Visual Cafeで見た実行環境のクラスには、システム機能を使うものが見えている
MRJでは、Mac OSのToolboxに用意されているシステムコールを使うためのクラスを構築してあり、それを利用することによって、Javaのソフトウエアからも比較的容易にMac OSのシステム機能を使うことができます。言い換えれば、C言語のライブラリということを意識しなくても、Javaのやり方でToolboxの機能を利用できるのです。しかしながら、どのように使えばいいかということが一切ドキュメントになっていません。現在読んでいただいているMacintosh Java Reportでは、こうしたすでに構築されているクラスについての使用法を解説することを1つの大きな柱と位置付けています。
これら、Toolboxのシステムルーチンを直接利用するクラスでは、JDirectの手法でネイティブコールを行っている模様です。ですが、そのような部分はMRJの実行環境として構築されており、一般のプログラマは、Appleが定義したシステムルーチンを使うためのクラスを使う方にフォーカスすることができます。つまり、Toolboxの機能を使うためのクラスを使えばそれでよいのです。その意味では、システムルーチンを使うようなアプリケーションでも、JDirectを直接プログラムで使うということはほとんどないでしょう。
MRJ SDK 2.1から新しく加わったMRJ Scriptingは、Applet Runnerをスクリプト処理できるというのが1つの機能です。Javaで作ったアプレットを、AppleScriptのオブジェクトとしてコントロールすることができるのです。その場合、Applet Runnerで実行しているアプレット内のボタンやテキストボックスと言ったComponentクラスを元にしたオブジェクト1つ1つを、AppleScriptのプログラムでコントロールできます。アプレット全体のコントロールだけでなく、アプレットの中の個々のオブジェクトをAppleScriptでコントロールできるという具合です。言い換えれば、Javaのアプレットは、それだけですでにAppleScript対応になるということに他なりません。
また、Javaで作ったアプリケーションをAppleScriptに対応させるということも、MRJ Scriptingの機能です。そのためのaeteリソース（AppleScriptの用語を管理するリソース）や対応方法を記述したドキュメントも付属します。
AppleScriptも、根本は処理対象をオブジェクトとして扱い、そのオブジェクトを処理するということを目指しています。MRJScriptingにより、Javaの世界をAppleScriptから操作できるようになるわけで、AppleScriptとJavaの親和性も一気に高くなるでしょう。特に従来のアプリケーションでは、AppleScriptつまりAppleEventに対応するために、対応する部分のプログラムをわざわざに構築する必要があったのですが、MRJScriptingがうまく機能すれば、Javaのアプレットに関しては、特にAppleScript対応のための追加プログラムをしなくても、AppleScriptでのコントロールができることになります。その意味でも、AppleScriptとの相性が一気に良くなっていると言えるでしょう。
JBinderyは、MRJ SDKに含まれるMac OSで機能するアプリケーションです。Javaで作られたアプリケーションをMac OS上で実行するのが1つの大きな機能です。その意味では、一般のSDKのjavaツールに対応したものです。また、Javaで作られたアプリケーションを、Mac OSでダブルクリックして実行可能なアプリケーションに変換するということも行います。つまり、JavaのアプリケーションをMac OS専用のアプリケーションにしてしまうというわけです。MRJToolkitの機能などを使ってアプリケーションが適切に作られていれば、JBinderyによって、たとえばテキストファイルをFinder上でドラッグ&ドロップすると、そのテキストファイルを開いて処理をするようなアプリケーションになります。
MRJ SDKには、JBinderyそのもの以外にも、その利用方法を記述したドキュメントと、サンプルのJavaアプリケーションが含まれています。
Javaのアプリケーションであるためには、public static void main(String args[])というスタティックなメソッドがクラス定義に含まれている必要があります。Javaのソースは.javaファイルに保存されますが、コンパイル結果は.classファイルに保存されます。そして、JBinderyでその.classファイルを実行すると、クラス内のmainメソッドを探してそれを最初に実行します。mainメソッド内からはプログラマが自分で作ったプログラムを実行できるように、プログラムを作成することになります。
アプリケーションとして作られてコンパイルされた.classファイルを実行するには、classファイルをJBinderyにドラッグ&ドロップします。すると、次のようなダイアログボックスが表示されます。ここでさまざまな設定をして、Runボタンで実行が行われます。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-13 JBinderyでアプリケーション実行の設定を行う
ダイアログボックスの左側のアイコンにより、さまざまな設定が行なえるようになっています。
Commandsでは、コマンドラインを指定します。実行するクラス名に加えてオプションを指定できるようになっています。また、Redirect stdoutやRedirect stdinでは、標準入出力を選択できます。いずれもなしにしたり、あるいはファイルを標準入出力としたり、出力ではウィンドウに出力結果を出すことから選択できます。
左のアイコンでClasspathを選択すると、クラスライブラリのファイルやファイルが存在するフォルダを指定することができます。通常はMRJLibraries/libは使えるようになっているのでそれ以外のパスを追加するときに利用します。
Propertiesは、アプリケーションで利用できるプロパティを追加したりあるいは値を設定することができます。Appearanceでは、サイズボックスのためにウィンドウの下に領域を設けるかあるいは表示サイズのままで右下にサイズボックスを設けるかを選択します。Securityは、プロキシサーバーなどの設定です。
Applicationは、アプリケーションを作ったときのクリエイタや、メモリのサイズ、さらにはリソースを結合する設定などが行なえます。
こうしたJBinderyでの設定は、「Save Settings」ボタンで保存できます。ファイルの保存のダイアログボックスが表示されるので、フォルダとファイル名を指定しますが、「Save as Application」のチェックボックスをオンにしておくと、保存したものはアプリケーションとなり、Finder上でダブルクリックして起動できます。チェックを入れないでおくと、JBindery文書として保存され、それをFinder上でダブルクリックするとJBinderyが指定した設定で開かれて、Runボタンにより実行ができます。つまり、実行のための設定を保存しておくということができるわけです。
MRJの実行環境に組み込まれているJManagerは、C言語などで作られたソフトウエアからJavaのソフトウエアを実行する機能を提供するものです。たとえば、Webブラウザを開発している人やApplet Runnerのようなものを自分で作るというプログラマには必要になる機能でしょう。また、ライブラリやプラグインはJavaで作る、というような場合にも必要になるかもしれません。JManagerを活用するとする状況としては、ソフトウエア部品としてすでに存在するJavaのソフトウエアを、CやC++で作るアプリケーションで必要になるという見方もあるでしょう。
いずれにしても、通常のJavaのアプレットやアプリケーションを作成しているプログラマが使うような機能ではありません。Mac OSの基本機能としては重要なJManagerですが、プログラマが一般的に使う機能ではないと言えるでしょう。
MRJ SDKには、JManagerの利用方法を記述したドキュメントと、C++で作られたプログラムからJavaのソフトウエアを呼び出すサンプルプログラムがあります。サンプルプログラムのJavaのソフトウエアを呼び出す部分を流用してプログラムに機能を組み込むのが一般的な利用方法になるでしょう。
MRJ SDKには、Interfaces&Librariesというフォルダがあります。このフォルダには、CやPascalのヘッダーファイルやライブラリがありますが、いずれも、ほとんどの部分はJManagerの機能を使うために、開発ツールあるいはそのプロジェクトで利用するファイルです。従って、一般的なJavaプログラマにとって必要性はほとんどないと思われます。
MRJ SDKのToolsフォルダには、開発に必要なさまざまなツールが含まれています。特に、JDK Toolsは、Windowsなどの他のプラットフォームでリリースされているJDKに対応するツールが含まれており、コンパイルなど基本的な開発作業ができるようになっています。
表 1-1 JDK Toolsの内容
| ファイル名 | 機能 |
| javac | Javaコンパイラ。Javaのソースファイル（.java）をドラッグ&ドロップすれば、コンパイルして実行ファイル（.class）を生成する |
| jar | Javaアーカイバ。Javaのアーカイブファイル（.jar）を作成したり、アーカイブからファイルを取り出す |
| javadoc | Javaドキュメントジェネレータ。Javaのソースファイルから、クラスの利用方法を記述したHTMLドキュメントを生成する。生成されたドキュメントで利用する画像ファイルは、Toolsフォルダの中のjavadoc imagesフォルダにある |
| javah | ネイティブコールの定義から、Cのヘッダーやスタブを作成するツール |
| javakey | セキュリティの設定ツール。プライベートあるいはパブリックキーを設定したり、認証を行う |
| rmic | RMIで使用するスタブやスケルトンの作成を行う |
JDKに比べていくつか存在しないツールがあります。まず、Java実行環境の「java」や「appletviewer」はありませんが、MRJではJBinderyやApple Applet Runnerがそれに代わります。デバッガのjdbがありませんが、それに直接代わるものはありません。デバッグ作業はMacsBugでできるようにコマンド拡張ファイルは付属していますが、MacsBugはローレベルのデバッガです。MRJ SDKにはデバッグ環境はないと言ってもよいでしょう。。
MRJ SDKのToolsフォルダの中のOther ToolsにあるMRJ dcmd for PPCフォルダが、MacsBug用のdcmdファイルになっており、これによってMacsBugのコマンドを増やします。ただし、ソースコードのデバッグではありません。通常、デバッグを行うとなれば、ソースコードレベルのデバッグはやはり必須でしょう。そうなると、市販の開発ツールを利用するということになります。
ToolsフォルダのMPW Toolsフォルダには、MPW（Macintosh Programmers Workshop）でJDK Toolsにある各ツールを利用できるようにするスクリプトなどがあり、MPW ShellでJavaのソフトウエア開発を可能にするものを提供しています。MPW Shellはコマンドライン形式でツールを呼び出せるので、MPWを使った方が、他のプラットフォームのJDKによる開発により近い感じで作業ができるかもしれません。また、その場合は、MPW Shell自体でJavaのソースコードを作成するということも可能でしょう。
ToolsフォルダのOther ToolsフォルダにあるJava Diddlerは、入力したJavaのプログラムをその場で実行するアプリケーションです。たとえば、1行だけJavaのプログラムを入力してそれを実行するということができます。あるメソッドがどのような動きになるのかなどを調べるのに利用できなくはありません。ドキュメントによれば、位置付けとしては、Javaの学習用に利用できるユーティリティだとされています。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-14 Java Diddlerを使った様子。左上のウィンドウでコマンドを入力する。右のウィンドウは実行によって作られたもの。Javaコンソールには処理結果が報告される
JDK Toolsの各アプリケーションは、Finder上での基本的なドラッグ&ドロップに対応しています。たとえばJavaのソースファイルをjavacにドラッグ&ドロップすると、そのソースファイルをコンパイルするために開きます。ただし、その場合は、ダイアログボックスで設定を行ってコンパイルの開始をマウスボタンでクリックして指示しなければなりません。
Other ToolsのDropletsフォルダにあるサンプルのドロップレットを利用すると、Javaのソースファイルをドラッグ&ドロップすれば、javacが起動して自動的にコンパイルが始まり、自動的にjavacが終了します。つまり、コンパイル作業が自動化されるというわけです。
JDK Toolsにある各ツールは、ファイルを開くといったな基本的なAppleEventに加え、処理を実行するなど少しはAppleScriptに対応しているわけです。それについての解説文書もDropletsフォルダにはありします。
Macintosh向けに市販のJava開発ツールも存在します。JDK Toolsだけでは、特にデバッグの作業ができないに等しいため、開発には、開発ツールを購入して臨むことになります。完全にクロスプラットフォームを狙うのであれば、Mac OSの開発ツールにこだわらなくてもいいのですが、Mac OSの機能を使うとなれば、やはりMac OS上で開発をするのが適切でしょう。
以下、代表的な開発ツールについて概略を説明しますが、開発ツールに関する使い方などは、Macintosh Java Reportでは話題に応じて随時説明をしましょう。また、バージョンアップなどのタイミングで詳細に紹介することも検討しています。
表 1-2 開発ツールの比較
| ツール | 提供元 | 価格 | ビジュアル環境 | ソースデバッガ |
| MRJ SDK | Apple | フリー | × | × |
| Code Warrior Pro | Metrowerks | ?82,000（アカデミック版は?28,000） | △ | ◯ |
| Visual Cafe for Java | Symantec | ?36,000（プロフェッショナル版）、?78,000（データベース開発版） | ◯ | ◯ |
C/C++でのアプリケーション開発ツールとしては、Mac OS環境では事実上Metrowerks社のCode Warriorしかなくなってしまったこともあって、Mac OSで開発をしている人は必ず所有している開発ツールではないかと思われます。そのCode WarriorでもJavaの開発はできます。統合開発環境内で、Javaのソースコードを記述して、それをコンパイルし、デバッグをしながらの実行もできます。Java VMは独自のものを提供しており、また、Apple Applet Runnerではなく、独自のJavaソフトウエア実行環境も提供しています。なお、MRJのVMを使うように切り替えることもできます。
統合開発環境とは別に、Constructor for Javaとして、ビジュアル開発環境も利用できるようになっています。そこでは、ボタンなどのオブジェクトをウィンドウ上に配置するようなグラフィカルな設計ができ、その設計通りに機能するJavaのソースコードを作成します。しかし、そこで生成されたソースを実行するには、Metrowerksが独自に定義したクラスも利用しなければなりません。オブジェクトの1つ1つを実現するのに標準的なクラスをそのまま使っているのではありません。
なお、初心者向けという位置付けのDiscover ProgrammingシリーズもMetrowerks社からリリースされています。CやC++でのプログラミングでは、PowerPC対応のコードをコンパイルできないことや、あるいは商用のソフトウエア開発がライセンス上できないことなど制約はありますが、Javaプログラミングに関してはあまり大きな制約はなく、Javaを中心に利用するのであれば、こちらも検討の価値はあるでしょう。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-15 Code Warriorの作業画面
Symantec社のVisual Cafe for Javaは、ビジュアル開発環境が完全に統合された開発ツールです。ウィンドウを用意して、その中にツールを使ってオブジェクトを配置します。そうすると、その設計通りに機能するJavaのソースコードが背後で作られます。実行時にそのオブジェクトをクリックして行う作業などを、ソースとして書き加えることができますます。標準的なコンポーネントに加え、独自のコンポーネントも数多くの提供しています。
デバッグや実行は、Apple Applet Runnerを利用します。従って、MRJが実行環境ということになります。「データベース開発版」も存在し、データベースを利用するようなJavaのアプレットを簡単に作成する機能も利用できます。ただし、データベースエンジン自体は、Windows NTを利用するのが前提になります。
なお、Windows版は、2.0、2.1、2.5とバージョンをアップしてきて、Swingにも対応するようになっています。Macintosh版は、2.0以降リリースされておらず、バージョンアップされる予定についても全くアナウンスがないという状態です。
 |
画像をクリックすると、大きく表示されます。 背後のウインドウに表示されていることもあります。 クリックしても表示されないときには背後のウインドウに表示されていないかを確認してください。 |
図 1-16 Visual Cafeの作業画面
非常に難しい問題ですが、Java開発としてみたとき、Code WarriorとVisual Cafeはやや性質が違うと言えるでしょう。
まず、開発ツール自体の操作性では、Code Warriorの方が良いと考えられます。ソフトウエア自体が軽く動作することや、デバッグ時のキーボードショートカットなど、統合開発環境の使用感は、Code Warriorに軍配が上がるでしょう。
一方、ビジュアル開発環境としてみたときには、Visual Cafeの方がより高機能ですし、何と言ってもフォームエディタなどのビジュアル開発機能が完全に開発環境に統合されているところが使いやすいところです。
Code Warriorは、現在は半年ごとのリリースとなっていますが、そのため、開発途中のバージョンのツールを使うことになってしまうのかもしれません。Code Warrior Pro3でも、完全な日本語対応はなされておらず、日本語の文字列はそのままソースコードで記述することができません。Code Warriorは、それなりにJavaの知識があるプログラマが、コードをばしばし書くような作り方ではそれなりに適応があると考えられます。
一方、Visual Cafeの方が初心者には取っ付きやすい面はあるでしょう。ただ、ビジュアル開発ですべてがうまく行くわけではありません。実用的なプログラムにするためには、やはりソースを書く必要があり、場合によってはビジュアル開発環境から離れた作成も必要になります。さらに、Mac版のバージョンアップがなされていないことも気掛かりな点です。
開発はバグとの戦いです。自分の作ったソフトのバグは仕方ないとしても、実行環境やあるいはシステムのバグについては気が付かないと相当に悩まされることにもなりかねません。MacintoshでのJava開発となると、やはりMRJ自体のバグについては知っておきたいと思うところでしょう。
Appleでは、MRJについてのバグ情報をAppleのWebページで公開しています。ときどき、それをチェックする必要もあるでしょう。
また、基本クラスライブラリ自身のバグについては、JavaSoft社のWebページで参照できます。JDC（Java Developer Connection）の中で公開されていますが、JDC自体は入会申し込みが必要です。ただし、無償なので、入会しておいて損はないでしょう。
これらのWebページのありかについては、このMacintosh Java Reportに「リンク情報」としてまとめておきます。
ここまでのところで、Javaについての概略を追ってきました。出発点が「マルチプラットフォーム」を目指したJavaなのですが、Macintosh向けに開発することにどのような意味があるのかを検討してみましょう。
まず、Mac OSという十分に完成度の高いOSがあるのに、その上にもう1つJavaというOSを稼動させるようなことが実際に意味があるのかという素朴な疑問があるでしょう。これについては意味があると考えます。もちろん、C++などと使ったMac OS向けの開発を否定するわけではありません。C++でネイティブ開発は重要な手段の1つです。それに加えて、Javaで開発するということも選択肢の1つとして浮かび上がらせることができるのではないかと考えられます。
ただし、Javaのメリットを生かした開発を行うためには、Mac OSでJavaが高いレベルでサポートされている必要があります。幸いなことに、Appleは、Javaに対して積極的な対応を行い、MRJとしてOSにタイトに組み込んだ実行環境を提供しています。そして、Finder上でのドラッグ&ドロップを始めとして、OS機能をふんだんに取り込んだJavaのアプリケーションを作成するということも可能にしています。現状では完全とは言えないものの、少なくとも、AppleはMac OS上で実行するJavaのソフトウエアは、本来のMac OSで機能するソフトウエアと遜色なく利用できるということを目指していることは間違いないでしょう。現状では、実行環境のパフォーマンスが悪いとか、Mac OS独自の機能を利用しづらいなど環境面で整っていないということがありますが、時間が経過すれば、徐々に解決されてくると考えられます。
現在のところ、Mac OS 8.1が最新版のOSですが、8.5のリリース、そしてMac OS Xのリリースが計画されており、そのロードマップの中でもJavaのサポートは強化される傾向にあると言えるでしょう。MRJのリリースがOSにうまく連動していない実情はあるものの、Mac OS Xのような根底から作り直されるOSにおいても、Javaのサポートははっきりと明言されています。Mac OSでJavaが使えなくなるということはあり得ない状況ですし、単に使えるということではなく、Mac OS上で高い機能を発揮するようなJavaのソフトウエアも実現へ向けて着々と進んでいるということになるでしょう。
現状でも、それなりにMac OSの本来の機能をJavaのソフトウエアから利用できます。しかしながら、そのためのドキュメントなど、開発に必要な情報が圧倒的にありません。少ないというよりも、ある部分に関してはまったくないと言ってもいいくらいです。Macintosh Java Reportでは、こうした情報を提供することによって、Javaでは貧弱なソフトしか作ることができないという状況を変えることを目指します。
Webページに埋め込まれるアプレットは、いろいろなブラウザで機能するため、特定のOSでしか機能しないようにするのは、もちろん得策ではありません。また、それ以前に、いろいろな面でセキュリティがかかっているため、できることもある程度限られます。アプレットはそうした制約を意識した上で、プログラム作成を行うことが必要になります。
一方、アプリケーションソフトは、セキュリティの制約は基本的にはなく、自由にソフトウエアを作成できます。それでも、Javaのメリットの1つである「マルチプラットフォーム」であることを削がないようにするには、OSに依存しない純粋なJava機能だけを使うという傾向はあるでしょう。また、Sunは「100% Pure Java」という称号を認定して与えるということも行っています。「完全にJavaで作らないといけないということはないのだ」ということは、インタビューなどで強く主張されていますが、「100% Pure Java」という言葉が一人歩きし、「すべての純粋なJava機能だけでソフトを作ることが最善である」という極端な純血主義的な考え方が広まっているようにも思われます。たとえば、データベースソフトの「ファイルメーカーPro」の開発版は100% Pure Java認定商品です。もちろん、ファイルメーカーPro自体はJavaで作られているわけではないのですが、Webサーバーとして利用したときに、サーバーのコントロールなどでJavaで作られた部品を利用して開発ができます。つまり、Javaをベースにしてクロスプラットフォーム対応のシステムを開発できる点が評価されているのです。
いずれにしても、100% Pure Javaという響きに酔いしれていると、「100%はいい、だけどそれ以外はダメ」という極端なデジタル的結論に走りがちになります。しかし、それではソフトウエアの可能性を削いでいるとしかいいようがありません。
仕様を満たすソフトウエアを作りたい、あるいは要求を満たしたいことから、どうしてもOSの本来の機能を使うしかいないということもあり得ます。たとえば、UNIXやMac OSではエイリアスを利用し、Windowsではショートカットを利用したいという場合があるかもしれません。それらエイリアスやショートカットを作ったり、あるいは参照の解決を行うとなると、Javaの機能だけではできません。たとえば、Mac OSでエイリアスの機能を使う部分を、JDirectあるいはそれをベースにした独自のクラスで利用したとします。そうすると、もちろんその部分は別のOSでは機能しません。結果的には、OSごとに処理を分岐させて対処することになるでしょう。
こうした作りのソフトウエアでも、たとえば95%は共通の標準的なJavaクラスライブラリを使っていて、残り5%はOSごとの処理が組み込まれているというのであれば、Javaのクロスプラットフォーム対応ということは十分に生かされていると言えるでしょう。クロスプラットフォーム対応がなければ、それぞれのOSごとに開発作業をしなければなりません。もちろん、すべてのOSで1からということはないにしても、GUIが絡むようなものだったら、ほとんどOSごとに1からやるのに変わりないでしょう。しかしながら、Javaならば、GUI部分は共通でOSに依存する部分をそれぞれのOSに向けて作るということが可能です。
クロスプラットフォームということを、OSには一切依存しないというところだけに短絡的に結び付けるのではなく、OSに依存したところもあるけども、共通部分をなるべく多く使うような見方に変えて考えてみましょう。そうすると、JavaでMac OSの機能を使うということは、クロスプラットフォームに反することだとは言えません。むしろ、クロスプラットフォーム対応のソフトウエアを作る足掛かりにもなります。OSに依存しない部分だけを使ってソフトウエアを作り、完成度が低くなることよりも、OSに依存する部分を認識しつつ、OSごとの切り分け、そして依存する部分としない部分をうまく切り分けて開発を行うことが、作成するソフトウエアの可能性を高め、より高い完成度が得られると言えるのではないでしょうか。
それでは、JDirectのような機能を積極的に使う必要があるのでしょうか。このことはJDirectのところで説明している通り、CとJavaの接点をどうこうするような難しいところは、Appleがクラス定義してくれています。プログラマは、その定義されたクラスを単に使うだけなので、その仕様さえ分かっていれば、Javaの流儀でMac OSの機能は使えます。ただ、その仕様自体、現状ではまったくドキュメント化されていないということが問題になります。
Javaのソフトウエアとなると、必ず実行速度の問題が出てきます。いまだに、初期の頃のゆっくりとぎこちない動きしかしないJavaアプレットのイメージがあるようなら、認識を変えるべきでしょう。Javaで作ったソフトウエアを高速に稼動させる技術は発達し、またJava VMの処理能力も高まっています。また、パソコン自体の高速化もとどまるところを知らないくらいで、パフォーマンスに関する問題は現状ではだいぶんと解決されてきています。
Javaがクロスプラットフォームであることは言い換えれば、Mac OS上で、Windowsで機能するソフトウエアを開発できるということに他なりません。開発にもいろいろな形態があるかもしれません。もちろん、市販のソフトウエアの開発のようなものから、個人のツールまでいろいろあります。企業内などのプロジェクトとしてソフトウエアを開発するという場面もあるでしょう。最近ではMacintoshのシェアの低下によって、企業の情報システム部門がMacintoshの存在自体を認めないような状況も出てきているという話はあちらこちらで耳にします。たとえば、実験的なシステムであっても、Macintoshで構築することが許されないという具合です。
Mac OSの魅力となると、読者の方々には釈迦に説法でしょうから多くは語りません。やはり何と言われようと、自分はMacintoshを使いたいと思うところかも知れません。そのような状況では、単にMacintoshで開発するという案件は通りづらいのですが、Javaを使ってクロスプラットフォーム開発を行うという理由があれば、実作業はMacintosh上で行うという手法を提示できるでしょう。Windowsでも動くということをうまく強調すれば、案件も通りやすいかもしれません。
利用範囲が限定されたような開発だけでなく、市販ソフトやフリーソフトでも、Javaで作れば比較的簡単にクロスプラットフォームが実現します。現状でそうしたソフトウエアが少ない理由としては、1つにはパフォーマンスということがありますが、やはり100% Pureという言葉に縛られている面があるのではないでしょうか。そのため、要求する機能が実現できず、CやC++で作ったようなソフトウエアに対抗するまでのスペックが実現できていないのです。Javaで作るときに、OSに依存する部分もうまく取り込んで高性能なソフトウエアに仕上げることができれば、Javaで作ったからというデメリットはかなりは解消されます。そして、少ない労力でクロスプラットフォーム対応が可能になります。
Javaで作るということを、Macintoshで開発する理由付けに利用するというのは、ある意味では後ろ向きなことかもしれません。しかしながら、その先にクロスプラットフォームを実現しつつ、最小公倍数ではなく、妥協をしないソフトウエア作りを行うことで、より大きな効果を得られるのではないでしょうか。
実際にクロスプラットフォームを実現するとなると、どうしても、WindowsのOS機能を使ったプログラムを作成したり、あるいはUNIXの機能を使う必要も出てきます。特にWindowsはJavaという環境をOSメーカーであるMicrosoft社が独自の定義を行い、本来は共通化しているようなGUI処理の部分にまで、Windows独自の環境を構築しています。そのあたりが、Appleの取り組みと大きな違いです。AppleはGUIなどの共通化された部分はその共通化された機能を使い、Mac OSにしかない独自の機能を、Apple独自のクラスライブラリで利用できるようにしているのです。
WindowsでのJavaの扱いは、SunとMicrosoftとの訴訟に発展してしまっているほど簡単には解決しない問題になってしまっています。その意味では、WindowsでJavaがどうなるかということはまだまだ不確定要素が存在し、スタンスを取りづらい状態ではないでしょうか。もっとも、Microsoftはそうしたところを狙ったとも見えるところです。
Macintosh Java ReportはMac OSにおけるJava利用をターゲットにしているので、Windows環境での開発を詳しく取り上げることはしませんが、クロスプラットフォーム開発となると、どうしてもWindowsの状態を見なければなりません。対岸の事とは思わずに、Windowsでの状況からも目を離さないようにしなければならないでしょう。
（第1章終わり）