Javaの文法はJavaプログラムを記述し解釈する方法を定義するルールの集合である。Javaは配列と文字列を扱うため専用の文法を持ってはいるが、配列と文字列は基本型ではない: それらはに代入できる参照型である。 // 配列を宣言 - 配列名は「myArray」、 要素の型は "SomeClass" への参照 SomeClass[] myArray = null;Javaはbyte型と文字型とを区別する。文字型変数は内部表現としてUTF-16で表現されている。また、J2SE 5.0以降ではサロゲートAPIによって、すべてのUnicode文字を扱える。Javaプログラムのソースコードに直接Unicode文字を記述することもできる。例えば、次のソースコードはJavaのコードとして正しく解釈されコンパイルされる。ここではクラス名、変数名、および文字列リテラルとして日本語の文字を使っている。関係演算子(==と!=)を参照型に対して用いた場合、そこで比較されるのは参照先のオブジェクトが同じかどうかであり、オブジェクトの中身の値が一致するか否かではない。オブジェクトの中身を比較したい場合はメソッドを使用する。instanceof演算子は或るオブジェクトが或るクラスのインスタンスであるか否かを判定するために用いる。三項演算子は二つの記号codice_3とcodice_4を組み合わせて記述する。条件演算子とも呼ぶ。構文:条件がcodice_5であるとき、式1の値をとる。そうでない場合は式2の値をとる。例:(訳注:上の通り、&&と||は左のオペランドしか評価しない可能性がある。これに対し、ビット演算子にも挙げられている&と|を代わりに書いた場合は、左右のオペランド両方が完全に評価される。実用上は&&と||を用いるのが一般的である) if (expr) {(訳注：上記文章では、「関係演算子」の節で述べている事柄であると考えられる。） switch (expr) { for (initial-expr; cond-expr; incr-expr) {J2SE 5.0では、for-each文と呼ばれる新機能が追加された。これは集合の中の全要素を順番に参照するような処理を大いに簡素化する。このような場合、従来は次の例に示すような反復子(iterator)を書かねばならなかった:for-each文はこのメソッドを大いに簡素化する:この例の動作としては、stringSetに含まれる全てのについて、長さを取得してsumに加算する。 while (expr) { do {例 LABEL1: statement;"codice_6" 文はJavaの予約語であるが、Javaでは機能しない。Javaでは別のクラスやインタフェース内部で宣言された「ネスト」されたクラスを作ることができる。ネストされていないクラスは「トップレベル」クラスと呼ばれる。非staticなネストされたクラスのことは「内部クラス」と呼ぶ。クラスを宣言する際は以下の修飾子を付けることができる:Javaのクラスはセミコロン(";")で終わらせる必要はない点に注意。この点はC++の文法と異なる。 // 子クラスは親クラスを継承するインタフェースとは、実装の詳細がいっさいない抽象クラスである。その目的は複数のクラスの用途をまとめて定義することにある。共通のインタフェースを実装する複数のクラスは、そのインタフェース型のコンテキストにしたがって互いに交換可能とすることができる。インタフェースはまた、抽象化 – クラスの実装方法を隠蔽すること – という考え方を強制するのにも役立つ。インタフェースは抽象メソッドとstatic finalフィールドだけを含むことができる。インタフェースメソッドはデフォルトでpublicかつabstractであり（実装を持たない）、インタフェースフィールドはデフォルトで public static final である。Javaは完全なの多重継承はサポートしていない。C++における多重継承には、複数の親クラスや型から複数回継承したフィールドやメソッドを識別するための複雑なルールが伴う。インタフェースを実装から分離することにより、インタフェースはより単純かつ明快に多重継承が持つ利点の多くを提供する。もっとも、多重継承を避ける代価としてコードは若干冗長になる。というのは、インタフェースはクラスのシグネチャを定義するのみで実装を持てないため、インタフェースを継承する全てのクラスは定義されたメソッドをいちいち実装しなければならないからである。純粋な多重継承であれば実装自体も継承されるのでこのようなことはない。Javaのインタフェースは Objective-C規約のコンセプトによく似た振る舞いをする。クラスは、一つのクラスを継承できるのに加えて、implementsキーワードを用いて一つ以上のインタフェースを実装することができる。以下の例では、codice_14インタフェースを実装する非codice_7クラスは、引数無しで戻り型がcodice_16であるcodice_17という名前の非抽象メソッドを定義しなければならない。そのメソッドの実装と機能は各々のクラスによって決定される。このコンセプトにはさまざまな使い道がある。例えば:上の配列に含まれる全てのオブジェクトはcodice_18メソッドを持つことが保証されるので、codice_19メソッドはcodice_20オブジェクトと他の如何なるcodice_14オブジェクトをも区別する必要がない。インタフェースはcodice_22キーワードを用いて一つ以上のインタフェースを継承することができる。結果として生じるインタフェースを実装するクラスは、元のインタフェースに含まれたメソッドをも併せて定義しなければならない。アクセス修飾子は、そのクラスやクラスメンバにアクセス可能なコードが誰であるかを決定する。デフォルトでは、Javaのクラスは、それら自身のJavaパッケージからのみアクセスできる。これは、クラスのパッケージが、裏に隠れて機能を実行するようなＡＰＩを提供することを可能とする。外にアクセスを公開されたクラスの動作を、隠されたクラスが支える形になる。"クラスメンバ"とはフィールド、メソッド、コンストラクタ、クラス内で定義されたネストされたクラスのことである。アクセス制限が厳しいものから並べると、クラスメンバのアクセス修飾子は次の通り。メソッドをオーバライドする際、そのメソッドのアクセス権を「より厳しく」することはできない。さもなくば親クラスのインタフェース契約を壊してしまうからである。したがってオーバライドされる場合、publicメソッドはpublicとして宣言されねばならず、protectedメソッドをデフォルトアクセス権（修飾子省略）とすることはできない。しかしながら、メソッドをオーバライドしてアクセス権を「より緩める」ことは許される。したがってオーバライドする際、デフォルト(パッケージ)アクセス権のメソッドはprotectedまたはpublicとして宣言することができ、protectedメソッドはpublicとして宣言することができる。アクセス修飾子に加えて、データフィールドは以下の修飾子によって宣言される:staticとfinal両方を宣言されたフィールドは事実上、定数である。codice_24はそのフィールドがそのクラスにおいてただ一つのみ存在することを示し、codice_27はそのフィールドがただ一度のみ値を設定（初期化）可能であることを意味する。「イニシャライザ」(初期化子)はフィールドのイニシャライザと同時に実行されるコードのブロックである。「スタティックイニシャライザ」（静的初期化子）はstaticフィールドのイニシャライザと同時に実行されるコードのブロックである。静的フィールド初期化子と静的初期化子は宣言された順番に実行される。静的初期化はクラスがロードされた後で実行される。「インスタンスイニシャライザ」（インスタンス初期化子）はインスタンスの(非codice_24な)フィールドの初期化子と同時に実行されるコードのブロックである。インスタンスフィールド初期化子とインスタンス初期化子は宣言された順番に実行される。インスタンス初期化子とインスタンスフィールド初期化子はコンストラクタが呼び出された際に実行される。正確な実行順序としては、親クラスのコンストラクタが実行された後、かつ、自身のコンストラクタが実行される前、となる。アクセス修飾子に加えて、メソッドには以下の修飾子を付けて宣言できる：privateメソッドは自ずからfinalであり、abstractにはできない点に注意。Java SE 5.0において、引数の個数が可変であるようなメソッドについての文法上の便宜()が追加された。これによって引数の個数が可変であるメソッドをタイプセーフに使用することが容易になる。最後のパラメタの後に「...」と書くと、Javaは全ての引数を配列に格納する：このメソッドを呼ぶ際、プログラマは個々のpointsを単にカンマで区切って書けばよく、Pointオブジェクトの配列をわざわざ用意する必要はない。このメソッドの内部でpointsを参照する際はpoints[0]、points[1]、などのように書ける。pointsが渡されていない場合、配列のlengthは0となる。可変個の引数と別に固定的に必要なパラメタがある場合は、それらのパラメタは可変引数に先立って指定すればよい。コンストラクタはオブジェクトが割り当てられた後すぐに呼び出され、オブジェクトの初期処理を行う。コンストラクタは典型的にはnewキーワードを使用して呼び出されるが、リフレクションを使用して呼ぶこともできる。リフレクション機能はjava.lang.reflectパッケージより提供される。コンストラクタを宣言する際に使える修飾子はアクセス修飾子のみである。クラスのメソッドは継承されるので、全てのクラスにて使用できる。メソッドは現在のオブジェクトのコピーである新しいオブジェクトを返す。クラスは、それがクローンできることを明示するためにマーカーインタフェースを実装しなければならない。メソッドはそのオブジェクトともう一つのオブジェクトを比較し、二つのオブジェクトが同一かどうかをcodice_40型の値で返す。意味的には、このメソッドはオブジェクトの内容を比較するのに対し、関係演算子"codice_41"はオブジェクトの参照を比較する。codice_39メソッドはパッケージにあるデータ構造クラスの多くで使われる。これらのデータ構造クラスのいくつかはcodice_43メソッドにも依存している - codice_39とcodice_45との間の契約の詳細について、hashCodeメソッドを参照のこと。メソッドはガベージコレクタがオブジェクトのメモリを解放する前に必ず一度だけ呼び出される。オブジェクトが消滅する前に実行しなければならない何らかの後処理がある場合、各クラスはcodice_46をオーバーライドすることができる。とはいえほとんどのオブジェクトはcodice_46をわざわざオーバーライドする必要はない。codice_46メソッドがいつ呼ばれるかは保証されない。複数のオブジェクトのcodice_46がどのような順番で呼ばれるかも不定である。もしJVMがガベージコレクションを実行せずに終了するならば、OSがオブジェクトを解放する可能性があり、その場合codice_46メソッドは呼ばれない。codice_46メソッドは、他のクラスから呼ばれるのを防ぐために、常にprotectedとして宣言されるべきである。メソッドはオブジェクトをインスタンス化するために使われたクラスのオブジェクトを返す。このクラスオブジェクトはJavaにおけるリフレクションの基本となる。その他のリフレクション機能はcodice_54パッケージにて提供される。メソッドは連想配列にオブジェクトを保存するための「ハッシュ値」として(codice_56型の)整数を返す。インタフェースを実装するクラスは連想配列を提供しcodice_45メソッドに依存する。codice_45の良い実装は安定(不変)かつ均等に分布するハッシュ値を返す(異なるオブジェクトのハッシュ値は互いに異なる値となる傾向を持ち、かつハッシュ値は整数値の範囲内で均等に分布する。)。連想配列はcodice_39とcodice_45の両メソッドに依存するため、これら二つのメソッドの間では、オブジェクトがcodice_61に挿入される場合に関する或る重要な契約が維持されねばならない：この契約を維持するために、codice_39メソッドをオーバーライドしたクラスは同時にcodice_45メソッドもオーバーライドし、逆もまた同様として、codice_45とcodice_39が常に同じ性質（または同じ性質の一部）に基づくようにしなければならない。マップがオブジェクトとの間に有する更なる契約は、ひとたびオブジェクトがマップに挿入されたなら、codice_45 と codice_39両メソッドの結果は以後変わらないということである。したがって、一般にハッシュ関数はオブジェクトの不変(変更不能)な属性に基くように設計するのが良い。メソッドはオブジェクトの文字列表現をで返すものである。codice_71メソッドは、オブジェクトが文字列連結演算子(codice_73とcodice_74)のオペランドとして使われたとき、コンパイラによって暗黙のうちに呼び出される。全てのオブジェクトは、そのオブジェクトに関連するスレッドについての二つの待ちリストを持つ。一つの待ちリストはsynchronizedキーワードに伴いオブジェクトをミューテックス排他するために使われる。もしミューテックスが他スレッドによって排他されているならば、自スレッドは排他を待っているスレッドのリストに追加される。もう一つの待ちリストはスレッド間でシグナルを送るためのもので、これはwait、notify、notifyAllの各メソッドを通して使用される。wait/notifyを用いるとスレッド間での能率的な連携が可能となる。あるスレッドが別スレッドでの処理が終わるのを待ち合わせる必要があるとき、または何らかのイベントが発生するまで待たねばならないとき、スレッドはその実行を一時停止してイベントが発生した際に通知を受け取ることができる。これはポーリングとは対照的である。ポーリングにおいては、スレッドは一定時間スリープしてはフラグや他の状態表示をチェックする処理を繰り返す。ポーリングはスレッドがチェックを繰り返さねばならないという点でより計算コストが掛かる上に、実際にチェックしてみるまでイベント発生を検知できないという意味で鈍感でもある。codice_75メソッドには三つのオーバーロード版があり、タイムアウト値の指定方法がそれぞれ異なる：、、の三つである。一つ目のメソッドはタイムアウト値が0であり、これはタイムアウトが発生しないことを意味する。二つ目のメソッドはミリ秒単位のタイムアウト値を取る。三つ目のメソッドはナノ秒単位のタイムアウト値を取り、これはcodice_77として計算される。codice_75を呼んだスレッドは待機状態となり、そのオブジェクトの待ちリストに追加される。そのスレッドは以下の三つのイベントのいずれか一つが起きるまで、オブジェクトの待ちリスト上に留まる：codice_75メソッドは、そのオブジェクトについての同期(synchronized)ブロックまたは同期(synchronized)メソッドの内部からのみ呼ばねばならない。これはcodice_75とcodice_79との間で競合を起こさないためである。スレッドが待ちリストに入るとき、そのスレッドはそのオブジェクトのミューテックス排他を解除する。そのスレッドが待ちリストから削除され実行可能スレッドとなった際に、そのスレッドは走行を再開するのに先立ってそのオブジェクトのミューテックスを改めて排他しなければならない。 と メソッドはオブジェクトの待ちリストから一つ以上のスレッドを削除し、それらを実行可能スレッドとする。codice_79は待ちリストから1スレッドのみ削除し、codice_80は待ちリストから全てのスレッドを削除する。codice_79がどのスレッドをリストから削除するかは規定されておらず、JVMの実装に依存する。codice_79とcodice_80メソッドは、そのオブジェクトについての同期(synchronized)ブロックまたは同期(synchronized)メソッドの内部からのみ呼ばねばならない。これはcodice_75とcodice_79との間で競合を起こさないためである。J2SE1.4よりも前のバージョンのJavaはストリーム・ベースののみをサポートしていた。これは1ストリームにつき1スレッドを必要とした。何故ならストリームの入力または出力を行おうとすると、それが完了するまでそのスレッドは完全に待ちに入ってしまい、他の処理がいっさい行えなくなったからである。これは、Javaを用いたネットワークサービスを構築する上で、スケーラビリティと性能双方の面で大きな問題となっていた。J2SE1.4以降ではフレームワークとしてNIO(New I/O)が導入され、このスケーラビリティ問題は修正された(ただし、サンによるNIO APIの実装にはまだ多くの問題点がある)。非ブロッキングIOフレームワークは、以前のブロッキングIOフレームワークより遥かに複雑ではあるが、一つのスレッドで任意の数の"チャネル"を扱うことができる。このフレームワークはをベースとしている。 public class MyClass { // MyApplet.java import java.applet.*; // MyApplet.java /*Javaはケースセンシティブ (大文字小文字を区別する) である。 // 一行コメント

出典:wikipedia