Java
Java（ジャバ）は、汎用性に富んだ高水準のプログラミング言語である。言語仕様は"C言語"をベースにして、"C++"と"Smalltalk"の双方をモデルにしたオブジェクト指向のパラダイムを導入している。従来のソフトウェアが抱えていた移植性問題の解決を目標とし、ハードウェア環境に依存せず、あらゆるプラットフォーム上で動かせるプログラムの実現を目指して開発された。”"write once, run anywhere”（"一度書けばどこでも動く）がそのキャッチコピーだった。
Javaプログラムは特殊なバイトコードにコンパイルされて、これがJava仮想マシンと呼ばれるソフトウェア上で実行される。各プラットフォームに対応したJava仮想マシンがハードウェア間の差異を吸収し、環境に依存しないプログラム動作を実現する仕組みとなっている。初期の対象である家電機器の組み込みシステムからパソコン、モバイル端末、サーバーマシンまであらゆる環境にJavaソフトウェアは普及したが、同時に期待された程のプラットフォーム非依存性が得られていない事も明らかとなった。2016年には世界で最も人気のあるプログラミング言語の一つとして認められ、世界中でおよそ900万人がJava開発環境を用いていると言われる。
Java言語は、1995年にサン・マイクロシステムズ社のソフトウェア技術者ジェームズ・ゴスリンによって開発された。2010年にサン社はオラクル社に吸収合併され、Java言語の著作権もそちらに移行した。おおよそ数年おきに言語仕様の改訂が重ねられており、2019年1月現在の最新バージョンは、2018年9月25日に公開された第11版となっている。
Javaは当初、それ以前の多様な言語の際立った特徴を引き継ぎ、プログラマの使い勝手と動作速度のバランスを考えて設計された。主には下記のような特徴を持つ。
Javaは組み込みシステムや携帯機器（携帯電話・PHSやPDA・スマートフォン等）のシステムから、企業の情報システムを担う大規模なデータベース、サーバ、スーパーコンピュータまで、多くの分野で使用されている。1995年のリリース時は他に似たような言語が無く、鳴り物入りで登場した。仮想マシンに基盤を置いたため、歴史の初期には動作速度や信頼性などの面で懐疑的な評価が行われることが多かったが、長年の実績の積み上げにより使い勝手の良さが広く認知され、基幹系や業務系のシステム開発では特に重宝されるようになっている。
プログラミング言語JavaおよびJavaプラットフォームは、1990年代前半当時、サン・マイクロシステムズに居たジェームズ・ゴスリン、ビル・ジョイなどの人々によって設計・開発された。2018年現在はサンを買収したOracleによる管理の他、追加提案などはサン時代から続いているJava Community Process (JCP) というプロセスによって進められる。
Javaに関わる呼称とその意味内容は、文脈に応じていくつか使い分けられている。サン・マイクロシステムズは、「Javaテクノロジ」（Java技術、Java technology）という呼称を使い、一方でJavaのさまざまな技術の形容詞として「Java」の呼称を使ってきた。多くのプログラマは、プログラミング言語の意味で「Java」の呼称を使っている。Javaの実行環境は、Java実行環境(Java Runtime Environment;JRE)と呼ばれる。Java の基本的な開発環境は、Java開発キット(Java Development Kit;JDK)と呼ばれる。
Javaはクラスベースのオブジェクト指向プログラミング言語である（#オブジェクト指向プログラミング）。Java のプログラムは複数のクラスから構成され、プログラムの実行は、各クラスが実体化したオブジェクト群が相互にメッセージをやりとりしながら行われる。Javaでは、継承については実装の単一継承を採用している。ただし1つのクラス（オブジェクト）は複数のインタフェースを実装できる。Java で扱うデータ/オブジェクトの型（データ型）は、強い静的型付けを採用している。Javaのコンパイラおよび実行環境が、型同士の整合性を検査することによって、プログラムが正しく記述されていることや、安全に動作するか検証が可能である。
Javaは例外処理機構を備えており、プログラム実行中に生じた異常（例外）の扱いを、比較的安全な方法で行い、プログラムを読みやすく記述できる。
Javaでは簡潔なメモリモデルを採用しており、プログラマがメモリ(主記憶装置)を管理する負担を軽減する。あらゆるオブジェクトはメモリ内のヒープという領域に割り当てられる。メモリ管理は、Java仮想マシンに統合されたガベージコレクションの機能によって行われる。従来のオブジェクト指向プログラミング言語であるC++では、ヒープ領域に生成したオブジェクトについて、もはや必要が無くなった時に破棄する指示を、プログラマが自分で責任をもって行わなければならなかった。これは、C++プログラマにとっては負担が大きく複雑で間違えやすい作業であり、ソフトウェアの安全性・開発効率・保守性を損なう要因だった。Javaではガベージコレクションの機能があるため、このようなことは無く、プログラマの負担は大きく軽減される。
Javaでは、C/C++のような、整数とポインタの相互変換、配列の要素へのポインタによるアクセス、ポインタ演算といった機能は、基本機能としては提供されていない。ただし、オブジェクトへの参照は内部的にはアドレスである。
Javaではプラットフォーム非依存を目標の一つとし、またバージョン間の互換性に注意して開発が進められている。プラットフォームに依存しない（Javaプラットフォーム自体を除く）アプリケーションソフトウェアの開発と配備を行うことができると主張される。従来のプログラミング言語の多くはプラットフォーム(CPU)に依存したネイティブなコードにコンパイルすることを前提として設計されていたが、Javaはこうした言語と異なり、中間言語（バイトコード）にコンパイルされ、Java仮想マシンで実行されるよう設計された（pコードマシンなど、過去にもあったものだが、）。性能向上のため、Java仮想マシンの成熟した実装では多くの場合、ジャストインタイムコンパイル方式が使われる。
プラットフォーム非依存とバージョン間の互換性の目標は、完全に達成できたわけではなく課題が残っている。
Javaではスレッドを言語仕様で規定しており、マルチスレッドによる並行計算を、従来の言語と比べて簡単に実装できる。なお並行計算は、複数の処理を同時に実行する処理形態である。またスレッドは、プロセスより小さく軽量な処理の単位である。
Javaでは充実したライブラリにより、コンピュータネットワークを活用するソフトウェアを、効率良く開発できる。Javaはその初期のバージョンから、TCP/IP のライブラリを備えていた。分散オブジェクト環境 (Java RMI, CORBA) のソフトウェアの開発も早い時期からできるようになっていた。では、さまざまなネットワークプロトコルの高水準なライブラリが使えるようになっている。W3Cにより標準化された、汎用マークアップ言語のひとつであるXMLで記述された文書を扱うライブラリも早期に実装・標準サポートされた。では、XMLプロセサとXSLTプロセサがJava標準ライブラリに統合され提供されている。充実したネットワーク機能とXML文書を扱う機能を有効に組み合わせることにより、Javaは標準機能だけでも高度なシステムを構築できる言語の一つとなっている。
Javaはセキュリティを考慮して設計されており、サンドボックスモデルに基づいたセキュリティ機構を備えている。セキュリティ機構を正しく実装したJava実行環境を適切に使うことで、遠隔のコンピュータ上にある実行コードを安全に実行できる（Javaアプレット）。
また、名前空間の機構をもつ言語であり、ライブラリおよびアプリケーションに含まれる多数の Java のプログラム（クラスとインタフェース）は、パッケージという階層構造で管理できる。
Javaに対する批判も少なくない。いくつかの批判に対しては、サン（後にはオラクル）やJCPに参加する人々の努力により、Javaの改良が行われている。一方で、。
JavaScript(ECMAScript)は、Javaにちなんで命名されたスクリプト言語である。とはいえ基本構文の一部がC言語系すなわちJavaに似ているだけであり、またクラスベースではなくプロトタイプベースのオブジェクト指向言語であるため、言語仕様的な共通点は少ない。
表記は"J"のみが大文字の「Java」が正しい。「JAVA」は正式な表記ではない。
この節では次の構成でJavaの歴史と近況を説明する。
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という名称は、一部のチームメンバーがよく出入りしていた近くのコーヒーショップで命名されたという。
この名称が、何かの頭字語であるかどうかについては、よく分かっていない。
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部門を立ち上げた。その2週間後に、最初の正式バージョンであるJava 1.0がリリースされた。
Javaの最初のバージョンが公開されてから2000年代までの動向を、いくつかの側面から述べる。なお、Javaの開発元であるサン・マイクロシステムズはこの後の2010年1月にオラクルにより買収されており、Javaに関する権利も同社に移転している。
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の他、バイトコード（あるいはネイティブコードの安全な実行）を指向したものとしてはNaCl (PNaCl)や、WebAssemblyがある。
現在、ウェブのサーバ側において、Java技術 (Java EE) は広く使われている。多くのウェブサイトが、Javaサーブレット (Java Servlet) やJavaServer Pages (JSP) などのJava EE技術を使って動的にページを生成するウェブを構築している。Javaサーブレットは2000年前後から急速に広く使われるようになり、現在では多くのウェブアプリケーション（動的なウェブページ）がサーブレットとして稼動するようになっている。
サン・マイクロシステムズが開発したJavaサーブレット技術を簡単に説明する。必ずしも厳密な説明ではない。サンがJavaサーブレット技術を開発した1990年代末当時、ウェブアプリケーションの開発には、次に述べるようないくつかの問題があった。
Javaサーブレットはこれらの問題をある程度解決することができる技術だった。
デスクトップ環境においては、スタンドアロンのJava (Java SE) のアプリケーションソフトウェア（Javaアプリケーション）は、これまではあまり多く使われていなかったが、近年はいくつかのソフトウェアが広く使われるようになっている。近年になって使われるようになってきた理由としては、次のことが挙げられる。広く使われているJavaのソフトウェアとしては、NetBeansおよびEclipse SDKの統合開発環境や、LimeWireやAzureusのようなファイル共有クライアントのソフトウェアなどがある。また数学ソフトウェアMATLABにおいても、ユーザインタフェースのレンダリングと計算機能の一部を実現するために使われている。多くの Java のSwingやSWTのウィジェット・ツールキットを使ったアプリケーションが、現在も開発されている。
このように、近年はデスクトップ上でJavaアプリケーションを使う事例が増えつつあるものの、従来は次に述べるいくつかの理由のためにあまり使われてこなかった。一部のソフトウェア開発者は、情報技術はウェブを基盤としたモデルが主流となっており、スタンドアロンアプリケーションは流行遅れであり、新しいプログラミング技術は優れたウェブアプリケーションを開発することに充てられている、と思っていた。この見解については、ソフトウェア技術者の間で賛否が分かれている。
現在では、リッチクライアントやWeb 2.0の登場により新たなパラダイムが生まれようとしている。すなわちウェブを基盤としたウェブアプリケーションとスタンドアロンアプリケーションの融合である。ウェブアプリケーションをAjaxや Java Web Start、Adobe Flash などと組み合わせることにより、Web2.0時代に見合ったより洗練されたアプリケーションを開発することができる。
一昔前、ほとんどの パーソナルコンピュータ (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の競合技術について簡単に述べる。世界的な動向としては、また、2001年にはソニーのコンシューマゲーム機 PlayStation 2 に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プラットフォームに対する変更の提案と規定を行う。
また、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での使用は推奨されないようになっている。
最初のバージョン。プレスリリース (英語)
いくつかの重要な機能が追加された。プレスリリース (英語)
コードネーム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) の基となるエディションであることが明確化された。プレスリリース (英語)
コードネームKestrel。プレスリリース (英語) 新機能の概要（日本語）
コードネームMerlin。このバージョンは、JCP (Java Community Process) の下で開発された最初のJavaプラットフォームである。プレスリリース（英語） 新機能の概要（日本語）
コードネームTiger。JSR 176 のもとで開発された。J2SE 5.0 では、言語仕様に大きく拡張が加えられ、多くの新しい言語機能が追加された。プレスリリース（英語） 新機能の概要（日本語）。もともとは J2SE 1.5 という名称だったが、この名称はすでに内部的なバージョン番号として使われていた。またマーケティング上の理由もあった。
この例では、codice_7という変数名のコレクションオブジェクト内の、各codice_8オブジェクトを反復して繰り返し処理する。各codice_8オブジェクトにはループサイクルごとにcodice_10という変数名をつける。各ループサイクルで、codice_10に対してcodice_8型で定義されているcodice_13メソッドを呼び出す。拡張forループはJSR 201で規定された。
コードネームMustang。JSR 270のもとで開発された。Java SE 6においては、サンは命名方針を変更して、"J2SE" からJava SEに変更し、バージョン番号から ".0" の部分を廃止している。
Java SE 6 Update 10が2008年10月22日にリリースされた。Update 8と9が省略され、7の次が10となった。Javaの動作速度が改善され、アプリケーションやアプレットの起動を高速化するJava Quick Starterが搭載され、Javaのインストールを高速化する、Java Kernelが搭載された。JavaアプレットやJava Web Startの起動を容易にするための、配備ツールキットが公開された。
コードネームはDolphinである。2006年に開発が始まった。元々は2008年春にリリースされる見通しであったが、何度かリリース予定が変更された。2007年8月の時点では2009年1月をリリース目標としていたが、2008年12月、ジェームズ・ゴスリンは、「私の勝手な憶測だが」という注意書き付きで、2010年6月以降のリリースを予測し、2009年11月には2010年9月以降のリリース予定に変更された。2010年9月に、これ以上の延期を避けるため、大きな言語仕様の改訂などの部分は Java SE 8 に先送りし、Java SE 7 を2011年中頃に、Java SE 8を2012年終わり頃に提供するという目標を立て、結局2011年7月28日にリリースした。Java SE 7は、オラクルによるサン買収後、初のメジャーリリースである。
Java SE 7に追加された項目は以下のとおりである。2014年3月4日に JSR 337 にて仕様が規定された。JDK 8 は2013年9月9日にリリース予定だったが、2013年4月18日にリリースの延期が発表になり2014年3月18日にリリースされた。CLDC, CDC を統合した Java ME 8 は2014年4月30日にリリースされた。主な新機能は以下。
当初搭載予定だった、以下の機能はJava SE 9に延期となった。
また、搭載予定だった以下の機能は廃止 (withdrawn) になった。
Java SE 9 は Java SE 8 リリースの3年後の2017年9月21日にリリースされた。。言語レベルでのモジュール化のサポート (Project Jigsaw, JSR 294) などを追加した。
オラクルはJavaの開発速度向上のため、これまでの新機能の完成を待ってメジャーバージョンアップを行うリリースモデルから、毎年3月と9月の年2回メジャーバージョンアップを行うタイムベースのリリースモデルへと移行することを発表した。またサポートサイクルも見直され、Java SE 9は次のメジャーバージョンまでの6ヵ月間のみ公式アップデートが提供されるnon-LTSリリースとなり、2018年3月に公式アップデートが終了した。なお、LTSリリースとなるJava SE 11以降は配布形態が変更されるため、LTSリリースの公式アップデートは提供されなかった。
JSR 383 にて仕様が規定されたJava SE 10は新リリースモデルによる初リリースで、予定通りJava SE 9から半年後の2018年3月20日にリリースされた。ローカル変数型推論などの機能が追加されている。
JSR 384 にて仕様が規定され、2018年9月25日にリリースされた。オラクルによるビルドはOracle JDKとOpenJDKの二種類が提供され、Oracle JDKの商用利用は有償サポート契約を結んだ顧客のみとなっている。なおリリースモデル変更後の初LTSリリースとなるが、オラクルによる長期サポートはOracle JDKを対象にしたものであり、オラクルによるOpenJDKの提供がJava SE 12リリース以降も行われるかは、2018年10月時点で未定である。
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プロジェクトのGNU Compiler for Java (GCJ)などがある。この場合、中間言語のバイトコードを生成するという段階は省かれる。しかしこの方法で生成されるJavaの実行コードは、コンパイル時に指定したプラットフォームでしか動かない。
Javaの実行コード（バイトコード）を生成する手段としては、プログラミング言語Javaでプログラムを書くことが標準的なやり方である。Javaのバイトコードの実行は、Java仮想マシンという仮想マシンの環境上で行われる。Java仮想マシンは実行時にバイトコードをネイティブコードに変換する。なお、Javaのバイトコードを生成する他の方法としては、現在ではRuby（JRuby）や Groovy 、Kotlin 、Jabaco 、Python（Jython）などのプログラミング言語でプログラムを書くこともできる。
サン・マイクロシステムズのJavaのライセンスは、すべてのJava実行環境の実装は「互換性」を備えるべきであることを要求していた。このことに関連して、サン・マイクロシステムズとマイクロソフトとの間で法的な争いが起こったことがあった。この法的な争いは、サンが、マイクロソフトのJava実行環境の実装について次のように主張したことによる。
サンは訴訟を起こして勝訴し、約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プログラムを作成することは、可能である。しかし実際には、Javaを利用できるプラットフォームによってはちょっとしたエラーが発生したり、微妙に異なる動作をする事例が多い。こうしたことから一部の人々は、サン・マイクロシステムズのJavaの売り文句であった "Write once, run anywhere"（一度コードを書けば、どの環境でも動く）をもじって "Write once, debug everywhere"（一度コードを書けば、どの環境でもデバッグが必要）と皮肉をいわれることがある。
しかし、Javaのプラットフォーム非依存は、サーバ側や組み込みシステムのアプリケーションに関しては、非常に成功している。サーバ側 (Java EE) では、Java のサーブレット、Webサービス、EJB (Enterprise JavaBeans) などの技術が広く使われている。組み込みシステムの分野においても、組み込みシステム向けの Java環境 (Java ME) を使ったOSGiを基にした開発が広く行われている。
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) の下で実行されるという点では、同じと考えることもできる。
構文は、CおよびC++から多くを引き継いでいる。このため、設計当時には割合として多かった、CやC++しか書けないプログラマにも習得しやすいと、。Javaが設計された1990年代中旬以前は、Cのプログラマが多く、またオブジェクト指向プログラミング言語の中では、C++は広く使われてきた言語の一つだった。
なお、JavaではC++と違って名前空間レベルの関数（メソッド）および変数（フィールド）の宣言および定義を許可しておらず、必ず何らかのクラス定義の中に記述することが特徴である。この特徴は後発のC#も踏襲している。
次の節以降では、Hello worldプログラムで、Javaプログラムの例を示して説明する。
Hello worldプログラムとは、"Hello, world" という文字列をディスプレイなどの出力装置に出力する簡単なソフトウェアプログラムである。プログラミング言語の初学者向けのプログラム例としてよく使われる。
なお先に述べた通り、Javaには複数の実行形態があると考えることができるので、以降では、それぞれの実行形態におけるHello worldプログラムを例示する。
コマンドライン環境で動くスタンドアロンのJavaアプリケーションの例を示す。Javaでは、他のプログラミング言語と同様に、コマンドライン環境で動くプログラムを簡単に開発できる。
このプログラムについて説明する。
グラフィカルユーザインタフェース (GUI) 環境で動く Swingを使ったスタンドアロンのJavaアプリケーションの例を示す。Swingは、Java SEの高度なGUIのウィジェット・ツールキットのライブラリである。
Javaアプレットは、他のアプリケーションに埋め込まれるプログラムである。多くの場合は、ウェブブラウザに表示されるウェブページに埋め込まれる。Javaサーブレットは、サーバ側のJava EEの構成要素であり、クライアントから受けた要求 (request) に対する応答 (response) を生成する。現在、多くの場合はウェブブラウザから要求を受け、応答としてXHTML / HTMLのウェブページを動的に生成する。
Javaプラットフォームの構成を説明する。
Java実行環境 (JRE; Java Runtime Environment) は、Javaプラットフォームに配置されたJavaアプリケーションを実行するために必要な、ソフトウェアである。標準クラスライブラリやJava仮想マシンなどから構成される。
エンドユーザは普通、Javaソフトウェアパッケージやウェブブラウザプラグインの利用を通じてJREを使う。オラクル / JCPをはじめ複数の団体や企業により、 さまざまなプラットフォーム向けに、多くの JRE の実装が開発・提供されている。
JREの他、オラクル / JCPなどの団体・企業は、Java開発キット (JDK) と呼ばれるJREのスーパーセットの実装を開発・提供している。JDKは、Javaプログラムの開発を支援する基本的なソフトウェアであり、多くの開発ツールが含まれている。
Java実行環境は、標準クラスライブラリとJava仮想マシン、およびいくつかのファイルとソフトウェアから構成される。
Java開発キット (JDK; Java Development Kit) は、オラクル / JCP をはじめ複数の団体や企業により開発・提供されている、Javaプログラムの開発を支援する基本的なソフトウェアである。Javaが世に出て以来、広く使われてきたJavaの開発ツールである。javac、javadoc、デバッガなどを含む多くの開発ツールが含まれている。また、完全なJava実行環境 (JRE) を同梱している。
Javaプログラムを実行するだけであれば、Java実行環境が導入されていれば充分で、Java開発キットを導入する必要は無い。
Java開発キット (JDK) の呼称は、これまでに何度か変更されている。
広く使われているプラットフォームなどに対しては、複数の団体や企業が独自にJREやJDKの実装を開発・提供している。独自の最適化技術を適用したり、特定の用途に特化した最適化、あるいは異なるライセンスを採用するなど、それぞれ特徴がある。
オラクルおよびいくつかの団体が、オープンソースもしくはフリーソフトウェアのライセンスで利用できる、Java仮想マシンおよびJRE 、JDKの実装を開発している。
サン / JCPはJava発表時からJava仮想マシンおよび標準ライブラリの仕様を公開しており、Java標準クラスライブラリのソースコードもJDKの一部として提供していた。しかしソースコードの改変は下記のOpenJDKリリースまでライセンスで認めていなかった。そのため、サンの実装とは別に、オープンソースもしくはフリーソフトウェアでかつサンの実装と互換性のあるJava標準クラスライブラリとJava仮想マシンが開発された。また、2006年にサンはライセンスの方針を変更し近い将来オープンソースにする意向を表明し、2007年5月8日にJava SE 6をOpenJDKとして GNU General Public License にてリリースした。
GNU Classpathは、2007年3月現在、J2SE 1.4のライブラリの99%以上を実装し、J2SE 5.0では95%以上を実装している。
またOpenJDKにはIBMが協力している。
GNUプロジェクトがGNU Interpreter for JavaおよびGNUコンパイラコレクション (GCC) のJava版であるGNU Compiler for Javaを出している。GNU Compiler for Javaはahead-of-timeコンパイラを搭載しており、Javaのソースコードやバイトコードをネイティブマシンコード（Windowsの場合はexeファイル）に変換できる。クラスライブラリはGNU Classpathを使っており、1.4のほとんどの部分が対応しており、5.0の部分も実装が進んでいる。
Windows環境では、GCJはMinGW (Minimalist GNU for Windows) もしくはCygwinを使って実行できる。Cygwinの場合は、対象がライセンスがGPLのソフトウェアに限られるが、MinGWの場合は商用含め、すべてのソフトウェアで利用できる。
米Excelsior社がExcelsior JETというahead-of-timeコンパイラを販売している。Java SE 用に書かれたプログラムを Windowsのネイティブマシンコードであるexeファイル（実行ファイル）に変換できる。起動の高速化やアプリケーションの難読化を実現する。
Windowsにて、配布、実行しやすくするために、Javaのjarファイルをexeファイル（実行ファイル）でラッピングするツールがある。以下が、その一例である。
Java Web Startには、適切なバージョンのJREをインストールする機能があるが、そもそも、JREがインストールされていない場合は、それが不可能である。JSmoothなどでは、ラッピングされたexeが、必要なJREがインストールされていないことを検出した時は、JREをダウンロードして、インストールする機能を持つ。また、上記3つすべてにおいて、JREを同梱して、同梱したJREを使ってアプリケーションを実行する機能を持つ。
また、通常のJavaアプリケーションでは、Windowsのタスクマネージャには、java.exeやjavaw.exeと表示され、Javaのアイコンが表示されるが、自前のexeファイル名と自前のアイコンを表示する機能を持つ。
さらに、上記のいくつかは、アプリケーションの2重起動を防止したり、アプリケーションをWindowsサービス（NTサービス）化する機能を持つ。
サンが特定のOSに特化した機能を提供することを嫌がっていたため、これらの機能が不足しており、それを補うために、exeパッケージ化が存在する。
オラクルと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の標準機能に対する拡張機能は、多くの場合、codice_113パッケージに属する。こうした拡張機能は、Java SEの Java開発キット (JDK) や Java実行環境 (JRE) には含まれない。Java の拡張機能や関連技術は、プログラミング言語Javaと密接に連携する。主なJavaの拡張機能と関連技術を示す（いくつかの拡張機能は近年のJava SE標準ライブラリに統合された）。
現在、Javaプラットフォームの将来のバージョンや機能は、JCP (Java Community Process) の標準化プロセスのもとで開発されている。JCPのメンバになることで、Java技術の将来のバージョンや機能の定義に関与することができる。JCPには、IBM、ボーランド、富士通、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のガベージコレクションの技術が、Cのmallocやfreeよりも高い性能を発揮できることによる。こうした事情から、Javaの実行性能については、議論の対象となっている。
ルックアンドフィールに関して、JavaのSwingのツールキットを使ったグラフィカルユーザインタフェース (GUI) を備えたアプリケーションの既定のルックアンドフィールが、従来のネイティブなアプリケーションとは大きく異なるため、エンドユーザの人々にとってJavaのGUIアプリケーションはなじみにくいと批判されることがある。Javaではプラグイン可能なルックアンドフィールの機構を備えており、サンは Windows、macOSおよびMotifの各ルックアンドフィールのクローンを提供した。そのため、Swingの既定のルックアンドフィールではなく、プラットフォームネイティブと同様のルックアンドフィールでJavaのアプリケーションを動かすよう指定することができる。しかしエンドユーザにとってこの指定方法は簡単ではないと指摘されることがある。
言語の設計（デザイン）に対する批判をいくつかの側面から述べる。
Javaの設計者は、他のプログラミング言語では備えているいくつかの機能をJavaから排除した。利便性より言語設計の簡潔さを優先した結果だが、こうした設計上の判断については賛否が分かれている。
また、Javaは、Smalltalkのように「純粋な」オブジェクト指向プログラミング言語ではないとして、設計の一貫性のなさを批判されることがある。たとえばJavaには、プリミティブ型という、クラス型（参照型）ではないものがある。Javaの設計者は、実行性能上の理由から、意図的にプリミティブ型をJavaに導入した。例えば、codice_3型などの組み込み型がプリミティブ型に相当する。codice_3型の値はオブジェクトではなく、これをクラス型のオブジェクトとして扱うには、ラッパーであるcodice_116クラス型への変換（ボクシング）が必要になる。J2SE 5.0以降ではオートボクシングにより、プリミティブ型と、それに対応するボックスクラス型の間のやりとり（変数への代入や値の参照など）は、コンパイラによって自動的に行われるようになり、ソースコード上の煩雑さは軽減されたが、本質的に同じものを指すはずのデータ型が複数存在するという矛盾を依然として抱えたままである。
一方で、C++のように名前空間レベルのメソッドやフィールドを定義できず、必ずクラス定義が必要であることから、クラスを定義する側も利用する側も記述量が肥大化しがちである。J2SE 5.0 では、メソッドとフィールドのstaticインポートを行えるようになり、クラス修飾なしでstaticメンバーを利用できるようになった。しかしstaticインポートを不用意に使うとソースコードを判読困難にする可能性がある。サン / JCPはstaticインポートを適切に使用するガイドラインを合わせて公開した。
なお、C#はDelphiの設計思想を取り入れた言語であり、登場当初からプロパティをサポートしている。演算子オーバーロードについても、C++より限定的ではあるがサポートされる。そのほか、Javaで問題視されていたプリミティブ型の扱いやジェネリクスなどに対して、C#は独自の解決策を提示している。
一般に、Javaプログラムを実行する際、-classpathオプションを使用するか、環境変数のクラスパス (CLASSPATH) を必要に応じて適切に設定する必要がある。クラスパスを指定すると、既定のカレントディレクトリという設定が上書きされる。したがって、クラスパスを変更するソフトをインストールするなど設定を変えられた場合は、Java実行環境は正しくJavaプログラムを実行することができなくなることがある。このため Javaを使い始めた人々は、クラスパスについて戸惑うことがある。サンは-classpathオプションを指定する方法を推奨していた。
Javaは高い移植性と互換性を実現するべく開発されており、ある程度の水準まで達成しているが、課題が残っている。Javaのバージョン間の下位互換性・上位互換性が完全ではないことが問題として議論の対象になっている。Javaでは高い移植性を保っているため、一部のプラットフォームにしかない独自の機能はJavaからは使えない。
サン・マイクロシステムズは複数のJava認定資格を主催していた。オラクルによる買収後、一部資格は変更されている。ただし、買収前に以下の資格を取得した者は買収後も有効資格である。
現行はオラクルが以下のJava認定資格を主催している。これらのうちOracle認定Java EE 6 Enterprise JavaBeansディベロッパ以外の試験はサン・マイクロシステムズが主催していた試験の、それぞれ略号の "OCJ" を "SJC" に変更したものに対応する位置付けにある。
認定試験に不合格だった場合、その試験日を含めて14日以内は同一試験を受験することができない。