stanford-oval/wikipedia huggingface dataset:
Javaの文法
オブジェクト > クラス

Javaではクラスあるいはインタフェースの内部で別のクラスを宣言することができる。これは「ネストされたクラス」(nested class) と呼ばれる。ネストされていないクラスは「トップレベルクラス」(top-level class) と呼ばれる。ネストされたクラスがstatic修飾されていない場合、「内部クラス」(inner class) となる。内部クラスは外側のクラスのインスタンスを暗黙的にキャプチャすることで、静的メンバ、非静的メンバいずれにもアクセスすることができる。ネストされたクラスがstatic修飾されている場合、「静的クラス」(static class) となり、静的メンバのみにアクセスできる。メソッドの内部にクラスを定義することもでき、これは「ローカルクラス」(local class) と呼ばれる。ローカルクラスでは、外側のローカル変数には読み取りアクセスのみできる。また、型の名前を持たないローカルクラスとして「匿名クラス」(anonymous class) を定義し、同時にインスタンス生成をすることもできる。
クラスあるいはインタフェースの内部で別のインタフェースを宣言することもできる。これは「ネストされたインタフェース」と呼ばれる。
クラスを宣言する際は以下の修飾子を付けることができる:
abstract – インスタンス化できない。インタフェースとabstract (抽象) クラスだけがabstract (抽象) メソッドを持つことができる。抽象クラスを継承する具象 (非abstract) サブクラスは、引き継がれた全ての抽象メソッドを、abstractでないメソッドでオーバーライドしなければならない。修飾子finalと併用することはできない。
final – サブクラスを作らせない。 finalクラスのすべてのメソッドは無条件にfinalになる。 修飾子abstractと併用することはできない。
strictfp – このクラスとそこに含まれる全てのネストクラスにおいて、全ての浮動小数点演算は厳密な浮動小数点演算動作を使用する。厳密な浮動小数点演算動作は、演算結果がプラットフォームに関わりなく同一となることを保証する。
Javaのクラス定義ブロックはセミコロン;で終わらせる必要はない点に注意。この点はC++の文法と異なる。
オブジェクト > クラス > 継承

// 子クラスは親クラスを継承する
class ChildClass extends ParentClass { ... }
任意のクラスのデフォルトの親クラスはObjectクラスである。
クラスは単一の親クラスだけを継承できる。実装多重継承はできない。
オブジェクト > クラス > スコープ

this – 現在のサブクラス (デフォルト) への参照 (例：this.someMethod())。
super – 親クラスへの参照 (例：super.someMethod())。サブクラスがオーバライドした親クラスのメソッドや、サブクラスが継承しつつも隠蔽した親クラスのフィールドにアクセスするために使うことができる。
オブジェクト > インタフェース

インタフェースとは、実装の詳細がいっさいない抽象型である。その目的は複数のクラスを多態性によって統一的に扱うことである。共通のインタフェースを実装する複数のクラスは、そのインタフェース型のコンテキストにしたがって互いに交換可能とすることができる（リスコフの置換原則）。インタフェースはまた、抽象化 – クラスの実装方法を隠蔽すること – という考え方を強制するのにも役立つ。
インタフェースは抽象メソッドと定数フィールド (static finalフィールド) だけを含むことができる。インタフェースメソッドはデフォルトでpublicかつabstractであり（実装を持たない）、インタフェースフィールドはデフォルトで public static final である。インスタンスフィールドやクラスフィールドすなわち状態を持つことができない点が抽象クラスと異なる。
Javaは完全な直交の多重継承はサポートしておらず、インタフェースによる「型の多重継承」のみをサポートする。C++における多重継承（実装の多重継承）には、複数の親クラスや型から複数回継承したフィールドやメソッドを識別するための複雑なルールが伴う。インタフェースを実装から分離することにより、インタフェースはより単純かつ明快に多重継承が持つ利点の多くを提供する。もっとも、実装の多重継承を避ける代価としてコードは若干冗長になる。というのは、インタフェースはクラスのシグネチャを定義するのみで実装を持てないため、インタフェースを継承する全てのクラスは定義されたメソッドをいちいち実装しなければならないからである。純粋な多重継承であれば実装自体も継承されるのでこのようなことはない。
なお、Java 8ではインタフェースのデフォルトメソッドにより実装の多重継承を限定的にサポートするようになった。また、インタフェースが静的メソッドを持つこともできるようになった。
Javaのインタフェースは Objective-C規約のコンセプトによく似た振る舞いをする。
オブジェクト > インタフェース > インタフェースの実装

クラスは、一つのクラスを継承できるのに加えて、implementsキーワードを用いて一つ以上のインタフェースを実装することができる。
interface MyInterface {
    void foo();
}

interface Interface2 {
    void bar();
}

class MyClass implements MyInterface {
    void foo() {...}
    ...
}

class ChildClass extends ParentClass implements MyInterface, Interface2 {
    void foo() {...}
    void bar();
    ...
}
以下の例では、Deleteableインタフェースを実装する非abstractクラスは、引数無しで戻り型がvoidであるdeleteという名前の非抽象メソッドを定義しなければならない。そのメソッドの実装と機能は各々のクラスによって決定される。
public interface Deleteable {
    void delete();
}
このコンセプトにはさまざまな使い道がある。例えば:
public class Fred implements Deleteable {
    // このメソッドはDeleteableインタフェースを満足する
    public void delete() {
        // ここにコードを実装
    }
    public void someOtherMethod() {
    }
}

public void deleteAll(Deleteable[] list) {
    for (int i = 0; i < list.length; i++) {
        list[i].delete();
    }
}
上の配列に含まれる全てのオブジェクトはdelete()メソッドを持つことが保証されるので、deleteAll()メソッドはFredオブジェクトと他の如何なるDeleteableオブジェクトをも区別する必要がない。
オブジェクト > インタフェース > インタフェースの継承

インタフェースはextendsキーワードを用いて一つ以上のインタフェースを継承することができる。
interface ChildInterface extends ParentInterface, AnotherInterface {
    ...
}
結果として生じるインタフェースを実装するクラスは、元のインタフェースに含まれたメソッドをも併せて定義しなければならない。
public interface MyInterface {
    foo();
}

public interface Interface2 extends MyInterface {
    bar();
}

public class MyClass implements Interface2 {
    void foo() {...}
    void bar() {...}
    ...
}
オブジェクト > アクセス修飾子

アクセス修飾子は、そのクラスやクラスメンバにアクセス可能なクラスを決定する。
オブジェクト > アクセス修飾子 > トップレベルクラスアクセス

デフォルトでは、Javaのクラスは、それら自身のJavaパッケージからのみアクセスできる。これは、クラスのパッケージが、裏に隠れて機能を実行するようなＡＰＩを提供することを可能とする。外にアクセスを公開されたクラスの動作を、隠されたクラスが支える形になる。
デフォルト (修飾子を省略した場合) – 定義されたパッケージ内からのみアクセス可能。
public – 定義されたパッケージの外のクラスからもアクセス可能。
オブジェクト > アクセス修飾子 > クラスメンバアクセス

クラスメンバとはフィールド、メソッド、コンストラクタ、クラス内で定義されたネストされたクラスのことである。アクセス制限が厳しいものから並べると、クラスメンバのアクセス修飾子は次の通り。
private – そのクラスからのみアクセス可能 (内部クラスからのアクセスを含む)。private宣言されたメンバはサブクラスによって引き継ぐことができない。
package-private (修飾子を省略した場合) – 同じパッケージ内の他クラスからもアクセス可能。
protected – 上に加え、パッケージ外の継承クラスからアクセス可能。
public – 任意のクラスからアクセス可能。
メソッドをオーバライドする際、そのメソッドのアクセス権を「より厳しく」することはできない。さもなくば親クラスのインタフェース契約を壊してしまうからである。したがってオーバライドされる場合、publicメソッドはpublicとして宣言されねばならず、protectedメソッドをデフォルトアクセス権（修飾子省略）とすることはできない。しかしながら、メソッドをオーバライドしてアクセス権を「より緩める」ことは許される。したがってオーバライドする際、デフォルト (パッケージ) アクセス権のメソッドはprotectedまたはpublicとして宣言することができ、protectedメソッドはpublicとして宣言することができる。
オブジェクト > フィールド

アクセス修飾子に加えて、データフィールドは以下の修飾子によって宣言される:
final – このフィールドの中身は変更できない。ただ一度のみ値を設定（初期化）できる。イニシャライザ (初期化子) がないfinalフィールドを「ブランクfinal」フィールドと呼ぶ。staticなブランクfinalフィールドは最終的にスタティックイニシャライザによって初期化されなければならない。staticでないブランクfinalフィールドはコンストラクタの実行中に必ず初期化されなければならない。volatileにはなれない。
static – クラスのインスタンスではなくクラスに属する。
transient – オブジェクトの中でも永続的 (persistent) にできないフィールドである。このフィールドの中身を待避または復元してはならないことをコンパイラに知らせる。
volatile – そのフィールドが他スレッドによって非同期にアクセスされる可能性があることをコンパイラに知らせる。finalにはなれない。
オブジェクト > フィールド > 定数

staticとfinal両方を宣言されたフィールドは事実上、定数である。staticはそのフィールドがそのクラスにおいてただ一つのみ存在することを示し、finalはそのフィールドがただ一度のみ値を設定（初期化）可能であることを意味する。
オブジェクト > 初期化子

「イニシャライザ」（初期化子）はフィールドのイニシャライザと同時に実行されるコードのブロックである。
オブジェクト > 初期化子 > 静的初期化子

「スタティックイニシャライザ」（静的初期化子）はstaticフィールドのイニシャライザと同時に実行されるコードのブロックである。静的フィールド初期化子と静的初期化子は宣言された順番に実行される。静的初期化はクラスがロードされた後で実行される。
static int count = 20;
static int[] squares;
static {  // スタティックイニシャライザ
    squares = new int[count];
    for (int i = 0; i < count; i++)
        squares[i] = i * i;
}
static int x = squares[5];  // x には値25が代入される。
オブジェクト > 初期化子 > インスタンス初期化子

「インスタンスイニシャライザ」（インスタンス初期化子）はインスタンスの (非staticな) フィールドの初期化子と同時に実行されるコードのブロックである。インスタンスフィールド初期化子とインスタンス初期化子は宣言された順番に実行される。
インスタンス初期化子とインスタンスフィールド初期化子はコンストラクタが呼び出された際に実行される。正確な実行順序としては、親クラスのコンストラクタが実行された後、かつ、自身のコンストラクタが実行される前、となる。
オブジェクト > メソッド

アクセス修飾子に加えて、メソッドには以下の修飾子を付けて宣言できる：
abstract – 当該クラスでは定義されないメソッドであり、代わりに当該クラスの全ての具象 (非abstract) サブクラスによって定義されなければならない。static、final、nativeのいずれとも併用できない。
final – サブクラスによって再定義できないメソッド。そのメソッドがインスタンス (非static) メソッドでありかつ十分小さいならば、コンパイラはそのメソッドをインライン関数のように各所に展開する場合がある（訳注：性能改善目的と思われる）。abstractと併用はできない。
native – このメソッドはネイティブなマシン依存コードにリンクする。メソッド本体無しで宣言される。abstractと併用はできない。Java Native Interfaceにて使用される。
static – クラスのインタンスではなく、クラスに属する。abstractと併用はできない。
strictfp – メソッドとそこに含まれる内部クラス全てにおける浮動小数点演算が、厳密な浮動小数点演算動作を使用する。厳密な浮動小数点演算動作は、演算結果がプラットフォームに関わりなく同一となることを保証する。
synchronized – メソッド本体を実行する前に、関連オブジェクトを排他する。関連オブジェクトが他スレッドにて排他済である場合、他スレッドが排他を解除し自スレッドが排他を獲得するまで実行を待たされる。ここで言う関連オブジェクトとは、そのメソッドがstaticならばClassオブジェクトを指し、非staticならばオブジェクトインスタンスを指す。abstractメソッドをsynchronizedとして宣言することは可能だが意味はない。何故なら排他とは宣言ではなく実装に伴う機能であり、抽象メソッドは実装を持たないからである。
privateメソッドは自ずからfinalであり、abstractにはできない点に注意。
オブジェクト > メソッド > 可変引数

Java SE 5.0において、引数の個数が可変であるようなメソッドについての文法上の便宜 (varargs) が追加された。これによって引数の個数が可変であるメソッドをタイプセーフに使用することが容易になる。最後のパラメタの後に「...」と書くと、Javaは全ての引数を配列に格納する：
public void drawPolygon(Point... points) { /* ... */ }
このメソッドを呼ぶ際、プログラマは個々のpointsを単にカンマで区切って書けばよく、Pointオブジェクトの配列をわざわざ用意する必要はない。このメソッドの内部でpointsを参照する際はpoints[0]、points[1]、などのように書ける。pointsが渡されていない場合、配列のlengthは0となる。可変個の引数と別に固定的に必要なパラメタがある場合は、それらのパラメタは可変引数に先立って指定すればよい。
// ポリゴンは少なくとも3つの点を必要とする。
public void drawPolygon(Point p1, Point p2, Point p3, Point... otherPoints) { /* ... */ }
オブジェクト > コンストラクタ

コンストラクタはオブジェクトが割り当てられた後すぐに呼び出され、オブジェクトの初期処理を行う。コンストラクタは典型的にはnewキーワードを使用して呼び出されるが、リフレクションを使用して呼ぶこともできる。リフレクション機能はjava.lang.reflectパッケージより提供される。
コンストラクタを宣言する際に使える修飾子はアクセス修飾子のみである。
可能ならば、オブジェクトはひとたびコンストラクタを呼ばれた以後は直ちに有効かつ有意味なオブジェクトとなるべきである。分割された複数の初期化用メソッドを使わなければ初期処理が完了しないというような設計は好ましくない。
慣習として、引数としてそのオブジェクト自身の型を受け取ってデータメンバを複写するようなコンストラクタを「コピーコンストラクタ」と呼ぶ。
コンストラクタが明示的に定義されていない場合、コンパイラは暗黙のうちに内容が空で引数を取らないデフォルトのコンストラクタを生成する。
コンストラクタはオーバーロードできる。
コンストラクタ内の最初の文は親クラスのコンストラクタ：super(...);または同じクラス内の別のコンストラクタ：this(...);を呼び出せる。
もし、super(...) または this(...)に対する明示的な呼び出しがないならば、コンストラクタ本体が実行される前に、親クラスのデフォルトコンストラクタsuper();が呼ばれる。
オブジェクト > Objectクラスのメソッド

Objectクラスのメソッドは継承されるので、全てのクラスにて使用できる。
オブジェクト > Objectクラスのメソッド > cloneメソッド

詳細は「クローン (関数)」を参照
Object.clone()メソッドは現在のオブジェクトのコピーである新しいオブジェクトを返す。クラスは、それがクローンできることを明示するためにマーカーインタフェースCloneableを実装しなければならない。
オブジェクト > Objectクラスのメソッド > equalsメソッド

Object.equals(Object)メソッドはそのオブジェクトともう一つのオブジェクトを比較し、二つのオブジェクトが同一かどうかをboolean型の値で返す。意味的には、このメソッドはオブジェクトの内容を比較するのに対し、関係演算子"=="はオブジェクトの参照を比較する。equalsメソッドはjava.utilパッケージにあるデータ構造クラスの多くで使われる。これらのデータ構造クラスのいくつかはObject.hashCodeメソッドにも依存している - equalsとhashCodeとの間の契約の詳細について、hashCodeメソッドを参照のこと。
オブジェクト > Objectクラスのメソッド > finalizeメソッド

詳細は「ファイナライザ」を参照
Object.finalize()メソッドはガベージコレクタがオブジェクトのメモリを解放する前に必ず一度だけ呼び出される。オブジェクトが消滅する前に実行しなければならない何らかの後処理がある場合、各クラスはfinalizeをオーバーライドすることができる。とはいえほとんどのオブジェクトはfinalizeをわざわざオーバーライドする必要はない。
finalizeメソッドがいつ呼ばれるかは保証されない。複数のオブジェクトのfinalizeがどのような順番で呼ばれるかも不定である。もしJVMがガベージコレクションを実行せずに終了するならば、OSがオブジェクトを解放する可能性があり、その場合finalizeメソッドは呼ばれない。
finalizeメソッドは、他のクラスから呼ばれるのを防ぐために、常にprotectedとして宣言されるべきである。
protected void finalize() throws Throwable { ... }
オブジェクト > Objectクラスのメソッド > getClassメソッド

Object.getClass()メソッドはオブジェクトをインスタンス化するために使われたクラスのClassオブジェクトを返す。このクラスオブジェクトはJavaにおけるリフレクションの基本となる。その他のリフレクション機能はjava.lang.reflectパッケージにて提供される。
オブジェクト > Objectクラスのメソッド > hashCodeメソッド

Object.hashCode()メソッドは連想配列にオブジェクトを保存するための「ハッシュ値」として (int型の) 整数を返す。java.util.Mapインタフェースを実装するクラスは連想配列を提供しhashCodeメソッドに依存する。hashCodeの良い実装は安定 (不変) かつ均等に分布するハッシュ値を返す (異なるオブジェクトのハッシュ値は互いに異なる値となる傾向を持ち、かつハッシュ値は整数値の範囲内で均等に分布する)。
連想配列はequalsとhashCodeの両メソッドに依存するため、これら二つのメソッドの間では、オブジェクトがMapに挿入される場合に関する或る重要な契約が維持されねばならない：
a.equals(b) == b.equals(a)でなければならない。
もしa.equals(b)がtrueならば、a.hashCode() == b.hashCode()でなければならない。
この契約を維持するために、equalsメソッドをオーバーライドしたクラスは同時にhashCodeメソッドもオーバーライドし、逆もまた同様として、hashCodeとequalsが常に同じ性質（または同じ性質の一部）に基づくようにしなければならない。
マップがオブジェクトとの間に有する更なる契約は、ひとたびオブジェクトがマップに挿入されたなら、hashCode と equals両メソッドの結果は以後変わらないということである。したがって、一般にハッシュ関数はオブジェクトの不変(変更不能)な属性に基くように設計するのが良い。
オブジェクト > Objectクラスのメソッド > toStringメソッド

Object.toString()メソッドはオブジェクトの文字列表現をStringで返すものである。toStringメソッドは、オブジェクトが文字列連結演算子(+と+=)のオペランドとして使われたとき、コンパイラによって暗黙のうちに呼び出される。
オブジェクト > Objectクラスのメソッド > waitとnotifyスレッドシグナルメソッド

全てのオブジェクトは、そのオブジェクトに関連するスレッドについての二つの待ちリストを持つ。一つの待ちリストはsynchronizedキーワードに伴いオブジェクトをミューテックス排他するために使われる。もしミューテックスが他スレッドによって排他されているならば、自スレッドは排他を待っているスレッドのリストに追加される。もう一つの待ちリストはスレッド間でシグナルを送るためのもので、これはwait、notify、notifyAllの各メソッドを通して使用される。
wait/notifyを用いるとスレッド間での能率的な連携が可能となる。あるスレッドが別スレッドでの処理が終わるのを待ち合わせる必要があるとき、または何らかのイベントが発生するまで待たねばならないとき、スレッドはその実行を一時停止してイベントが発生した際に通知を受け取ることができる。これはポーリングとは対照的である。ポーリングにおいては、スレッドは一定時間スリープしてはフラグや他の状態表示をチェックする処理を繰り返す。ポーリングはスレッドがチェックを繰り返さねばならないという点でより計算コストが掛かる上に、実際にチェックしてみるまでイベント発生を検知できないという意味で鈍感でもある。
オブジェクト > Objectクラスのメソッド > waitとnotifyスレッドシグナルメソッド > waitメソッド

waitメソッドには三つのオーバーロード版があり、タイムアウト値の指定方法がそれぞれ異なる：wait()、wait(long timeout)、wait(long timeout, int nanos)の三つである。一つ目のメソッドはタイムアウト値が0であり、これはタイムアウトが発生しないことを意味する。二つ目のメソッドはミリ秒単位のタイムアウト値を取る。三つ目のメソッドはナノ秒単位のタイムアウト値を取り、これは1000000 * timeout + nanosとして計算される。
waitを呼んだスレッドは待機状態となり、そのオブジェクトの待ちリストに追加される。そのスレッドは以下の三つのイベントのいずれか一つが起きるまで、オブジェクトの待ちリスト上に留まる：
別のスレッドがそのオブジェクトのnotifyまたはnotifyAllメソッドを呼ぶ (詳細はnotifyメソッド参照）
別のスレッドがそのスレッドのinterrupt()メソッドを呼ぶ
waitにて指定した0でないタイムアウト値が満了する
waitメソッドは、そのオブジェクトについての同期(synchronized)ブロックまたは同期(synchronized)メソッドの内部からのみ呼ばねばならない。これはwaitとnotifyとの間で競合を起こさないためである。スレッドが待ちリストに入るとき、そのスレッドはそのオブジェクトのミューテックス排他を解除する。そのスレッドが待ちリストから削除され実行可能スレッドとなった際に、そのスレッドは走行を再開するのに先立ってそのオブジェクトのミューテックスを改めて排他しなければならない。
オブジェクト > Objectクラスのメソッド > waitとnotifyスレッドシグナルメソッド > notifyとnotifyAllメソッド

Object.notify() と Object.notifyAll() メソッドはオブジェクトの待ちリストから一つ以上のスレッドを削除し、それらを実行可能スレッドとする。notifyは待ちリストから1スレッドのみ削除し、notifyAllは待ちリストから全てのスレッドを削除する。notifyがどのスレッドをリストから削除するかは規定されておらず、JVMの実装に依存する。
notifyとnotifyAllメソッドは、そのオブジェクトについての同期(synchronized)ブロックまたは同期(synchronized)メソッドの内部からのみ呼ばねばならない。これはwaitとnotifyとの間で競合を起こさないためである。
アノテーション

Javaのアノテーションはクラスやインタフェース、メソッドやフィールド、パッケージなどに対してメタデータとして付加情報を記入する機能で、Java SE 5 で追加された。
アノテーションはjava.lang.annotation.Annotationインタフェースを実装することで自作することもできる。
Javaのアノテーションは三つに分けることができる。
マーカー・アノテーション – データが無く名前だけを持つアノテーション。
単一値アノテーション – データを一つだけ持つアノテーション。見かけはメソッド呼び出しに似ている。
フル・アノテーション – 複数のデータを持つアノテーション。
アノテーション > Java標準APIの主なアノテーション

@Deprecated – 対象となるクラスやメソッドが非推奨であることを情報として付加する。
@Override – そのメソッドがスーパークラスのメソッドをオーバーライドしていることを示す。
@SuppressWarnings – 引数で指定した特定の警告メッセージをJavaコンパイラに与えず無視する。
@Target – 定義したいアノテーションがどこに適用されるべきかを指し示すメタアノテーション。
@Retention – アノテーションの配置方法を設定するメタアノテーション。
アノテーション > アノテーションを使用する > マーカーアノテーション

クラスやメソッドにマーカーアノテーションを付加するには以下のようクラスやメソッドの接頭辞に最低一つ以上のスペースまたは改行コードを入れて修飾子のように記述する。
この例は、クラスに非推奨、メソッドに、スーパークラスからのメソッドをオーバーライドしていることを意味するマーカーアノテーションを付加している例である。
@Deprecated class DeprecatedClass {
    @Override public boolean equals(Object obj) {
        return this == obj;
    }
}
アノテーション > アノテーションを使用する > 単一値アノテーション

単一値アノテーションを付加するには以下のようにする。
この例は、Serializableインタフェースを実装したクラスのフィールドにstatic finalなserialVersionUIDが宣言されていないという警告を無視するアノテーションを付加していることを意味する。
@SuppressWarnings(value = {"serial"})
class NoSerialVersionIDClass implements java.io.Serializable { }
これは、以下のような書き方もできる。これは単一値アノテーション@SuppressWarningsがvalue()メソッドを一つしか持たないことがわかっているためvalue = を省略できることを意味する。
@SuppressWarnings("serial")
class NoSerialVersionIDClass implements java.io.Serializable { }
このアノテーションは、戻り値の型がString[]になっているため同じvalue値であっても以下のように複数指定することができる。以下のように指定することで、シリアルバージョンIDが設定されていない警告と、コレクションで総称型による型チェックを行われていないことによって生ずる警告を無視することができる。 "unchecked"はメソッドに対してのみ設定することもできる。
@SuppressWarnings("serial", "unchecked")
class NoSerialVersionIDClass implements java.io.Serializable {
    public void setupList() {
        List list = new ArrayList();
        list.add("abcdef");
    }
}
このアノテーションは正確に記述すると以下のようにString[]配列の初期化宣言のようになる。
@SuppressWarnings(value = {"serial", "unchecked"})
アノテーション > アノテーションを使用する > フルアノテーション

フルアノテーションは、複数のデータ型を持つアノテーションである。ここでは自作したアノテーション @MyAnnotation があるとき、以下のように、変数名 = 値の形をカンマで区切って記述する。各値の記法は、各アノテーションで定義されているメソッドの戻り値の型で決まる。たとえばこの場合valueという変数名はStringを戻り型にとる value() というメソッドと、int を戻り型にとる version() というメソッドを持つ。フルアノテーションの場合は、default によりデフォルト値が設定されているアノテーション以外は、value = や version = を省略することはできない。
@MyAnnotation(value = "abc", version = 2)
class AnnotatedClass { }
アノテーション > アノテーションを定義する

アノテーションを定義するには、interfaceキーワードの接頭辞に@をつけて定義する。
アノテーション > アノテーションを定義する > マーカーアノテーション

マーカーアノテーションは以下のように定義する。メソッドやフィールドが一切ないマーカーインタフェースのアノテーション版ともいえる。@Overrideや@Deprecatedがこれらのアノテーションに相当する。
public @interface MarkerAnnotation { }
アノテーション > アノテーションを定義する > 単一値アノテーション

単一値アノテーションは以下のように定義する。このアノテーションには少なくともメソッドがひとつだけ定義されている。単一値アノテーションのメソッド名にはvalueという名前をつけるのが儀礼である。
@interface Single {
    String value();
}
アノテーション > アノテーションを定義する > フルアノテーション

フルアノテーションは以下のように定義する。以下のように二つ以上のメソッドを定義する。
@interface FullAnnotation {
    String value();
    int id();
}
アノテーション > メタアノテーション

メタアノテーションとは、定義しているアノテーションのみにつけられるアノテーションのことである。メタアノテーションの例としては@Targetや@Retention、@Documented、@Inheritedがあり、これらはクラスやメソッドなどには使うことができず、アノテーションのみに使うことができる。アノテーションを定義するために使われるアノテーションということから、メタアノテーションと呼ばれる。
アノテーション > メタアノテーションを使用する

メタアノテーションを使ってアノテーションを定義するには、以下のように記述する。
@Retention(RetentionPolicy.SOURCE)
@Target({ElementType.ANNOTATION_TYPE, ElementType.METHOD})
public @interface NewAnnotation {
}
このとき、@Retentionは、新たにアノテーション NewAnnotation を作るとき、このアノテーション情報はソースコードのみにしか保存されないことを意味する。@Targetはこのアノテーションをどの型に使うことができるかを指定している。この場合、ANNOTATION_TYPE と METHOD を指定しているのでこのアノテーションはアノテーション型とメソッドにしか使うことができない。つまり、この NewAnnotation もまた、メソッドだけでなくアノテーションにも保存できるため、メタアノテーションとしても使えることを示している。
アノテーション > @Retention

メタアノテーション@Retentionには以下のRetentionPolicy列挙型を設定することができる。
| RetentionPolicy 名 | 説明 |
| --- | --- |
RetentionPolicy.CLASS: アノテーション情報はコンパイル時に保存されるが実行時にはJava仮想マシンによって保持されない。
RetentionPolicy.RUNTIME: アノテーション情報はコンパイル時に保存され、実行時にもJava仮想マシンによって保持される。
RetentionPolicy.SOURCE: アノテーション情報はコンパイル時に破棄される。ソースコード内のみで有効。
アノテーション > @Target

メタアノテーション@Targetには以下のElementType列挙型を設定することができる。これは配列を使って
@Target({ElementType.METHOD, ElementType.FIELD, ElementType.TYPE})
と複数指定することができる。ただし、同じ値を { … } 内で複数使用するとエラーとなる。これによって型を指定することで、そのアノテーションが、どの型に対して使うことができるのかを指定できる。
| ElementType 名 | 説明 |
| --- | --- |
ElementType.ANNOTATION_TYPE: アノテーション型に指定できることを示す。
ElementType.CONSTRUCTOR: コンストラクタに指定できることを示す。
ElementType.LOCAL_VARIABLE: ローカル変数に指定できることを示す。
ElementType.FIELD: フィールドに指定できることを示す。
ElementType.METHOD: メソッドに指定できることを示す。
ElementType.PACKAGE: パッケージに指定できることを示す。
ElementType.PARAMETER: メソッド引数に指定できることを示す。
ElementType.TYPE: クラス、またはインタフェース（アノテーション型を含む）、列挙型に指定できることを示す。
入出力

J2SE1.4よりも前のバージョンのJavaはストリーム・ベースのブロッキングI/Oのみをサポートしていた。これは1ストリームにつき1スレッドを必要とした。何故ならストリームの入力または出力を行おうとすると、それが完了するまでそのスレッドは完全に待ちに入ってしまい、他の処理がいっさい行えなくなったからである。これは、Javaを用いたネットワークサービスを構築する上で、スケーラビリティと性能双方の面で大きな問題となっていた。J2SE1.4以降では非ブロッキングI/OフレームワークとしてNIO (New I/O) が導入され、このスケーラビリティ問題は修正された (ただし、サンによるNIO APIの実装にはまだ多くの問題点がある)。
非ブロッキングIOフレームワークは、以前のブロッキングIOフレームワークより遥かに複雑ではあるが、一つのスレッドで任意の数の"チャネル"を扱うことができる。このフレームワークはReactorパターンをベースとしている。
実行コード > アプリケーション

(ウェブブラウザではなく) スタンドアロン仮想マシンで実行されるJavaコード
mainメソッドは以下のように定義されなければならない:
public class MyClass {
    public static void main(String[] args) {...}
    ...
}
実行コード > アプレット

詳細は「Javaアプレット」を参照
ウェブブラウザで明示された表示領域上で実行されるJavaコード。
initとdestroyは一度だけ呼ばれるが、startとstopはユーザがウェブページを訪問するたびに何回も呼ばれる。
// MyApplet.java

import java.applet.*;

public class MyApplet extends Applet {
    init() {...}     // ブラウザが最初にアプレットを読み込むときに呼ばれる。
    destroy() {...}  // ユーザがブラウザを終了するときに呼ばれる。
    start(){...}     // アプレットを実行し始めるときに呼ばれる。
    stop() {...}     // ユーザがウェブページを去るとき、再読込するとき、
                     // ブラウザを終了するときに呼ばれる。
}
<applet code="MyApplet" width="200" height="200">
</applet>
実行コード > アプレット > appletタグの埋め込み

HTMLのappletタグをアプレットのソースコードに埋め込むことができる。
appletタグを書くと、そのアプレットは.htmlファイル無しでも、簡易アプレットビューアによって直接実行可能となる。
典型的には、appletタグはimport文の直後に書かれる。
appletタグは/* */コメントによって囲まれていなければならない。
// MyApplet.java
...
/*
<applet code="MyApplet" width="200" height="200">
</applet> 
*/
...
実行コード > サーブレット

詳細は「Java Servlet」を参照
Webサーバ上で実行されるJavaコードであり、その出力 (一般的にHTMLやXML) は典型的にはウェブブラウザに対して送信される。
実行コード > JSP (JavaServer Pages)

詳細は「JavaServer Pages」を参照
ウェブページにJavaコードを埋め込む形態。
JSPタグはウェブサーバで処理され、出力結果 (一般的にHTMLやXML) はクライアントに送信される。
JSPコードは実行される前にJava Servletにコンパイルされる。
JSPはJava Servletの拡張である。
JSPタグの使用法はPHPやASPのタグの使用方法と類似する。
実行コード > JSP (JavaServer Pages) > JSPタグ

| 文法 | 意味 |
| --- | --- |
<% Java構文 %>: スクリプトレット
<%= 単一Java構文の出力 %>: 構文
<%! Java宣言文 %>: 宣言
<%@ [page, include, taglib] JSPディレクティブ %>: ディレクティブ
その他 > ケースセンシティビティ (大文字小文字区別)

Javaはケースセンシティブ (大文字小文字を区別する) である。
その他 > コメント

コメントの文法はC++と同じである。
// 一行コメント

/* 複数行
   コメント */
なお、ドキュメンテーションコメントとしてJavadoc方式をサポートする。
/**
 * この行はクラス、インタフェース、メソッド、フィールド宣言の直前に記述する。
 * このコメントはクラスのドキュメントを自動生成する
 * ユーティリティで使用することができる。
 */
国設知床野営場

国設知床野営場
国設知床野営場（こくせつしれとこやえいじょう）は北海道斜里郡斜里町にあるキャンプ場。
概要

知床の観光拠点のひとつであるウトロの市街地から約1キロの高台にあり、知床八景のひとつとして知られる「夕陽台」、およびウトロ温泉街に隣接する。
野営場周辺はエゾマツ・トドマツなどの亜高山帯針葉樹、およびミズナラ・センノキ・ニレ・カンバなど落葉広葉樹の混在する針広混交林となっており、林野庁北海道森林管理局が管理する「知床森林スポーツ林」に含まれる。2008年（平成20年）には「知床の森林に関する情報発信」などを目的として「知床ボランティア活動施設」が開所。また、キャンプ利用が行われていない冬季には森歩き体験なども実施されている。
管理棟
キャビン
夕陽台からの眺望
野営場内で草を食むエゾシカ
利用

営業期間：6月1日～9月30日
定員：200名、テント60張、キャビン5棟（キャビンは要予約）
オートキャンプ不可
所在地

北海道斜里郡斜里町ウトロ香川
交通アクセス

斜里バスウトロターミナルから徒歩約20分、またはバス5分
My Tomorrow

「My Tomorrow」（マイ・トゥモロー）は、AiMの11枚目のシングル。
収録曲

My Tomorrow (4:28)
作詞:松木悠、作曲・編曲:大久保薫
「デジモンテイマーズ」EDテーマ(1 - 23話)。
ひまわり (3:56)
作詞:ai、作曲・編曲:樫原伸彦
「デジモンテイマーズ」挿入歌(24話)。
My Tomorrow (Original Karaoke) (4:28)
ひまわり (Original Karaoke) (3:54)
収録アルバム

デジモンテイマーズ シングルベストパレード (#1,2)
DIGIMON HISTORY 1999-2006 ALL THE BEST (#1)
デジモンエンディングベストエイマー (#1)
15 (#1)
ALL MY PARTS

『ALL MY PARTS』（オール・マイ・パーツ）は、GYROAXIAの配信限定シングル。2023年9月8日発売。
収録曲

ALL MY PARTS (4:19)
作詞：AG（NOISEMAKER）、作曲：HIDE（NOISEMAKER）、編曲：AG・HIDE（NOISEMAKER）
エピソード

全英詞の楽曲となっている。歌唱の際は楽曲提供をしたNOISEMAKERのメンバーが発音指導をした。
歌詞の内容は那由多の過去、傷など内面を描いている。
大分県竹工芸・訓練支援センター

大分県立竹工芸訓練センター（おおいたけんたけこうげい・くんれんセンター）（旧大分県竹工芸・訓練支援センター）は、大分県別府市にある職業能力開発促進法に基づく県立の職業能力開発校である。竹工芸の人材育成を行う。かつては介護サービス科も設置されていた。
概要

竹工芸の技術者育成、試験研究を行う公設試験研究機関として、1938年（昭和13年）に大分県によって設立された大分県工業試験場別府工芸指導所（1954年大分県別府産業工芸試験所に改称）が前身。
大分県竹工芸・訓練支援センターは、大分県立別府高等技術専門校との統合で発足した公共職業能力開発施設の一つで、経済産業大臣指定伝統的工芸品に指定された別府竹細工が伝わる大分県別府市に設けられた、日本で唯一の公立の竹工芸の教育・訓練機関である。
竹工芸科は、伝統的工芸品としての竹工芸に関する専門人材の育成を行い、全国の主だった産地へも多くの技術者を送り出している。
全国から入校希望者が集まり毎年募集定員を大きく超える。2013年度より訓練期間を延長して2年制となったが、定員は10名と半減しより狭き門となった。
その他に、県内外の竹加工等に関する技術相談に対応し、技術指導や企業単独での入手が困難な加工機械の貸し付けを行っている。2009年にはセンター内に竹工芸支援用のインキュベーション型貸し工房を開設して技術者の定着をはかっている。
2016年（平成28年）3月31日をもって介護サービス科が廃科となり、竹工芸科のみとなる。また、翌4月1日より施設の名称が変更され「 大分県立竹工芸訓練センター 」となる。
概要 > 学科

統一募集は毎年1月、入校時期は毎年4月。竹工芸科のみ高卒予定者を対象とした早期募集が毎年11月にある。
竹工芸科 - 訓練期間2年・定員12名（平成29年度に10名から12名に変更）
介護サービス科（2016年に廃科） - 訓練期間1年・定員30名
概要 > 所在地

大分県別府市東荘園3-3
沿革

1938年（昭和13年）1月 - 大分県工業試験場別府工芸指導所を別府市浜脇に設置。
1948年（昭和23年）4月 - 別府工芸指導所を大分県工業試験場から分離するとともに、大分県別府工芸指導所に改称。
1952年（昭和27年）5月 - 大分県別府工芸指導所を別府市秋葉通に新築移転。
1954年（昭和29年）4月 - 大分県別府工芸指導所を大分県別府産業工芸試験所に改称。
1963年（昭和38年）10月 - 大分県別府産業工芸試験所を別府市東荘園町に新築移転。
1994年（平成6年）4月 - 大分県工業試験場、別府産業工芸試験所、日田産業工芸試験所を統合して大分県産業科学技術センター発足。
2001年（平成13年）4月 - 大分県産業科学技術センターから別府産業工芸試験所を分離するとともに、大分県立別府高等技術専門校と統合し、大分県竹工芸・訓練支援センターとして発足。
2009年（平成21年） - 貸し工房「未来竹房 B-スクエア」開設。
2013年（平成25年）3月 - 中堅技術者養成指導課程が終了
2016年（平成28年）3月 - 介護サービス科が廃科。
2016年（平成28年）4月 - 「大分県立竹工芸訓練センター」へ名称が変更される。
柳街道

| --- | --- |
: この項目では、名古屋と佐屋街道を結んでいた街道について説明しています。岩倉街道の別名については「岩倉街道」をご覧ください。
柳街道（やなぎかいどう）は、名古屋と佐屋街道を結んでいた街道。
概要

東海道のバイパスとして開かれた佐屋街道は宮宿と佐屋宿を結んでいたが、佐屋街道の佐屋側から名古屋城下町にアクセスするためには、一旦南に遠回りする形になる。この短絡路として成立したのが柳街道であるという。岩塚宿にほど近い烏森から米野・牧野を通り、禰宜町を経て、納屋橋で堀切筋（広小路通）に接続するというルートを取っていた。総延長は1里（約4キロメートル）強であったという。また、ルートが複雑で、多くのカーブが存在したことから、百曲街道の別名もあった。区画整理により一部区間が廃道となっており、全線を追うことはできない。
名称の由来

街道名の由来には複数説があるという。有力な説としては、当地の地名である「一楊」（いちやなぎ）に由来するという説がある。また、1つは街道の両脇に柳の木があったことによるという説、1つは納屋橋付近に柳の木が多かったという説がある。
佐屋街道と名古屋城下町の位置関係
湘南新道

湘南新道（しょうなんしんどう）
一覧

神奈川県道30号戸塚茅ヶ崎線の通称。
神奈川県道44号伊勢原藤沢線別線の都市計画道路名。
振動準位

振動準位（しんどうじゅんい）は分子の重心の移動を伴わず、核の相対的な位置の変位にともなう運動を表す量子状態である。分子内において核は、結合する隣接核と結合エネルギーに相当するポテンシャルの井戸を形成し、お互いばねで結ばれた様な状態にあるために、上記のような運動は振動運動によって記述される（詳細は以下の章を参照）。振動準位間の遷移は振動遷移（しんどうせんい）と呼ばれ、主に赤外分光法またはラマン分光法によって観測される。
二原子分子の調和振動 > 古典論

二原子分子において2つの原子核の運動をばねによって結ばれた2つの粒子の調和振動子で近似する。2つの原子核が一直線上の位置 x1, x2 にあるとすると、フックの法則からそれぞれの核にはたらく力は
x はばねの変位（l0をばねに伸び縮みが無いときの長さとしたとき x = x2 − x1 − l0）、k はばね定数を表す。マイナス符号は、2つの核に反対向きの力が働くことを示す。
ここで換算質量 \mu を導入し、2つの核の相対運動を一方を固定した1つの粒子の運動で表す。
はじめの式を m1、2つ目の式を m2 で割り、2式を引いて整理すると
この運動のポテンシャルエネルギー U の位置についての微分は、粒子に働く力に負を乗じたものであるから、
これを積分するとポテンシャルエネルギーが得られる（ただし積分定数が０となるようにポテンシャルエネルギーの基準点をとった）。
これは伸び縮みのない状態を極小とした、二次関数である。分子のなかで核のまわりのポテンシャルは、極小点（平衡核間距離近傍）においては二次関数と近似できるので、調和振動子近似は、分子における核の相対運動を近似できると考えられる。
全エネルギー（ハミルトニアン）はこのポテンシャルエネルギーに運動エネルギーを加えたものであるから、次のように書ける。
二原子分子の調和振動 > 量子論

古典論から量子論に移るには、古典論のハミルトニアンに含まれる位置xを位置演算子 {\hat {x}}に、運動量pを運動量演算子 -i\hbar {\frac {\partial }{\partial x}}に置き換えればよい(正準量子化)。
この量子的なハミルトニアンの固有値問題を解くと、固有エネルギーは次のように得られる。
ただし \omega ={\sqrt {k/\mu }}。ここでn は振動の量子数と呼ばれる。分子振動を調和振動で近似すると、その量子的なエネルギーはn について等間隔なエネルギー準位となる。
振動遷移の選択律 > 量子論

量子力学における摂動論を用いて対称性を考えると、以下の様な選択律が得られる。
振動遷移の選択律 > 量子論 > 赤外吸収による遷移

振動量子数の変位  \Delta v=\pm 1
振動による双極子の変位が0で無い
赤外吸収により振動遷移が起こるためには、振動による双極子の変位が0で無いことが必要である。つまり、
ここで \mu は双極子モーメント、Qjはj番目の基準座標である。
振動遷移の選択律 > 量子論 > ラマン効果による遷移

振動量子数の変位  \Delta v=\pm 1
振動による分極率の変化が0でない
ここで \alpha は分極率、Qjはj番目の基準座標
振動遷移の選択律 > 群論

量子論から導かれる選択律は厳密なものであるが、群論の知識を使えば、より簡単に遷移が起きる振動を知ることができる。
まず適切な基底を導入し、振動をあらわす表現行列を作る。これは一般には可約表現の表現行列である。基底の選び方によっては、振動運動以外にも並進運動や回転運動も含まれている場合があり、これらは取り除く。表現行列の指標表を分子の対称性を表す点群の指標表を用いて既約表現へ分解する。
振動遷移の選択律 > 群論 > 赤外吸収

既約表現の指標表を見て、遷移モーメントがその点群において属する既約表現と同じであれば赤外光を吸収する。つまり指標表のｘ、ｙ、ｚが属する既約表現と同じであれば、その既約表現で表される振動は赤外線を吸収する。
振動遷移の選択律 > 群論 > ラマン効果

既約表現の指標表を見て、分極率がその点群において属する既約表現と同じであればラマン効果が起きる。つまり指標表のｘ2、ｙ2、ｚ2、ｘｙ、ｙｚ、ｚｘの一つもしくはｘ2-ｙ2が属する既約表現と同じであれば、その既約表現で表される振動はラマン効果が起きる。
調和振動ポテンシャルと実際の分子のポテンシャル

調和振動ポテンシャルは低いエネルギー（小さい量子数）の準位においてはよい近似ではある。しかし、実際の分子のポテンシャルは、原子間距離が小さくなる方向には原子間の排斥力により2乗の関数よりもさらに急激に上昇し、原子間距離が大きくなる方向では、緩やかであり、無限遠の極限においてはお互いに力を及ぼしあわなくなる。
以上のような違いから、実際の振動準位は、量子数が増えるにつれて準位間隔が狭くなっていき、遠距離の極限以上のエネルギー以上では量子化されない連続なエネルギー帯となっている。また、実際には振動量子数の変位  \Delta v=\pm 2 となる遷移も起こりうる。
これらの性質を非調和性と呼ぶ。
調和振動子よりも実際の分子のポテンシャルをモデル的に表すポテンシャルとしては、モースポテンシャルがよく知られる。