Java Platform, Standard Edition または Java SE（バージョン5.0までは Java 2 Platform, Standard Edition または J2SEと呼ばれていた）は多くのJavaプラットフォームプログラムで役立つJava APIの集合体である。Java仮想マシン、APIなどから構成される。J2SE1.4バージョン (Merlin) 以降、Java SEプラットフォームはJava Community Process (JCP) の下で開発されている。JSR 59 はJ2SE1.4の包括仕様であり、JSR 176はJ2SE 5.0 (Tiger) を、JSR 270はJava SE 6 (Mustang) を規定している。Java SE 7 (Dolphin) はJSR 336の下でリリースされた。Java SEでは標準的な機能のみが定められており、サーバ向けの機能についてはJava SEを拡張した企業向けのJava Platform, Enterprise Edition (Java EE) にて定義されている。下記は主要なJava SEパッケージの説明である。全てのパッケージリストはを参照。Javaの基本的なパッケージ。パッケージ codice_1 は、言語とランタイム（実行）システムに緊密な基本的なクラスとインタフェースを含む。これはクラス階層を形成する基底クラス、言語仕様に密接な型、基本的な例外、数学関数、スレッド、セキュリティ関数、下位にあるネイティブシステムに関する情報も含む。codice_1の主なクラス:codice_1のクラスはソースファイルでimport宣言をせずとも自動的にインポートされる。codice_12パッケージは、他の可能な許可するアプリケーションとJava仮想マシン (JVM) ガベージコレクタとの間の限定的な相互関係よりもフレキシブルな参照型を提供する。それは重要なパッケージであり、それに"java.lang"で始まる名前を与えた言語設計者のための言語として十分に中核をなしたが、それはいくぶん特殊目的であり多くの開発者は使わない。このパッケージはJ2SE1.2から追加された。Javaは多くのガベージコレクトされたプログラミング言語より柔軟な参照システムを持ち、ガベージコレクションに特別な振る舞いを許可する。Javaにある通常の参照は「強参照(")」として知られている。codice_12パッケージは三つのそれぞれの参照型—ソフト, 弱, ファントム参照 —を定義している。各々の参照型は特殊な用途のために設計されている。これらの各々の参照型はクラスを継承し、リファレント（指示対象オブジェクト）（または、もし参照がクリアされているか参照型がファントムであるならばcodice_14)への強参照を返すメソッド および、リファレンスをクリアするメソッドを提供する。codice_12 もまた参照型が変わるオブジェクトを保持するために上記で検討された各々のアプリケーションが使われるクラスを定義する。codice_16が生成されるとき、それは任意にリファレンスキューに登録される。アプリケーションは到達可能性状態に変化する参照を得るリファレンスキュー票を得る。参照型とリファレンスキューのより首尾よい説明は"Reference Objects and Garbage Collection" を参照。リフレクションはJavaコード調査や、実行時のJavaコンポーネントやリフレクトされたメンバを使用する上での「リフレクト」を可能にするJava APIの構成要素である。このパッケージにあるクラスは、codice_17とに加えて、デバッガやインタプリタ、オブジェクトインスペクタ（調査）、クラスブラウザのようなアプリケーション、オブジェクトシリアライゼーションやJavaBeansのようなサービスに適合し、（その実行クラスを基礎とする）ターゲットとなるオブジェクトのpublicメンバまたは与えられたクラスによって宣言されたメンバにアクセスする必要がある。このパッケージはJDK1.1より追加された。リフレクションはインスタンスによって使われ、それらの名前を使ってメソッドを呼び出す、動的プログラミングを許可する着想である。クラス、インタフェース、メソッド、フィールド、コンストラクタはすべて実行時に見つけて利用することができる。メタデータによってサポートされているリフレクションはそのプログラムの近くにあるJVMである。そこにはリフレクションによって呼び出された二つの技術がある。Discoveryはだいたいオブジェクトから始まり、codice_18のオブジェクトを取得するメソッドを呼び出す。codice_18オブジェクトはクラスの中身を発見する数種のメソッドを持つ。以下にその例を示す:codice_18オブジェクトは「クラスリテラル」(e.g. codice_25)を使用することまたは、メンバのシンボル名を使って得られるクラス(e.g. ). codice_18オブジェクト、メンバcodice_27、codice_28、codice_29オブジェクト、などの名前による発見を通して得られる。例:codice_27、codice_28、codice_29オブジェクトはクラスのメンバを表現した動的アクセスで利用することができる。例:codice_46引数に留まるものはメソッドによって渡される。(もしcodice_27オブジェクトが静的メソッドであるばあいは第一codice_39引数が無視されてcodice_14となることがある。)codice_52パッケージもまた静的メソッドを含み配列オブジェクトを巧みに扱うクラスと、J2SE1.3以降登場した、特定のインタフェースを実装したプロキシクラスの動的生成をサポートするクラスを提供する。codice_53クラスの実装はインタフェースを実装した補給オブジェクトによって提供される。codice_54の メソッドはプロキシオブジェクトで呼び出された各々のメソッドに呼ばれる。—第一引数はプロキシオブジェクト、第二引数はプロキシによって実装されたインタフェースメソッドcodice_27オブジェクト、第三引数はインタフェースメソッドへ渡す引数の配列である。codice_43メソッドはプロキシインタフェースメソッドを飛ぶコードを戻り値として含むcodice_39を戻り値として返す。codice_58パッケージは入出力(I/O)をサポートするクラスを含む。 パッケージにあるクラスは本来ストリーム指向である。; しかしながら、ランダムアクセスファイル (コンピュータ)としてのクラスもまた提供されている。パッケージで中心となるクラスはそれぞれバイトストリームの読み書きを行う抽象クラスであるとである。このパッケージもまた多数のファイルシステムとの相互作用をサポートする多少の様々なクラスを持っている。ストリームクラスはストリームクラスに特色を加えたベースとなるサブクラスを拡張したDecoratorパターンに沿っている。ベースとなるストリームクラスのサブクラスはたいてい以下の特質を用いて名付けられる。:ストリームサブクラスはcodice_59が特色を記述しcodice_60がcodice_61、codice_62、codice_63、codice_64のような名前をもつパターンcodice_65を使って名付けられる。以下の表はcodice_58パッケージが直にサポートする送信元/送信先を示す:他の標準ライブラリパッケージは、メソッドやJava EEのクラスが返すcodice_61のような他の送信先としてストリーム実装を提供する。データ型ハンドリング、ストリームデータのプロセッシングやフィルタリングはストリームフィルタを通してできあがっている。フィルタクラスはすべて、コンストラクタの引数としてもう一つの互換ストリームオブジェクトを受け入れ、追加された特色とともに囲まれたストリームをデコレート("decorate")する。ベースとなるフィルタクラス、、、を拡張することでフィルタは生成される。codice_63とcodice_64クラスは真に、バイトを文字にコンバートするためのデータストリームで追加処理を行うバイトストリームである。それらはJ2SE5.0から登場した静的メソッドによって返されるを使う。クラスはcodice_61をcodice_63へとコンバートし、クラスはcodice_62をcodice_64へコンバートする。これら双方のクラスは特別に役立つ文字エンコーディングを許可するコンストラクタを持っている—もしエンコーディングが指定されていなければ、プラットフォームにあるデフォルトエンコーディングを使用する。以下の表はcodice_58パッケージを直にサポートする他の処理、フィルタを示す。これらのクラスはすべてcodice_75クラスに相当するものを継承している。クラスはファイルの"ランダムアクセス"読み書きをサポートする。このクラスはファイル内の次の読込または書込命令を行うバイトオフセットを表現する"ファイルポインタ"を使用する。ファイルポインタは読み書きによって無条件に動かされ、またはメソッドによって明確になる。ファイルポインタのカレントポジションはメソッドによって返される。 クラスはファイルシステムのファイルやディレクトリパスを表現する。 codice_76オブジェクトはファイル、ディレクトリの生成、削除、リネームや「読み取り専用」や「最終更新タイムスタンプ」のようなファイル属性操作をサポートする。codice_76 オブジェクトはファイルとディレクトリを含むすべてのリストを得るために使われるディレクトリを表現することができる。J2SE 1.4では、パッケージcodice_82 (NIO または New I/O) がメモリマップドI/O、ときどき劇的にベターなパフォーマンスを得る基本ハードウェアと、よりいっそう親密な入出力命令を容易にするサポートが追加された。codice_82 パッケージはバッファ型サポートを提供する。サブパッケージ は文字データとは異なる文字エンコーディングサポートを提供する。サブパッケージ はファイルやソケットのようなI/O命令演算能力がある資格を与える接続を表現する「チャネル」サポートを提供する。codice_84 パッケージもまたファイルのきめ細かいロックサポートを提供する。java.math package (剰余演算を含む)多倍長精度の演算をサポートし暗号鍵を生成するための多倍長の素数生成を提供する。 以下にパッケージのメインクラスを示す:codice_81 パッケージは他の共通トランザクションと同じくらい良質のHTTPリクエストネットワーク向けに特別なI/Oルーチンを提供する。codice_89 パッケージは文字列をパースするルーチンを実装し、様々な自然言語、ロケールに依存したパースをサポートする。codice_90パッケージの中心である集約したオブジェクトデータ構造。パッケージに含まれているものは、デザインパターンを非常に考慮したデータ構造階層、コレクションAPI(コンテナ)である。Javaアプレット生成をサポートするために作られたcodice_91パッケージはネットワーク越しにダウンロードされた保護されたサンドボックス上で動くアプリケーションを許可する。セキュリティ制約は簡単にサンドボックスに適用される。開発者は、例えば、それが安全であることを示すために、アプレットに電子署名を適用することができる。(ローカルハードドライブにアクセスするような)制限された処理を行うアプレットの許可を認めるため、そういう行為をユーザに許し、サンドボックスの制限を部分的または全て取り払う。デジタル証明書はThawteやEntrustのような機関によって発行される。codice_92パッケージに含まれているものは開発やbean操作のための様々なクラスであり、JavaBeansアーキテクチャによって定義された再利用コンポーネントである。アーキテクチャはコンポーネントのプロパティ操作やそれらのプロパティが変更されたときの発火イベントのメカニズムを提供する。codice_92にあるAPIの多くはbeanが結合、カスタマイズ、操作されうるbean編集ツールによる使用として書かれている。beanエディタのとあるタイプは、IDEにあるGUIデザイナである。The Abstract Windowing Toolkit(AWT)は基本的なGUI命令をサポートするルーチンを含み、基礎を成すネィティブシステムから基本的なウィンドウズを使用する。Java API（GNUのlibgcjのような）多くの独自実装は何もかも実装しているがしかし、AWTは多くのサーバサイドアプリケーションで使われていない。このパッケージもまたJava 2DグラフィックAPIを含んでいる。codice_94 パッケージは異なるJVM上にある2つのJavaアプリケーション間でのRPCをサポートする Java Remote Method Invocationを提供する。メッセージダイジェストアルゴリズムを含んでいるセキュリティサポートはcodice_95 に含まれている。JDBC API (SQLデータベース接続で使用)の実装はcodice_96パッケージにまとめられている。アプリケーション間のリモート間通信を提供し、RMI over IIOPプロトコルを使用する。このプロトコルはRMIとCORBAと連携させる。general inter ORB protocolを使用するアプリケーション間のリモート間通信をサポートし、CORBAの他のフィーチャーをサポートする。RMIとRMI-IIOPと同じく、このパッケージは(通常、ネットワーク経由で)他の仮想マシン上で動いているオブジェクトのリモートメソッドを呼ぶためにある。 すべての通信可能性からCORBAは様々なプログラミング言語でもっともポータブルである。しかしながら、それはCORBAを理解することをもいくぶん難しくしている。Swing はプラットフォーム非依存ウィジェット・ツールキットを提供するcodice_97を構築するルーチンの集合である。SwingはOS独自のGUIサポートに頼る替わりに、ユーザインタフェースコンポーネントをレンダリングするために2次元描画ルーチンを使用する。Swingは、GUI上のウィジェットは基礎を成すネイティブシステムからそれらを見習うことができるように、PLAFs(pluggable looks and feels))をサポートし他に頼らない非常にリッチなシステムである。システム全体に行き渡っているデザインパターン、特にMVCパターンの修正は機能と外観との間の結合度を緩めている。 一つの不調和は、(J2SE1.3での)フォントは基本を成すネイティブシステムに依存して描かれていることであり、Javaでは描かれない、限定的なテキストポータビリティである。次善策としては、ビットマップフォントを使うことが挙げられる。一般的に「レイアウト」は美学的にプラットフォームを横渡る一貫したGUIからなる構成要素を使用維持する。様々なウェブブラウザやウェブボットの記述に関して使われるエラーに寛大なHTMLパーサを提供する。

出典:wikipedia