いまどきのプログラム言語の作り方  プログラミング未経験者のための基本情報技術者 午後［プログラム言語］  やさしいＪａｖａ 第３版（やさしいシリーズ）  |
Java（ジャバ）は、狭義ではオブジェクト指向プログラミング言語Javaであり、広義ではプログラミング言語Javaのプログラムの実行環境および開発環境をいう。 このJavaプログラムの実行環境と開発環境 (広義のJava) は、Javaプラットフォームとも呼ばれる。 Javaは、従来のさまざまな言語の良い部分を引き継ぎ、欠点を克服するよう設計された。 次のような特徴をもつ。
現在、Javaの技術は、情報技術のローエンドからハイエンドまで幅広く使われている。 組み込みシステムや携帯機器（携帯電話・PHSやPDA・スマートフォン等）のシステムから、企業の情報システムを担う大規模なサーバやスーパーコンピュータまで、非常に多くの分野で活用されている。 概要プログラミング言語JavaおよびJavaプラットフォームは、1990年代前半にサン・マイクロシステムズ社でジェームズ・ゴスリンなどの人々によって開発された。Java技術の標準化作業は、Java Community Process (JCP)というプロセスを経て行われている (#Java技術の標準化)。 Javaに関わる呼称とその意味内容は、文脈に応じていくつか使い分けられている。サン・マイクロシステムズは、「Javaテクノロジ」(Java技術、Java technology)という呼称を使い、一方でJavaのさまざまな技術の形容詞として「Java」の呼称を使ってきた。多くのプログラマは、プログラミング言語の意味で「Java」の呼称を使っている。Javaの実行環境は、Java実行環境 (Java Runtime Environment; JRE)と呼ばれる。Javaの基本的な開発環境は、Java開発キット (Java Development Kit; JDK)と呼ばれる。 Javaはクラスベースのオブジェクト指向プログラミング言語である (オブジェクト指向プログラミング)。Javaのプログラムは複数のクラスから構成され、プログラムの実行は、各クラスが実体化したオブジェクト群が相互にメッセージをやりとりしながら行われる。Javaでは、継承については実装の単一継承を採用している。ただし一つのクラス (オブジェクト) は複数のインタフェースを実装できる。Javaで扱うデータ/オブジェクトの型 (データ型) は、強い静的型付けを採用している。Javaのコンパイラおよび実行環境が、型同士の整合性を検査することによって、プログラムが正しく記述されていることや、安全に動作することの検証が、可能である。 Javaは例外処理機構を備えており、プログラム実行中に生じた異常 (例外) の扱いを、比較的安全な方法で行い、プログラムを読みやすく記述することができる。 Javaでは簡潔なメモリモデルを採用しており、プログラマがメモリ (主記憶装置) を管理する負担を軽減する (自動ガーベジコレクション) 。あらゆるオブジェクトはメモリ内のヒープという領域に割り当てられる。メモリ管理は、Java仮想マシンに統合された自動ガーベジコレクションの機能によって行われる。従来のオブジェクト指向プログラミング言語である C++では、ヒープ領域に生成したオブジェクトについて、もはや必要が無くなった時に破棄する指示を、プログラマが自分で責任をもって行わなければならなかった。これは、C++ プログラマにとっては負担が大きく複雑で間違えやすい作業であり、ソフトウェアの安全性・開発効率・保守性を損なう要因であった。Javaでは自動ガーベジコレクションの機能があるため、このようなことは無く、プログラマの負担は大きく軽減される。 Javaの文法は、CおよびC++から多くを引き継いでいる (文法) 。ただし、C/C++の低水準のポインタなどの要素は排除されている。 Javaではプラットフォーム非依存を目標の一つとし、またバージョン間の互換性に注意して開発が進められている (プラットフォーム非依存) 。Java技術を使うことで、プラットフォームに依存しないアプリケーションソフトウェアの開発と配備を行うことができる。従来のプログラミング言語の多くはプラットフォーム (CPU)に依存したネイティブなコードにコンパイルすることを前提として設計されていたが、Javaはこうした言語と異なり、中間言語 (バイトコード) にコンパイルされ、Java仮想マシンで実行されるよう設計された (多くの場合、ジャストインタイムコンパイル方式が使われる)。 プラットフォーム非依存とバージョン間の互換性の目標は、完全に達成できたわけではなく課題が残っている (Java批評#移植性・互換性) 。 Javaではスレッドを言語仕様で規定しており、マルチスレッドによる並列処理を、従来の言語と比べて簡単に実装することができる。なお並列処理は、複数の処理を同時に実行する処理形態である。またスレッドは、プロセスより小さく軽量な処理の単位である。 Javaでは充実したライブラリにより、コンピュータ・ネットワークを活用するソフトウェアを、効率良く開発することができる (ネットワーク機能) 。Javaの初期のバージョンから、TCP/IPのライブラリを備えていた。分散オブジェクト環境 (Java RMI、CORBA)のソフトウェアの開発も早い時期からできるようになっていた。近年では、さまざまなネットワークプロトコルの高水準なライブラリが使えるようになっている。充実したネットワーク機能と次に述べるXML文書を扱う機能を有効に組み合わせることにより、これまでにない高度なシステムの構築ができる言語の一つである。 XML文書を扱う機能も早期に実用化された。XMLは、広く普及している構造化文書の技術である。近年では、XMLプロセサとXSLTプロセサがJava標準ライブラリに統合され提供されている。 Javaはセキュリティを考慮して設計されており、サンドボックスモデルに基づいたセキュリティ機構を備えている (セキュリティ) 。セキュリティ機構を正しく実装したJava実行環境を適切に使うことで、遠隔のコンピュータ上にある実行コードを安全に実行することができる (Javaアプレット) 。 また、名前空間の機構をもつ言語であり、ライブラリおよびアプリケーションに含まれる多数のJavaのプログラム (クラスとインタフェース) は、パッケージという階層構造で管理することができる (名前空間) 。 現在、Javaの技術は、情報技術のさまざまな領域、ローエンドからハイエンドまで、幅広く使われている (近年の動向) 。携帯機器やウェブサーバ、企業の基幹となる情報システムにおいて、非常に普及している。パーソナルコンピュータ (PC)でも使われている。C++などの言語とともに、現在最も広く使われているオブジェクト指向プログラミング言語の一つである。 Javaに対しては批判も少なくない (批判) 。いくつかの批判に対しては、サンやJCPに参加する人々の努力により、Javaの改良が行われている。一方で現在、多くのソフトウェア開発者は、Javaについて、広く使われている言語としては優れた技術の一つと評価している。 JavaScript (ECMAScript)は、Javaとは直接の関係は無いが、Javaと似た言語名称と構文を持っている。 歴史この節では次の構成で Java の歴史と近況を説明する。
草創Javaプラットフォームおよびプログラミング言語Javaは、1990年12月にサン・マイクロシステムズ社が一つの内部プロジェクトを立ち上げたことから始まった。 この内部プロジェクトでは、C++/C の代替となるプログラミング言語を開発した。 この言語は、プロジェクトで Greenオペレーティングシステム (Green OS) と共に、同OSの標準言語として開発された。 この言語は、1992年頃プロジェクト内では Oak と呼ばれていたが、後に Java の呼称に変更されることになる。 呼称変更の理由は、Oak は既に別の会社が商標として使っていたからである。 1990年頃、サンの技術者パトリック・ノートンは、自社のプログラミング言語 C++ と C の API (アプリケーションプログラミングインタフェース) と開発ツールに不満を募らせていた。 その頃、情報技術の世界でNeXT社が開発した技術が注目を浴びていたことがきっかけとなって、ノートンはサンで新技術の仕事をすることになった。
こうした経緯のなかで「ステルスプロジェクト」が始まった。 ステルスプロジェクトには、始まってすぐにジェームズ・ゴスリンとマイク・シェルダンが参加し、プロジェクトの名称は「グリーンプロジェクト」に変更された。 プロジェクトには他の技術者たちも参加し、彼らはアメリカ合衆国カリフォルニア州メンロパーク市サンドヒルロードの道沿いにある小さなオフィスで作業を始めた。 プロジェクトの目的は、次世代の家電製品のための新しいプログラミング技術を開発することであった。 サンはこの分野が重要な市場になると予測していた。 プロジェクトチームでは当初はプログラミング言語としてオブジェクト指向プログラミング言語である C++ を採用することを検討していたが、いくつかの理由から C++ は却下された。 彼らの目的は、家電製品すなわち組み込みシステムの技術を開発することであった。 組み込みシステムでは、利用できるコンピュータ資源が少ないという制約がある。 彼らは C++ ではコンピュータ資源を食いすぎると判断した。 また C++ は複雑なプログラミング言語であり、C++ を使うプログラマは注意していても間違いを犯しがちである。
プロジェクトチームは、いくつかの重要な機能について C++ の移植性が乏しいことも問題であると考えた。 このプロジェクトでの重要な機能とは、セキュリティおよび分散コンピューティング、マルチスレッドであり、これらの機能が、プラットフォームに依存せずに使える必要があった。 このような事情で、彼らはあらゆる機器に容易に移植できるプラットフォームが必要であると認識するようになった。 一方で、サンの技術者ビル・ジョイは、プログラミング言語 MesaとCの良いとこどりをした新しいプログラミング言語を構想していた。 ジョイは Further という名前で呼ばれる論文を書き、自社で C++ に基づいたオブジェクト指向環境を開発するべきであることを進言した。 まずジェームズ・ゴスリンが C++ を改変し拡張することを試みた。 ゴスリンはこの拡張版C++を、"C++ ++ --" と名付けた。 しかしゴスリンは、すぐにこの拡張版C++の開発を中止して、全く新しいプログラミング言語を開発する方針を採ることにした。 ゴスリンはこの新しい言語に Oak という名前をつけた。 この名前の由来は、ゴスリンのオフィスのすぐそばにオーク (Oak) の木が立っていたことによる。 プロジェクトチームは残業までして作業を続け、1992年の夏までに新しいプラットフォームを、Greenオペレーティングシステム、Oak言語、ライブラリ、ハードウェアによって部分的なデモンストレーションができるようになった。 1992年9月3日の最初のデモンストレーションでは、チームは Star7というPDA (携帯情報端末) 機器を開発することに力点をおいていた。 このPDA機器は、グラフィカルなインタフェースを備え、"Duke" という名前の知的な仮想代理人が利用者を支援した。 同年11月、サンはグリーンプロジェクトを分離して完全子会社の FirstPerson, Inc を設立した。 それにともないチームはパロアルトに引っ越した。 FirstPersonチームは、高度にインタラクティブな機器に関心を持っていた。 そのおりタイム・ワーナー社がケーブルテレビのセットトップボックスの RFP (Request For Proposal) を公表していた。 そこでFirstPersonチームは自分たちの目標を変更し、タイム・ワーナーの RFP に応じてセットトップボックスの提案を提出した。 しかしながら、 FirstPersonは入札でシリコングラフィックス社 (SGI) に負けた。 その後に3DO社のセットトップボックスの案件もあったが、契約には至らなかった。 FirstPersonはテレビ業界では利益を出すことができず、サンはFirstPersonを解散してチームを自社に戻した。 インターネットの世界へ1994年の6月から7月にかけて、ジョン・ゲージと、ジェームズ・ゴスリン、ビル・ジョイ、パトリック・ノートン、ウェイン・ロジン、エリック・シュミットの間で、3日間かけてブレインストーミングを行い、プロジェクトチームはウェブ (World Wide Web) の世界に主眼を置くという方針変更を行った。 彼らは、革新的なウェブブラウザである NCSA Mosaic の出現を目の当たりにし、ウェブを含むインターネットの世界は、ケーブルテレビの世界に劣らず、高度にインタラクティブな媒体に発展しつつあると認識するようになった。 Oak を使ったプロトタイプとして、ノートンは WebRunner という小さなウェブブラウザを開発した。 このウェブブラウザの名称は後に HotJava と変更された。 ウェブページにJavaアプレットという小さなJavaプログラムを埋め込んでおいて、ウェブブラウザ HotJava でそのページにアクセスすると、HotJava 上でアニメーションの表示やマウスによるインタラクティブな操作ができた。 同年、チームは Oak の名称を Java に変更した。 変更の理由は、商標を調べて、"Oak" という名前がすでにビデオカードアダプタの製造会社 (Oak Technology社) によって使われていたことが判明したからである。 Java という名称は、一部のチームメンバーがよく出入りしていた近くのコーヒーショップで命名された。 この名称が、何かの頭字語 (アクロニム) であるかどうかについては、よくわかっていない。
1994年10月に、HotJava とJavaプラットフォームが、サン・マイクロシステムズの幹部社員の前でデモンストレーションされた。 そして1994年内に Java 1.0a (アルファ版) がダウンロードできるようになった。 Java と HotJava が最初に公的な場で公表されたのは、1995年5月23日のSunWorldカンファレンスであった。 サンは、Javaで記述されたウェブブラウザ HotJava を使って、JavaとJavaアプレットの技術により、ウェブページ内でアニメーションの表示やマウスによるインタラクティブな操作が可能であることをアピールした。 カンファレンスでアナウンスを行ったのは、サンの技術部長ジョン・ゲージである。 このカンファレンスではまた、ゲージのアナウンスに関連する、マーク・アンドリーセン （ネットスケープコミュニケーションズの上級副社長）によるアナウンスが人々を驚かせた。 それは、ネットスケープが自社のウェブブラウザである Netscape Navigator に Java の実行機能を追加する予定であるというものであった。 このアナウンスにより情報技術の世界でJava技術は広く知られるようになった。 1995年秋には Java 1.0 のベータ版が公開された。 1996年1月9日にサンは、Java技術の開発を行うJavaSoft部門を立ち上げた。 その2週間後に、最初の正式バージョンである Java 1.0 がリリースされた。 近年の動向Java の最初のバージョンが公開されてから現在までの動向を、いくつかの側面から述べる。 ウェブ (クライアント側)ウェブブラウザでJavaアプレットを実行する技術は、広く使われている。 Javaアプレットは、ブラウザ（ウェブのクライアント側）がウェブページ内でアニメーションの表示やマウスによるインタラクティブな操作を可能とする技術である。 ただし、いくつかの有力な競合技術も存在する。 近年では、Yahoo! Games やビデオプレイヤーなどのアプリケーションで、Javaアプレットを採用する事例が多い。 かつては、Javaアプレットを使用したサイトを表示すると、数十秒〜数分間操作を受け付けないブラウザが存在した。近年は、JavaおよびJavaアプレットの技術の向上により、環境によって動作が異なったり、実行速度、特に画面の描画が遅いという問題が解消されつつある。 簡単でインタラクティブなアニメーション用には、Javaアプレットよりも GIF89a や 有償のMacromedia Flash を採用する事例が多い。 この分野においては、最近では Ajax も普及しつつある。 ウェブ (サーバ側)現在、ウェブのサーバ側において、Java技術 (Java EE) は広く使われている。 多くのウェブサイトが、Javaサーブレット (Java Servlet) や JSP (JavaServer Pages) などの Java EE 技術を使って動的にページを生成するウェブを構築している。 サーブレットは2000年前後から急速に広く使われるようになり、現在では多くのウェブアプリケーション（動的なウェブページ）がサーブレットとして稼動するようになっている。 サン・マイクロシステムズが開発したJavaサーブレット技術を簡単に説明する (必ずしも厳密な説明ではない) 。
サンがJavaサーブレット技術を開発した当時 (1990年代末) 、ウェブアプリケーションの開発には、次に述べるようないくつかの問題があった。
サーブレットはこれらの問題をある程度解決することができる技術であった。 デスクトップにおける展開デスクトップ環境においては、スタンドアロンのJava (Java SE) のアプリケーションソフトウェア (Javaアプリケーション) は、これまではあまり多く使われていなかったが、近年はいくつかのソフトウェアが広く使われるようになっている。 近年になって使われるようになってきた理由としては、次のことが挙げられる。
広く使われているJavaのソフトウェアとしては、NetBeans および Eclipse の統合開発環境や、LimeWire や Azureus のようなファイル共有クライアントのソフトウェアなどがある。 また数学ソフトウェア MATLAB においても、ユーザインタフェースのレンダリングと計算機能の一部を実現するために使われている。 多くの Java の Swing や SWT のウィジェット・ツールキットを使ったアプリケーションが、現在も開発されている。 このように、近年はデスクトップ上でJavaアプリケーションを使う事例が増えつつあるものの、従来は次に述べるいくつかの理由のためにあまり使われてこなかった。
一部のソフトウェア開発者は、情報技術はウェブを基盤としたモデルが主流となっており、スタンドアロンアプリケーションは流行遅れであり、新しいプログラミング技術は優れたウェブアプリケーションを開発することに充てられている、と思っていた。この見解については、ソフトウェア技術者の間で賛否が分かれている。 現在では、リッチクライアントやWeb2.0の登場により新たなパラダイムが生まれようとしている。すなわちウェブを基盤としたウェブアプリケーションとスタンドアロンアプリケーションの融合である。ウェブアプリケーションをAjaxや Java Web Start、Adobe Flash などと組み合わせることにより、Web2.0時代に見合ったより洗練されたアプリケーションを開発することができる。 パーソナルコンピュータにおける実行環境現在、ほとんどの パーソナルコンピュータ (PC) のユーザは、何ら問題なくウェブおよびデスクトップ環境上でJavaアプリケーションを実行できる。 多くのPCメーカーは、自分たちが製造・販売する Windows PC にJava実行環境 (Java SE) を同梱している。 アップルコンピュータ社の Mac OS X や、多くのLinuxディストリビューションでも、Java実行環境を同梱している。 そのため、マイクロソフト社が2001年頃以降にJava実行環境をWindowsに同梱していないことの影響は、小さい。
しかし近年では、Javaアプリケーションパッケージ自体にJava実行環境を同梱する事例が少なくない。 その背景にはJavaアプリケーション開発者の判断がある。 Javaアプリケーションが想定どおりに機能するよう、Java実行環境のバージョンの違いによる非互換性に基づく不具合を避けるために、PCに同梱されているJava実行環境を使わないという判断である。 現在では、Javaアプレットは動作対象のJava実行環境のバージョンを認識することができる。 また、バージョン間の互換性もそこそこ高い水準にあり、上位互換性についてはjava SE 1.3以降は大きな問題はほぼおきにくくなっている。さらに Java Web Start ではデスクトップにインストールされているJavaのバージョンを確認してアップデートできるならアップデートし、それだけでなく Java Web Start 対応アプリケーションをもアップデートしようとする。 そのため古いバージョンのJava実行環境を使っているマシンがあったとしても、自動アップデートされるためにそう難しい問題は起きない。 組み込みシステム組み込み機器 (組み込みシステム) 向けの Java (Java ME) も広く使われている。 携帯機器（携帯電話・PHSやPDA・スマートフォン等）にJavaの実行環境が実装されるケースが多い。 Java環境はこれら携帯機器全般に広く普及している。一方、 Symbian および BREWは携帯電話を主なターゲットとし、Javaと競合している。 Java ME では、BREW とは異なり、開発者がライセンス料を支払わずに、プログラムを開発することができる。 Java ME は Symbian より広く普及している。 その理由は、Java ME が Symbian より広範な携帯機器、特に廉価なモデルで動作するからである。 こうした事情からサードパーティにより Opera mini のようなフリーのJavaソフトウェアを開発することができるようになった。 携帯機器の Java ME プログラムは、サンドボックスのもとで動くため、多くの開発者が特別な配慮をせずにプログラムを開発しても、安全に実行できる。 携帯機器のJava技術が多様化するに伴い、異なるメーカーの携帯機器でもJavaプログラムが動くよう、携帯機器のためのJava技術の標準が必要となった。 携帯機器のための Java ME の標準が MIDP (Mobile Information Device Profile) である。 最初の標準は MIDP 1 で、小さい画面を想定したものであり、音声機能は無く、プログラムサイズは 32kB までという制限があった。 後の MIDP 2 の標準では、音声機能を備え、プログラムサイズの制限は 64kB までと緩和された。 携帯機器の設計の進歩は標準化よりも急速であるため、一部のメーカーは、MIDP 2 標準の最大プログラムサイズなどいくつかの制限を、意図的に緩和して携帯機器を開発している。 携帯機器における Java ME の競合技術について簡単に述べる。
世界的な動向としては、
また、2001年にはソニー社のコンシューマゲーム機 PlayStation2 にJava仮想マシンが搭載される予定と発表され話題になった。 バージョン履歴Java は、JDK (Java Development Kit; Java開発キット) 1.0 以来、数度のメジャーバージョンアップを経ている。 バージョンアップに伴い、多くのクラスとパッケージが標準ライブラリに追加されてきた。 プログラミング言語JavaおよびJavaプラットフォームは、高い水準でバージョン間の互換性を保ちつつ発展してきている。 J2SE 1.4 から、Javaの開発は JCP (Java Community Process) という標準化プロセスで行うようになっている。 JCP では、JSRs (Java Specification Requests) という文書群により、Javaに対する追加機能やJavaプラットフォームに対する変更の提案と規定を行う。 言語仕様は JLS (Java Language Specification; Java言語仕様) により規定する。 JLS は JSR 901 の管理下にある。
void displayWidgets (Iterable<Widget> widgets) { for (Widget w : widgets) { w.display(); } } この例では、
バージョンアップの過程で、言語仕様の変更だけでなく、標準クラスライブラリにおいても大きな変更が加えられている。 JDK 1.0 では標準ライブラリは約200クラス/インタフェースであったが、Java SE 6 では4000以上のクラス/インタフェースとなっている。 Swing や Java 2D のような全く新しいAPIが追加された。 その一方で、もともと JDK 1.0 から存在していたクラスのメソッドの多くが、J2SE 5.0 での使用は推奨されないようになっている。 特徴Javaの主な特徴を述べる。 思想Javaを開発する上では、5つの目標があった。
ネットワーク機能および遠隔コンピュータの実行コードの実行を実現するために、場合によっては、Javaプログラマは、CORBA や Internet Communications Engine、OSGi のような拡張機能を使う。 オブジェクト指向プログラミングJavaはクラスベースのオブジェクト指向プログラミング言語である。 Javaのプログラムは複数のクラスから構成され、プログラムの実行は、各クラスが実体化したオブジェクト群が相互にメッセージをやりとりしながら行われる。 Javaでは、実装の単一継承を採用し、一つのクラスが複数のインタフェースをもつことができる。 クラスとは、オブジェクト指向においてオブジェクトの設計図にあたるものである。 オブジェクトについては後述する。 継承とは、既存のクラスを基にして、そのクラスの機能を引き継いだ新しいクラスを定義できることをいう。 Javaでは実装の多重継承は採用していない。 Javaでは一つのクラスが複数のインタフェースをもてるため、一つのクラスに複数の役割をもたせることができる。 Javaで扱うデータ/オブジェクトの型 (データ型) は、強い静的型付けを採用している。 静的型付けにより、Javaのコンパイラおよび実行環境が、型同士の整合性を検査することによって、プログラムが正しく記述されていることや、安全に動作することの検証が、可能である。 Javaのデータ型には、参照型 (reference type) と基本型 (プリミティブ型、primitive type) の2種類がある。 Javaのオブジェクトは全て参照型である。 Javaの基本型は、単純な構造のデータ (数値、論理値、文字 など) のための型である。 Javaの標準ライブラリは、基本型の値をオブジェクトとして扱えるようにするためのクラス (ラッパクラス) を提供している。 近年のJava (J2SE 5.0) からは型の扱いに改良が加えられている。
Javaの特徴の一つであるオブジェクト指向プログラミングは、プログラミングおよびプログラミング言語設計の手法をいう。 Javaはオブジェクト指向プログラミング言語である。 オブジェクト指向の概念に対しては、多くの解釈がなされてきた。 一般には、オブジェクト指向を特徴づける重要な考え方は、ソフトウェアで扱うさまざまな種類のデータについて、データとそのデータに関連する手続きを一体化するように、ソフトウェアを設計することである。 こうして、データとコード (手続き) は、オブジェクトと呼ばれる実体に一体化される。 オブジェクトとは、状態 (データ) と振る舞い (コード、手続き) がひとかたまりとなったものと、考えることができる。 Java では、オブジェクトの設計図であるクラスに定義する振る舞い (コード) を「メソッド」と呼び、状態 (データ) を「フィールド」 (インスタンス変数) と呼ぶ。 オブジェクト指向以前の技術での本質的な問題点は、プログラムにおいて、データと振る舞い (コード) が、分離されていたことである。
オブジェクト指向に基づいて、これまで分離されていた状態 (データ) と振る舞い (コード) を、オブジェクトに一体化することは、ソフトウェアシステムの設計において堅牢な基盤となる。 オブジェクト指向を有効に活用することにより、大規模なソフトウェア開発プロジェクトを管理することの困難さが軽減され、ソフトウェアの品質が向上し、失敗するプロジェクトの数を減らすことができる。 オブジェクト指向のもう一つの目標は、汎用的なオブジェクトを開発することで、プロジェクトをまたがってソフトウェアをより再利用可能にしてゆくというものである。 例えば、汎用的な「顧客」オブジェクトは、別のプロジェクトにおいても、理論的にはほぼ同一の手続き群を備えるであろう。 大きな組織において、その組織の複数のプロジェクトが機能的に共通する基盤層をもつ場合は、なおさらソフトウェアの再利用が重要となる。 こうしたことから、ソフトウェアオブジェクトは、さまざまなシステムに組み込み可能であるように、汎用性を備えていることが望ましい。 こうすることで、ソフトウェア業界は、既存のしっかりテストされたオブジェクトコンポーネントを活用してプロジェクトを進めることができ、開発期間を大幅に短縮することができる。 一方で、ソフトウェアの再利用性を高めるということには、実践においては、2つの大きな困難を伴う。
いくつかのオープンソースコミュニティでは、再利用に伴う問題を軽減するために、オブジェクトやクラスライブラリの開発者に、自分たちが開発した汎用的で再利用可能な開発物についての情報を広報する手段を提供している。 プラットフォーム非依存Javaのもう一つの特徴はプラットフォームに依存していないことであり、これは、Javaのプログラムがさまざまなハードウェアやオペレーティングシステム上で必ず同じように動くということを、意味する。 一度Javaのプログラムを作成すれば、そのプログラムはどのプラットフォーム上でも動くのである。 近年では、Java実行環境を構成するJava仮想マシンに高速化の技術が導入され、プラットフォームに依存したプログラムと同水準の実行性能を実現している。 Javaのプラットフォーム非依存は、次のようにして実現されている。
また、実際にはJavaコンパイラの実装として、ソースコードから直接にプラットフォームのハードウェアにネイティブなオブジェクトコード(機械語コード) を生成するものがある。 このようなJavaコンパイラの実装としては GNU の GCJ などがある。 この場合、中間言語のバイトコードを生成するという段階は省かれる。 しかしこの方法で生成されるJavaの実行コードは、コンパイル時に指定したプラットフォームでしか動かない。 Javaの実行コード (バイトコード) を生成する手段としては、プログラミング言語Javaでプログラムを書くことが標準的なやり方である。 Javaのバイトコードの実行は、Java仮想マシンという仮想マシンの環境上で行われる。 Java仮想マシンは実行時にバイトコードをネイティブコードに変換する。 なお、Javaのバイトコードを生成する他の方法としては、Ruby (JRuby) や Groovy 、Python (Jython) などのプログラミング言語でプログラムを書くこともできる。 サン・マイクロシステムズのJavaのライセンスは、全てのJava実行環境の実装は「互換性」を備えるべきであることを要求する。 最初期のJava実行環境の実装では、Javaプログラムの実行速度が遅かったが、近年では大きく改善されて、高速に実行できるようになった。 最初期のJava実行環境のJava仮想マシンの実装は、移植性を実現するためにインタプリタとして動作する仮想マシンを採用した。 こうした初期のJava実行環境の実装では、Javaプログラムの実行速度が C や C++ のプログラムと比べて遅かった。 そのため、Javaプログラムの実行速度は遅いという評判が広まった。 近年のJava実行環境の実装では、いくつかの技術を導入することにより、以前と比べて、Javaプログラムをかなり高速に実行できるようになった。 Javaプログラムを高速に実行するために使われる技術を説明する。
Java仮想マシンにジャストインタイムコンパイルと動的再コンパイル、世代別ガーベジコレクションの技術を導入することにより、Javaプログラムは、移植性を保ちつつ、ネイティブコードと同水準で高速に実行することができるようになった。 Javaの移植性 (プラットフォーム非依存) がどの程度実現できているかについては、議論の対象となっている。 技術的には移植性とは実現が難しい目標である。 多くのプラットフォームにおいて同一に動作するJavaプログラムを作成することは、可能である。 しかし実際には、Javaを利用できるプラットフォームによってはちょっとしたエラーが発生したり、微妙に異なる動作をする事例が多い。 こうしたことから一部の人々は、サン・マイクロシステムズのJavaの売り文句である "Write once, run anywhere" (一度コードを書けば、どの環境でも動く) をもじって "Write once, debug everywhere" (一度コードを書けば、どの環境でもデバッグが必要) と皮肉をいわれることがある。 しかしながら、Javaのプラットフォーム非依存は、サーバ側や組み込みシステムのアプリケーションに関しては、非常に成功している。 サーバ側 (Java EE) では、Javaの サーブレット、Webサービス、EJB (Enterprise JavaBeans) などの技術が広く使われている。 組み込みシステムの分野においても、組み込みシステム向けのJava環境 (Java ME) を使った OSGi を基にした開発が広く行われている。 自動ガーベジコレクションJavaでは、自動ガーベジコレクションを備えており、この機能を備えていない従来の多くの言語と比べて、プログラムの開発生産性と安定性が高い。Javaの自動ガーベジコレクションにより、プログラマの負担は、完全に解消されるわけではないものの、大きく軽減される。近年のJavaの自動ガーベジコレクションでは世代別ガベージコレクションという効率的な技術を導入している。自動ガーベジコレクションを備えていない言語である C++の場合は、プログラマは自分自身でメモリ (主記憶装置) の管理をしなければならないという負担に苦しめられる。 Javaでは、自動ガーベジコレクションを備えていない言語における潜在的な問題は、自動ガーベジコレクション機能によって、その多くを未然に防ぐことができる。 プログラマは任意の時点でオブジェクトを生成することができ、Java実行環境は生成されたオブジェクトのライフサイクルを管理する責任をもつ。 プログラム (オブジェクト) は、他のオブジェクトへの参照をもち、そのオブジェクトのメソッド (手続き) を呼び出すことができる。 他のオブジェクトへの参照とは、低水準の視点で述べると、メモリ (主記憶装置) 内のヒープという領域上に確保されたそのオブジェクトを指すアドレスのことである。 オブジェクトがどこからも参照されなくなった場合、Javaのガーベジコレクション機能が自動的にその「到達不可能なオブジェクト」を削除し、そのメモリ領域を開放することで、メモリリーク (解放し忘れた未解放メモリが累積していき利用できるメモリの量が減ってゆく問題) を防ぐ。 ただしJavaの自動ガーベジコレクション機能は、メモリリークの問題を完全に解消するわけではない。 プログラマが、自分のプログラムでもはや必要のないオブジェクトへの参照を保持し続けた場合は、やはりメモリリークが発生する可能性がある。 別の表現で述べると、Javaでは、メモリリークは概念的に高い水準においては、発生する可能性が残っているということである。 概念的に低い水準においては、正しく実装されたJava仮想マシンを使えば、メモリリークが発生する可能性は無くなった。 全体として、Javaの自動ガーベジコレクション機能により、C++の場合と比べると、オブジェクトの生成と削除は、より簡潔になり、潜在的に安全になり、また多くの場合は高速になっている。 C++においても、しようと思えば、Javaと同等のメモリ管理の高速性と効率性を実現することはできるが、先に述べたとおり、複雑な作業で間違えやすく、完璧に行おうとすれば開発期間が非常に長くなり、開発したソフトウェアはかなり複雑で難解になる。 例えば、C++で特定のクラスを対象として、高速実行およびメモリ利用の断片化の最小化を、高水準で達成できるメモリ管理モデルで設計開発する技法があるが、こうした技法は複雑である。 自動ガーベジコレクションの機構は、Java仮想マシンに組み込まれており、開発者からは、事実上隠蔽されている。 開発者は、場合にもよるが、ガーベジコレクションがいつ起こるか意識しなくて良い。 というのも多くの場合、ガーベジコレクションの実行は、プログラマが自分で書いたコードによって明示的に起こる何らかの挙動と、必ずしも関連しているわけではないからである。 ネットワーク機能Javaでは充実したライブラリにより、コンピュータ・ネットワークを使うソフトウェアを、効率良く開発することができる。 Javaの初期のバージョンから、TCP/IP (IPv4) のライブラリを備えており、ネットワークでソケット通信を行うソフトウェアを簡単に実装することができた。 分散オブジェクト環境のソフトウェアの開発も早い時期からできるようになった。 Java RMI もしくは CORBA の分散オブジェクト技術を標準で使うことができる。 近年では、標準、拡張その他のライブラリにより、さまざまなネットワークプロトコルを高水準で扱えるようになっている。
現在では IPv6 も扱えるようになりつつある。 XML 文書を扱う技術とネットワーク機能を有効に組み合わせることにより、高度なシステムやサービスを構築できるようになっている。 セキュリティJavaでは初期のバージョンから遠隔のコンピュータ上にある実行コード (Javaアプレット) を安全に実行できるよう設計されていた。
名前空間Javaは、パッケージという名前空間の機構をもつ言語であり、ライブラリおよびアプリケーションソフトウェアに含まれる多数のJavaのプログラム (クラスとインタフェース) を、パッケージの階層構造に分類・整理することができる。 名前空間の機構をもたない言語と比べて、多数のクラスとインタフェースの管理が容易となり、クラスとインタフェースの命名についても、既存のものとの名前の衝突回避を考慮する労力が、大きく軽減される。 実行形態Javaのバイトコードには複数の実行形態があると考えることができる。 ただしいずれのバイトコードも、Java実行環境 (JRE) のもとで実行されるという点では、同じと考えることもできる。
文法プログラミング言語Javaの文法は、C および C++ から多くを引き継いでいる。 このためJavaの文法は、多くのプログラマにとって習得しやすくなっている。 Javaが世に現れる以前は、Cのプログラマが多く、またオブジェクト指向プログラミング言語の中では、C++は広く使われてきた言語の一つであった。 しかし Java では、C++ とは違って、言語の基礎的な部分から全体にわたって、オブジェクト指向プログラミングの思想が貫かれている。 C++ の文法は、構造化プログラミング、総称的プログラミング (generic programing) 、およびオブジェクト指向プログラミングの構文が集まってハイブリッドに構成されている。 Javaでは、若干の例外を除き、全てがオブジェクトであり、全てはクラス内に記述する。 Hello world次の節以降では、Hello world プログラムで、Javaプログラムの例を示して説明する。
なお先に述べたとおり、Javaには複数の実行形態があると考えることができるので、以降では、それぞれの実行形態における Hello world プログラムを例示する。 例: スタンドアロン (コマンドライン)コマンドライン環境で動くスタンドアロンのJavaアプリケーションの例を示す。 Javaでは、他のプログラミング言語と同様に、コマンドライン環境で動くプログラムを簡単に開発できる。 // Hello.java public class Hello { public static void main(String[] args) { System.out.println("Hello, world!"); } } このプログラムについて説明する。
例: スタンドアロン (Swing)グラフィカルユーザインタフェース (GUI) 環境で動く Swing を使ったスタンドアロンのJavaアプリケーションの例を示す。 Swing は、Java SE の高度な GUI のウィジェット・ツールキットのライブラリである。 // Hello.java import javax.swing.*; public class Hello extends JFrame { Hello() { setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); add(new JLabel("Hello, world!")); pack(); } public static void main(String[] args) { new Hello().setVisible(true); } }
例: アプレットJavaアプレットは、他のアプリケーションに埋め込まれるプログラムである。 多くの場合は、ウェブブラウザに表示されるウェブページに埋め込まれる。 // Hello.java import java.applet.Applet; import java.awt.Graphics; public class Hello extends Applet { public void paint(Graphics gc) { gc.drawString("Hello, world!", 65, 95); } } <!-- Hello.html --> <html> <head> <title>Hello World Applet</title> </head> <body> <div> <applet code="Hello" width="200" height="200"> </applet> </div> </body> </html>
例: サーブレットJavaサーブレットは、サーバ側の Java EE の構成要素であり、クライアントから受けた要求 (request) に対する応答 (response) を生成する。 現在、多くの場合はウェブブラウザから要求を受け、応答としてXHTML/HTMLのウェブページを動的に生成する。 // Hello.java import java.io.*; import javax.servlet.*; public class Hello extends GenericServlet { public void service(ServletRequest request, ServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter pw = response.getWriter(); pw.println("Hello, world!"); } }
構成Javaプラットフォームの構成を説明する。
Java実行環境Java実行環境 (JRE; Java Runtime Environment) は、Javaプラットフォームに配置されたJavaアプリケーションを実行するために必要な、ソフトウェアである。 標準クラスライブラリやJava仮想マシンなどから構成される。 エンドユーザは普通、Javaソフトウェアパッケージやウェブブラウザプラグインの利用を通じて JRE を使う。 サン・マイクロシステムズ/JCP をはじめ複数の団体や企業により、 さまざまなプラットフォーム向けに、多くの JRE の実装が開発・提供されている。 JRE の他、サン/JCPなどの団体・企業は、Java開発キット (JDK) と呼ばれる JRE のスーパーセットの実装を開発・提供している。JDK は、Javaプログラムの開発を支援する基本的なソフトウェアであり、多くの開発ツールが含まれている。 実行環境の構成Java実行環境は、標準クラスライブラリとJava仮想マシン、およびいくつかのファイルとソフトウェアから構成される。
Java開発キットJava開発キット (JDK; Java Development Kit) は、サン/JCP をはじめ複数の団体や企業により開発・提供されている、Javaプログラムの開発を支援する基本的なソフトウェアである。 Javaが世に出て以来、広く使われてきたJavaの開発ツールである。 Javaコンパイラ、javadoc、デバッガなどを含む多くの開発ツールが含まれている。 また、完全なJava実行環境 (JRE) を同梱している。 Javaプログラムを実行するだけであれば、Java開発キットを導入する必要は無い (Java実行環境が導入されていれば良い) 。 Java開発キット (JDK) の呼称は、これまでに何度か変更されている。
JREとJDKの複数の実装広く使われているプラットフォームなどに対しては、複数の団体や企業が独自に JRE や JDK の実装を開発・提供している。 独自の最適化技術を適用したり、特定の用途に特化した最適化、あるいは異なるライセンスを採用するなど、それぞれ特徴がある。
オープンソース/フリーソフトウェアの実装いくつかの団体が、オープンソースもしくはフリーソフトウェアのライセンスで利用できる、Java仮想マシンおよび JRE 、JDK の実装を開発している。 Java仮想マシンおよび標準ライブラリの仕様はサン/JCPが公開している。 サン/JCPのJava標準クラスライブラリのソースコードは JDK の一部として提供されているため、開発者はJava標準クラスライブラリのソースコードを参照することができる。 しかしサン/JCPのJava標準クラスライブラリのソースコードを改変することは、サンのライセンスにより認められていなかった (ただし2006年にサンはライセンスの方針を変更し近い将来オープンソースにする意向を表明している) 。 そのため一部の人々は、オープンソースもしくはフリーのライセンスで利用できる、サン/JCPとは別の、ただし互換性のあるJava標準クラスライブラリとJava仮想マシンを実装する作業を行っており、近い将来に完全な実装が完成し公開されるとみられる。 オープンソースもしくはフリーの実装を開発しているいくつかのプロジェクトを示す。
GNU Classpath は、2007年3月現在、J2SE 1.4 のライブラリの 99% 以上を実装し、J2SE 5.0 では 95% 以上を実装している。 また Apache Harmony には IBM が協力している。 GCJGNUがGNUコンパイラコレクション (GCC) のJava版、GCJ (The GNU Compiler for the Java Programming Language) を出している。 ahead-of-time コンパイラを搭載しており、Javaのソースコードやバイトコードをネイティブマシンコード(Windowsの場合はexeファイル)に変換できる。 クラスライブラリは GNU Classpath を使っており、1.4のほとんどの部分が対応しており、5.0の部分も実装が進んでいる。 Windows環境では、GCJはMinGW (Minimalist GNU for Windows) もしくはCygwinを使って実行できる。 Cygwinの場合は、対象がライセンスがGPLのソフトウェアに限られるが、MinGWの場合は商用含め、全てのソフトウェアで利用できる。 GCC/GCJ for MinGWにて、MinGW版のGCJをまとめたパッケージが公開されている。 Excelsior JET米Excelsior社が Excelsior JET というahead-of-timeコンパイラを販売している。Java SE 5.0 用に書かれたプログラムをWindowsのネイティブマシンコードであるexeファイル (実行ファイル) に変換できる。 Windows exeパッケージ化Windowsにて、配布、実行しやすくするために、Javaのjarファイルをexeファイル (実行ファイル) でラッピングするツールがある。以下が、その一例である。
Javaのエディションサン・マイクロシステムズとJCP は、さまざまな環境に対応するため、3つのJavaプラットフォームのエディションを規定している。 Java の API の多くは分類され各エディションに割り当てられている。 エディションごとに実行環境と開発環境がある。 Java実行環境 (JRE) は、Java仮想マシンと標準ライブラリの実装から構成される。 JDK 1.1 のバージョンまでは、Java SE に相当するエディションのみが提供されていた。 3つのエディションが規定されたのは、JDK 1.1 の次のバージョンからである。 サン/JCP が規定しているエディションを次に示す。
Java API に含まれるクラスは、パッケージと呼ばれるグループに分類される (#名前空間) 。 各パッケージは、相互に関連するインタフェース、クラス、例外を含む。 Javaの各エディションでどのような機能が使えるかについては、それぞれのエディションの項目 (Java SE、Java EE、Java ME) を参照のこと。 JavaのAPIセットは、サン・マイクロシステムズと他の個人や企業・団体が共同で、JCP (Java Community Process) プログラムに沿って管理している。 このプロセスに参加する人々が、Java API の設計と開発に関わっている。 このプロセスのあり方については、議論の対象となっている。 2004年より、IBM と BEA は、Java の公式のオープンソース実装を作る動きを、公的に支援している。 2006年まで、サンはこうした動きに対しては拒否する立場をとってきたが、方針を変えて自社とJCPによるJavaの実装をオープンソースにする意向を表明し実行に移し始めている。 拡張機能と関連技術Javaの標準機能に対する拡張機能は、多くの場合、
Java技術の標準化現在、Javaプラットフォームの将来のバージョンや機能は、JCP (Java Community Process) の標準化プロセスのもとで開発されている。 JCP のメンバになることで、Java技術の将来のバージョンや機能の定義に関与することができる。 JCP には、さまざまな個人、団体、企業がメンバとして参加している (IBM、ボーランド、BEA Systems、富士通、Apacheソフトウェア財団、ヒューレット・パッカード など) 。 JCP は、Javaプラットフォームに追加する仕様や技術を、JSRs (Java Specification Requests) という文書群に記述する。 プログラミング言語JavaとJavaコアAPIに関わるいくつかの JSRs を示す。
開発ツールJavaアプリケーションを開発するための開発ツール (開発用ソフトウェア) をいくつか示す。 次に示すツール以外にも、数多くのツールが開発・提供されている。
統合開発環境Javaプログラムを開発できるいくつかの統合開発環境 (IDE) を示す。
批判Javaに対しては、優れた技術だと評価する人々がいる一方で、批判も少なくない。 Javaは、ソフトウェアに関する複雑さを管理する問題に対して、革新的な方法を提供するという目標のもとで、開発された。 多くの人々は、Java技術は、この期待に対して満足できる答えを提供したと評価している。 しかしJavaにも欠点が無いわけではない。 Javaは、どのようなプログラミング作法にも適応しているわけではない。 また、どのような環境や要件にも普遍的に適応しているわけではない。 Javaに対する批判を大まかに記述する。 実行性能Javaの初期のバージョンでは、CやC++などのネイティブにコンパイルする言語と比べて、とても実行が遅くメモリの消費が激しいとして、批判されることが多かったが、近年のバージョンでは改善されてきている。 近年のJava仮想マシンで採用しているジャストインタイムコンパイラや動的再コンパイルの実行性能は、従来の言語のネイティブコンパイラとほぼ同じ水準の実行性能を達成することがある。またJavaの自動ガーベジコレクションの技術も向上している。こうした事情から、Javaの実行性能については、議論の対象となっている。 ルックアンドフィールルックアンドフィールに関して、JavaのSwingのツールキットを使ったグラフィカルユーザインターフェース (GUI) を備えたアプリケーションの既定のルックアンドフィールが、従来のネイティブなアプリケーションとは大きく異なるため、エンドユーザの人々にとってJavaのGUIアプリケーションはなじみにくいと批判されることがある。Javaではプラグイン可能なルックアンドフィールの機構を備えており、サンはWindows、Mac OS XおよびMotifの各ルックアンドフィールのクローンを提供している。そのため、Swingの既定のルックアンドフィールではなく、プラットフォームネイティブと同様のルックアンドフィールでJavaのアプリケーションを動かすよう指定することができる。しかしエンドユーザにとってこの指定方法は簡単ではないと指摘されることがある。 言語仕様の設計言語仕様の設計に対する批判をいくつかの側面から述べる。
クラスパス一般に、Javaプログラムを実行する際、-classpath オプションを使用するか、環境変数クラスパス (CLASSPATH) を必要に応じて適切に設定する必要がある。環境変数クラスパスを指定すると、既定のカレントディレクトリという設定が上書きされる。したがって、環境変数クラスパスを変更するソフトをインストールするなど設定を変えられた場合は、Java実行環境は正しくJavaプログラムを実行することができなくなることがある。このためJavaを使い始めた人々は、クラスパスについて戸惑うことがある。サンは -classpath オプションを指定する方法を推奨している。 移植性・互換性Javaは高い移植性と互換性を実現するべく開発されており、ある程度の水準まで達成しているが、課題が残っている。Javaのバージョン間の下位互換性・上位互換性が完全ではないことが問題として議論の対象になっている。Javaでは高い移植性を保っているため、一部のプラットフォームにしかない独自の機能はJavaからは使えない。 |
