JDKのインストール(Windows)と Java 関連用語の説明

今回は Java の開発キットである JDK(Java Development Kit) の Windows へのインストール方法についての紹介です。
ただ Java は JDK, JRE, Java SE など略称がいっぱいです。これらのJava に関連する用語についても説明しています。

JDK は Java による開発はもちろん JVM 言語 の開発にも必要です。 私の場合はむしろ JVM 言語用としてインストールしました。
Java は用語がいっぱいあり、何をインストールするのか、何がインストールされたのか、 よくわからないといったことがありました。 そこで、それらの用語について私なりにまとめたものをインストール方法と一緒に紹介したいと思います。

Java アプリケーションの実行の仕組み

Java アプリの実行の仕組みから先に説明します。

まず、 比較として通常(Native)のアプリケーションでの実行の説明から行きましょう。
Native では gcc, VC++ といったコンパイラーで人間が書いたソースファイルを機械が読みやすいマシン語(機械語) に変換した実行ファイルを作成します。 このファイルは 0, 1 で書かれたバイナリーで、これを OS が読み取って実行します。


一方、 Java ではソースファイルをコンパイルするとバイトコードと呼ばれるファイルが作成されます。これはソースコードと機械語との中間言語のファイルです。
これを Java の仮想マシン JVM(Java Virtual Machne) が読み取り、実行します。


この JVM の環境を提供するのが、 JRE(Java Runtime Environment) というソフトウェアのセットです。
この中の java.exe にバイトコードを渡して、実行します。
このため、Java 製アプリを実行するには JRE が必要です。 通常 Java のインストールというとこちらを指します。

Java アプリ作成に必要なソフトウェアのセットが JDK (Java Development Kit)で、 Java の SDK といったところです。
JDK の中の Java コンパイラー(javac.exe) を使って、 ソースファイル(*.java) からバイトコード(*.class)を作成します。 Java の配布パッケージとしてよくある jar ファイルは class ファイルを単に zip で固めたファイルです。

なお、 JDK をインストールすると JRE も一緒にインストールされます。
ただし、こちらはプライベート JREといって、 JDK 用のフォルダー内にインストールされます。 このため、通常使っている JRE に影響を与えることなく、別バージョンの JRE 用のアプリを開発する ということもできるらしいです。


なんでこんな仮想マシンという仕組みをとっているかというと、もちろんメリットがあってやっています。 ただ、その説明はインストールの解説の後に行うことにします。

JDK のダウンロード

Java プラットホーム

Java の開発環境をインストールしていくわけですが、 ここでまた、Java にはいくつかの開発環境(Java プラットホーム)があります。

• Oracle Technology Network for Java Developers

Java プラットホームをまとめると次のような感じです。 JDK はこのうちの標準版である Java SE の開発キットです。

略称	名称	説明
Java SE	Java Platform, Standard Edition	標準版。主なターゲットはデスクトップ(PC)。
Java EE	Java Platform, Enterprise Edition	企業向け。主なターゲットはサーバーサイド。
Java ME	Java Platform, Micro Edition	組み込みシステム、モバイル用。

JDK の選択

いよいよ JDK のダウンロードです。
以下の Java SE のダウンロードページから行います。

• Java SE Downloads

3 種類のダウンロードリンクがありますが、 "JDK" または "NetBeans 付きの JDK" を選択します。
NetBeans は Visual Studio に当たる IDE です。 IDE も一緒に入れたければ、 JDK + NetBeans を選択して下さい。
Java の IDE では NetBeans 以外にも Eclipse や IntelliJ IDEA あたりが有名どころです。 というよりもシェアとしては Eclipse が圧倒的人気で、 2 番目が IntelliJ です。

追記 2013-10-02

画像では 3 種類になっていますが、 次節で説明する JavaFX が JDK と一緒にインストールされることになったので、 現在は 2 種類です。

JavaFX

もう一個残った JavaFX についても説明しておきます。
分かれていますが、今のバージョン(7u21)では JDK と一緒に JavaFX もインストールされるみたいです。

JavaFX というのは Rich Internet Application (RIA) の GUI ツールキット(API)です。
といっても、"それ何?" という人も多いと思います。 RIA は Adobe Flash や Microsoft の SilverLight といった類のものです。 ブラウザーにプラグインとしてインストールし、 よりリッチなコンテンツや Web アプリを提供するための技術です。

Web のクライアント側スクリプトとしては JavaScript で統一されてしまった感がありますが、 Java もデビュー時は クライアントサイドの言語でした。その Java で作ったものが Java アプレット です。
JavaFX は次世代の Java アプレットに当たります。

ちなみに JavaFX は 1.0 として出た頃はスクリプト言語でした。 しかし、 Sun が Oracle に買収されたあたりで方針転換し、 2.0 から今の API の形態になっています。


また、方針変換に伴い JavaFX はブラウザー上だけでなく、デスクトップアプリの GUI ツールキットとしても使えるようになりました。 Java では AWT, Swing, SWT といった GUI ツールキットがありますが、 その最新版とも言えます。
Windows(.NET) では WPF と SilverLight に分かれていますが、それが合わさった感じです。

JDK インストーラー

前節 で "JDK のみ" を選択したとして進めたいと思います。 "NetBeans 付き" でもほとんどやり方は同じです。

JDK のみを選択するとプラットホーム(OS)別のインストーラーのダウンロードページとなります。


ここで、ライセンス条項に同意して、 インストーラーをダウンロードします。
32 ビット PC であれば jdk-XXX-windows-i586.exe、 64 ビット PC なら jdk-XXX-windows-x86.exe です。

このページでは、その他にもデモやサンプルのファイルがおいてあります。 お好みでダウンロードして下さい。

JDK のインストール

インストールはダウンロードしたインストーラーを実行します。


ここで、インストール先を変更していた方がお勧めです。
デフォルトでは "C:\Program Files" 以下なのですが、 たまにパスにスペースを含む場合に正常に動作しないプログラムがあるためです。 また、 "C:\Program" というフォルダーを作るのは問題があり、後で変えるように言われるので、 そちらもやめておきましょう。

その後はウィザード従えば、インストールされます。
オプションで [公開用の JRE] を外していなければ、 そのまま JRE のインストールが続けられます。 こちらは開発時に使う プライベート JRE ではなく、普段使う JRE です。 こちらのパスは変えなくても大丈夫だと思いますが、気になる人は変えておきましょう。


この状態で、 javac (コンパイラー)などをフルパスで指定すれば、実行できるのですが、 環境変数 PATH に実行ファイルのある bin フォルダーを追加していた方が使いやすくなります。
また、ツールや JVM 言語の中には次で説明する JAVA_HOME を設定しておく必要があるものも多いです。
環境変数の設定画面の呼び出しは Windows のバージョンによって違うのですが、 基本的に [(マイ)コンピューター] を右クリックして [プロパティ] を選択し、 [詳細設定] を選ぶと出てくると思います。

単に bin フォルダーを PATH に追加するのではなく、 JAVA_HOME の変数を介して追加します。

環境変数	値
JAVA_HOME	インストール先のフォルダー(C:\Programs\Java\jdk1.7.0_21 など)
PATH (追加)	%JAVA_HOME%\bin

%..% というのは他の環境変数を展開して入れる記号です。(Unix の ${..} に当たる記述)
新しいバージョンをインストールした場合、 環境変数を設定し直す必要があります。 前の PATH の記述を消すのは面倒ですが、 このように設定しておけば、 JAVA_HOME の値を変更するだけでよくなります。


以上でインストールの説明は終わりです。
これ以降は、 JVM の仕組みについて気になった人のために、もう少し JVM のメリット、デメリットについて説明をしておきます。

仮想マシン(JVM) のメリット、デメリット

コンパイル型と比べたメリット

メリットとしては次のようなものが考えられます。

• クロスプラットフォーム
• 構文解析と最適化処理の分離
• クロスランゲージ

クロスプラットホーム :
もともと Write once, run anywhere(一回書けば、どこでも動く) がスローガンでしたし、 これは売りなのでしょう。
ただ、 C++ でも Qt といったクロスプラットホームのフレームワークを使えば、 同じようなことはできます。
もちろん、 Qt ではプラットホーム別の処理を書く必要が全くないということは ありません。しかし、それは Java も同様です。

また、バイトコード等の仕様は公開されているので、 JVM を独自につくることができます。
新しく OS などの環境をつくったとして、そこで JVM さえ作れば、 すでにたくさんある Java のアプリがそのまま動くようになります。
実際には、そのまま動くほど、おいしい話ではありませんが、 速度向上の目的のものを含めると多くの JVM が開発されています。

• 開発者が知っておくべき Java と仮想マシンの歴史 - ＠ IT

構文解析と最適化処理の分離 :
コンパイラーの仕事のうち、大きなポイントが 2 つあります。
一つが言語の仕様に基づき、ソースを解釈する処理です。 この言語の仕様を決めるところが言語作成者の腕の見せ所であり、 センスを問われる部分でしょう。
もう一つはプログラムをいかに速く動かすかという最適化の部分です。 こういうところに情熱を燃やす人もいます。
この特性の違う二つをコンパイラーと JVM で分けて開発できるようになります。


クロスランゲージ :
前述の分離により、 中間言語へと変換するコンパイラーさえ作れば、 新しい言語でも最適化の恩恵を受けることができます。
また、一旦中間言語に直すので、違う言語間でのやり取りが簡単にできるようになります。

本来、 JVM は Java 用ですが、これらのメリットにより、 Scala 、 Groovy を始めとした 200 を超える新しい言語が生まれています。 これらの JVM 上で動作する言語を JVM 言語 と言います。
この多くの JVM 言語を生み出す環境を用意したことが、 Java の一番の功績ではないかと個人的には思います。

コンパイル型(Native)と比べたデメリット

逆にデメリットもあります。

• 重い、メモリー消費量が多い
• リバース エンジニアリングされやすい
• システムへの JRE のインストールが必要

重い、メモリー消費量が多い :
C, C++ といった言語では事前にコンパイルします。 それに対して Java では、 実行時にコンパイルします。 これは JIT コンパイル(Just In Time) と呼ばれています。
実行の際にコンパイルするので、その時間がかかりますし、 コンパイル結果のマシンコードをメモリー上に確保するので、メモリーを大量に消費します。
このため、初期の Java は「使い物にならない」といわれるほど、 遅いものでした。 実を言うと、私は Java が嫌いなのですが、 この第一印象の悪さが一因となっています。

しかし、 よく使うところだけコンパイルするなどの技術が盛り込まれ、大分改善されています。
最近では条件によっては事前コンパイルよりも高速になることもあるそうです。 ただ、そうはいっても基本的には遅いし、メモリーも使います。


リバース エンジニアリングされやすい :
これは商用アプリに限った問題です。
実行ファイルから元のソースコードの情報を得ることをリバース エンジニアリングと呼びます。 これは Java に限った技術ではありませんが、中間言語の形式でリリースする Java では特にやりやすくなってしまいます。

これを防ぐための難読化という技術もあります。
JavaScript の難読化 は速度を上げるために空白等を取り除いて、結果読みにくくなるものですが、 Java の難読化はわざとソースコードを読みにくくします。 しかし、これには新たな不具合が生じたり、速度が低下したりといった危険性があります。
最近のアプリでは減ってきていますが、アルゴリズムで勝負しているような部分は、 C, C++ といった Native な言語で実装する必要があります。


システムへの JRE のインストールが必要 :
インタープリター型と比べたコンパイル型のメリットとして、 "コンパイルした実行ファイルだけで動作する"というものがあります。
しかし、 Java のアプリは JVM(JRE)が必要で、そのメリットがありません。

インタープリター型(スクリプト)との違い

仮想マシンを使う仕組みはインタープリター型の言語とよく似ています。
しかし、人が書いたコードを事前にマシンが読みやすい中間言語にコンパイルしているため、 その分、速度の向上が望めます。

コンパイル型との比較で挙げた JIT コンパイルなどの技術などもあり、 Java のアプリは大抵のスクリプト言語よりも 5 倍程度、速いらしいです。

ただ、 Ruby は Ver. 1.9 から RubyVM を内蔵していますし、 Python の PyPy や JavaScript の V8 エンジンなどは JIT コンパイルの技術が使わており、 速度の点に関しては、スクリプト系も向上していっています。

追記 - 2013-05-13

DartVM にいたっては JVM の速度を超えたらしいです。

• 最新のDart VM がJVMにDeltaBlue ベンチマークで勝つ(英語版)

また、コンパイルが不要ということは、 手軽というインタープリター型のメリットとも言えます。

まとめ

最後に仮想マシンのシステムについてまとめてみます。

速度に関しては、条件にもよりますが、概ね次のような関係となっています。

インタープリター型  <  仮想マシン  <  コンパイル型

また、 コンパイル型の"実行ファイルだけで動作する点"やインタープリター型の"コンパイルが不要な点" と両方の利点をともに失っています。

こうまとめるとあまり良い点はないように見えます。
しかし、 Micorsoft も Java と同じような .NET CLR のシステムを採用しました。 それだけ、 構文解析と最適化の分離やクロスランゲージといったメリットが大きいということでしょう。

ただ、これは開発サイドのメリットで、純粋にユーザーの視点からはコンパイル型が一番です。 しかし、速い技術進歩を求められるソフトウェア開発では必要な技術だと思います。
例えば、プログラミング言語が成熟するまで 10 年以上必要だと言われてきましたが、 Java や .NET を使えば、できてすぐ、高機能の最適化や豊富なライブラリーが使えるようになります。 また、既存のアプリに部分的に適用していくといったことも可能です。