第6章 名前

宣言では、次のいずれかのエンティティがプログラムに導入されます。

コンストラクタ(§8.8、§8.10.4)も宣言によって導入されますが、新しい名前を導入するのではなく、宣言されているクラスの名前を使用します。

宣言には一般的に、宣言された実体を参照するために名前で使用できる識別子(§3.8)が含まれています。 この識別子には、導入されるエンティティがクラス、インタフェースまたは型パラメータである場合は特定のコンテキスト・キーワードを回避するという制約があります。

宣言に識別子が含まれず、かわりにキーワード_ (アンダースコア)が含まれている場合、エンティティを名前で参照することはできません。 アンダースコアを使用して、次の種類のエンティティを宣言できます。

アンダースコアを使用して宣言されるローカル変数、例外パラメータまたはラムダ・パラメータは、それぞれ名前なしローカル変数、名前なし例外パラメータまたは名前なしラムダ・パラメータと呼ばれます。

汎用クラスまたはインタフェース(class C<T> ...またはinterface C<T> ...)の宣言では、Cという名前のクラスと一連の型(RAW型C、パラメータ化された型C<Foo>、パラメータ化された型C<Bar>など)が導入されています。

汎用性が重要でない場合に Cへの参照が発生し、次に非汎用コンテキストの1つとして識別された場合、Cへの参照はクラスまたはインタフェース Cを示します。 他のコンテキストでは、Cへの参照は、Cによって導入された型または型の一部を示します。

15種類の非汎用コンテキストは、次のとおりです。

最初の12個の非汎用コンテキストは、§6.5.1のTypeNameの最初の12個の構文コンテキストに対応します。 13番目の非汎用コンテキストでは、C.xなどの修飾ExpressionNameに、静的メンバー・アクセスを示すTypeName Cが含まれる場合があります。 これらの13のコンテキストでのTypeNameの一般的な使用は重要です。これは、これらのコンテキストに、型の最初より少ないクラスの使用が含まれていることを示しています。 一方、14番目と15番目の非汎用コンテキストでは、ClassTypeが使用され、throwsおよびcatch句では、フィールド宣言などに沿って、ファーストクラスの方法で型が使用されることを示します。 非汎用としてのこれら2つのコンテキストの特徴は、例外型をパラメータ化できないという事実によるものです(§8.1.2)。

ClassType本番では注釈が許可されるため、throws句またはcatch句での型の使用に注釈を付けることができますが、TypeName本番では注釈が許可されないため、単一型インポート宣言などの型の名前に注釈を付けることはできません。

命名規則

Java SE Platformのクラス・ライブラリは、できるかぎり下に示される規則に従って選択される名前を使用しようとします。 これらの規則によって、コードの読取りが容易になり、特定の種類の名前の競合を回避できます。

Javaプログラミング言語で作成されたすべてのプログラムでこれらの表記規則を使用することをお薦めします。 ただし、長期的な従来型の使用方法が指示を受けている場合は、これらの表記規則に従ってはなりません。 したがって、たとえば、クラスjava.lang.Mathのsinメソッドとcosメソッドには、数学的に従来型の名前がありますが、これらのメソッド名は、短く動詞ではないため、ここで提案する規則を省略しています。

パッケージ名およびモジュール名

プログラマは、広く配布されているパッケージに対して「一意のパッケージ名」を選択することで、同じ名前を持つ2つの公開されたパッケージの可能性を回避するステップを実行する必要があります。 これにより、パッケージを簡単かつ自動的にインストールし、カタログ化できます。 この項では、このような一意のパッケージ名の生成に関する推奨される規則を指定します。 Java SEプラットフォームの実装は、パッケージのセットをローカルおよび不定期のパッケージ名からここに記載された一意の名前形式に変換するための自動サポートを提供することをお薦めします。

一意のパッケージ名を使用しないと、競合するパッケージのいずれかの作成時点で、パッケージ名の競合が発生する可能性があります。 この場合、ユーザーやプログラマが解決するのが困難または不可能な状況が発生することがあります。 クラスClassLoaderおよびModuleLayerを使用して、パッケージに制約付き相互作用があるが、naïveプログラムに対して透過的な方法ではない場合に、同じ名前のパッケージを相互に分離できます。

oracle.comなどのインターネット・ドメイン名を持つ(または属する組織に属する)ことで、一意のパッケージ名を形成します。 次に、この名前(コンポーネントごとにコンポーネント)を元に戻して、この例ではcom.oracleを取得し、これをパッケージ名の接頭辞として使用します。これは、組織内で開発された規則を使用してパッケージ名をさらに管理します。 そのような規則により、パッケージ名の特定のコンポーネントがビジョン、部門、プロジェクト、マシン、またはログイン名であることを指定します。

com.nighthacks.scrabble.dictionary
org.openjdk.compiler.source.tree
net.jcip.annotations
edu.cmu.cs.bovik.cheese
gov.whitehouse.socks.mousefinder

一意のパッケージ名の最初のコンポーネントは、常にすべて小文字のASCII文字で記述され、com、edu、gov、mil、net、orgなどのトップ・レベルのドメイン名、またはISO Standard 3166で指定されている国を識別する英語の2文字のコードのいずれかである必要があります。

インターネット・ドメイン名が有効なパッケージ名でない場合もあります。 これらの状況に対処する場合の推奨される方法を次に示します:

モジュールの名前は、エクスポートされたパッケージのプリンシパル名に対応する必要があります。 モジュールにこのようなパッケージがない場合やレガシーの理由で、エクスポートされたパッケージのいずれかに対応していない名前が必要な場合、その名前は作成者が関連付けられているインターネット・ドメインで、逆転した形で開始する必要があります。

com.nighthacks.scrabble
org.openjdk.compiler
net.jcip.annotations

パッケージ名またはモジュール名の最初のコンポーネントは、識別子javaにしないでください。 識別子javaで始まるパッケージ名およびモジュール名は、Java SEプラットフォームのパッケージおよびモジュール用に予約されています。

パッケージまたはモジュールの名前は、パッケージまたはモジュールがインターネット上に格納されている場所を示すものではありません。 たとえば、edu.cmu.cs.bovik.cheeseという名前のパッケージは、必ずしもホストcmu.edu、cs.cmu.eduまたはbovik.cs.cmu.eduから取得できるとはかぎりません。 一意のパッケージ名およびモジュール名を生成するための推奨される規則は、パッケージ名およびモジュール名の別のレジストリを作成するかわりに、既存の広く知られている一意の名前レジストリの上にパッケージおよびモジュール命名規則をまとめる方法です。

クラス名とインタフェース名

クラスの名前は、過度に長くない説明的な名詞または名詞句にし、大文字と小文字を混在させ、各単語の先頭を大文字にする必要があります。

ClassLoader
ProcessBuilder
Thread
Dictionary
BufferedInputStream

同様に、インタフェースの名前は、過度に長くない短い説明的な名前にし、大文字と小文字を混在させ、各単語の先頭を大文字にする必要があります。 名前は、java.io.DataInputやjava.io.DataOutputなどの抽象スーパークラスであるかのようにインタフェースが使用される場合に適切な、わかりやすい名詞または名詞句にすることも、インタフェースRunnableおよびCloneableのように動作を記述する形容詞にすることもできます。

型変数名

型の変数名は、(単一文字(可能な場合))がまだ明白である必要があり、小文字は使用しないでください。 これにより、型パラメータと通常のクラスおよびインタフェースを簡単に区別できます。

コンテナ・クラスおよびインタフェースでは、要素タイプにEという名前を使用する必要があります。 マップでは、キーのタイプにK、値のタイプにVを使用する必要があります。 Xという名前は、任意の例外タイプに使用する必要があります。 Tは、型を区別するために型についてより具体的なものがない場合に使用します。 (一般的なメソッドの場合に使用します。)

任意の型を示す複数の型パラメータがある場合は、Sなどのアルファベットに隣接するTの文字を使用する必要があります。 または、数値添字(T1、T2など)を使用して、異なる型変数を区別することもできます。 この場合、同じプレフィクスを持つすべての変数をサブスクライブする必要があります。

汎用メソッドが汎用クラス内に表示される場合、混乱を避けるために、メソッドおよびクラスの型パラメータと同じ名前を使用しないことをお薦めします。 これは、ネストされた汎用クラスにも当てはまります。

public class HashSet<E> extends AbstractSet<E> { ... }
public class HashMap<K,V> extends AbstractMap<K,V> { ... }
public class ThreadLocal<T> { ... }
public interface Functor<T, X extends Throwable> {
    T eval() throws X;
}

型のパラメータが、前述のカテゴリのいずれにも影響しない場合、名前は単一の文字の範囲内でできるだけ意味があるものに選択する必要があります。 前述の名前(E、K、V、X、T)は、指定されたカテゴリに該当しない型パラメータには使用しないでください。

メソッド名

メソッド名は動詞または動詞のフレーズである必要があります。この場合、最初の文字は小文字に、以降の単語は大文字にした最初の文字は大文字にします。 メソッド名に関するその他の規則を次に示します:

可能で適切な場合は常に、既存のクラス(特にJava SE Platform APIからのクラス)の名前に基づいてメソッドの名前を作成しておくと、使いやすくなります。

フィールド名

final以外のフィールドの名前は、小文字の先頭文字と後続の単語の先頭文字を大文字にして、大文字と小文字を混在させる必要があります。 適切に設計されたクラスには、定数であるフィールド(static finalフィールド)を除き、publicまたはprotectedフィールドはほとんどないことに注意してください。

フィールドには、ナウン、名詞句または名詞の略語である名前を含める必要があります。

定数名

インタフェース内の定数の名前は、通常、クラスのfinal変数は、1つ以上の単語、頭字語または略語のシーケンスで、すべて大文字で、コンポーネントはアンダースコア_文字で区切ります。 定数名は説明的である必要があり、意味のない短縮は必要ありません。 品詞の適切な部分である場合もあります。

集合の代替値、または整数値の使用頻度の低いマスク・ビットを表す定数のグループは、名前のプレフィクスとして一般的な頭文字で完全に指定される場合があります。

interface ProcessStates {
    int PS_RUNNING   = 0;
    int PS_SUSPENDED = 1;
}

ローカル変数およびパラメータ名

ローカル変数名とパラメータ名は、短くて、わかりやすい名前にする必要があります。 通常、これらは小文字の短いシーケンスであり、次のような単語ではありません:

1文字のローカル変数またはパラメータ名は、一時変数およびループ変数以外、または変数がタイプの非識別値を保持している場合を除き、使用しないでください。 従来の1文字の名前は、次のとおりです:

2文字または3文字のみで構成されるローカル変数またはパラメータ名は、一意のパッケージ名の最初のコンポーネントである初期国コードおよびドメイン名と競合しないようにする必要があります。

nameは、プログラムで宣言されたエンティティを参照するために使用されます。

名前には、単純名と修飾名の2つの形式があります。

単純名は単一の識別子です。

修飾名は、名前、.トークンおよび識別子で構成されます。

名前の意味(§6.5)を決定する際には、その名前が表示されるコンテキストが考慮されます。 §6.5の規則は、パッケージ(§6.5.3)、クラス、インタフェース、または型パラメータ(§6.5.5)、式内の変数または値(§6.5.6)、またはメソッド(§6.5.7)を示す(参照する)必要があるコンテキストを区別します。

パッケージ、クラス、インタフェース、および型パラメータには、修飾名でアクセスできるメンバーがあります。 修飾名の説明と名前の意味の決定の背景として、§4.4、§4.5.2、§4.8、§4.9、§7.1、§8.2、§9.2および§10.7のメンバーシップの説明を参照してください。

プログラムのすべての識別子が名前の一部となるわけではありません。 識別子は、次の状況でも使用されます。

class Test {
    public static void main(String[] args) {
        Class c = System.out.getClass();
        System.out.println(c.toString().length() +
                           args[0].length() + args.length);
    }
}

このような式では、単純名ではなく識別子が使用されるのはなぜでしょうか。 その理由は、単純な式名が字句環境の観点から定義されているためです。つまり、単純な式名は変数宣言のスコープ内に存在する必要があります(§6.5.6.1)。 一方、フィールド・アクセス、修飾されたメソッド呼出し、メソッド参照および修飾されたクラス・インスタンスの作成はすべて、名前が字句環境にないメンバーを参照します。 定義上、このような名前は、フィールド・アクセス式、メソッド呼出し式、メソッド参照式またはクラス・インスタンス作成式のプライマリによって提供されるコンテキスト内、またはフィールド・アクセス式、メソッド呼出し式またはメソッド参照式のsuperなどによってのみバインドされます。 したがって、このようなメンバーを単純名ではなく識別子で示します。

さらに複雑化するため、フィールド・アクセス式は、オブジェクトのフィールドを示す唯一の方法ではありません。 解析の理由から、スコープ内変数のフィールドを示すために修飾名が使用されます。 (変数自体は単純名で示され、上に示されます。) アクセス制御(§6.6)は、フィールドの両方の単位に適用する必要があります。

宣言のスコープは、宣言によって宣言されたエンティティがシャドウ化されていない場合に、単純名を使用して参照できるプログラムの領域です(§6.4.1)。

宣言は、宣言のスコープにそのポイントが含まれている場合にのみ、プログラム内の特定のポイントでスコープ内であるとみなされます。

観測可能な最上位パッケージ(§7.4.3)の宣言の範囲は、パッケージが一意に見えるモジュール(§7.4.3)に関連付けられたすべての観測可能なコンパイル単位です。

監視できないパッケージの宣言はスコープ内にありません。

サブパッケージの宣言はスコープ内にありません。

パッケージjavaは常にスコープ内にあります。

Mサイズは箱入りとなりますSサイズは箱なしでのラッピングとなりますギフトボックス・ラッピングについて_______________________________________________§7.7)およびimport宣言が出現するコンパイル・ユニットのすべてのクラスおよびインタフェース宣言(§8.1、§9.1)、およびコンパイル・ユニットのモジュール宣言またはパッケージ宣言の注釈。

単一静的インポート宣言(§7.5.3)または静的インポート・オン・デマンド宣言(§7.5.4)によってインポートされるメンバーのスコープは、モジュール宣言であり、import宣言が出現するコンパイル・ユニットのすべてのクラスおよびインタフェース宣言、およびコンパイル・ユニットのモジュール宣言またはパッケージ宣言の注釈です。

通常のコンパイル単位で宣言された最上位のクラスまたはインタフェース(§7.6)のスコープは、最上位のクラスまたはインタフェースが宣言されているパッケージ内のすべてのクラスおよびインタフェース宣言です。

コンパクトコンパイル単位(§7.3)での最上位クラスの暗黙的宣言のスコープは空であり、クラスはスコープ内にありません。

クラスまたはインタフェースC(§8.2、§9.2)で宣言または継承されたメンバーmの宣言のスコープは、ネストされたクラスまたはインタフェース宣言を含むCの本体全体です。 Cがレコード・クラスである場合、mのスコープには、Cのレコード宣言のヘッダーが追加で含まれます。

メソッド(§8.4.1)、コンストラクタ(§8.8.1)、またはラムダ式(§15.27)の仮パラメータの範囲は、メソッド、コンストラクタまたはラムダ式の本体全体です。

クラスの型パラメータ(§8.1.2)のスコープは、クラス宣言の型パラメータ・セクション、クラス宣言のスーパークラス型またはスーパーインタフェース型の型パラメータ・セクション、およびクラス本体です。 クラスがレコード・クラス(§8.10)である場合、型パラメータのスコープにはレコード宣言のヘッダーも含まれます(§8.10.1)。

インタフェースの型パラメータの範囲(§9.1.2)は、インタフェース宣言の型パラメータ・セクション、インタフェース宣言のスーパーインタフェース型の型パラメータ・セクション、およびインタフェース本体です。

メソッドの型パラメータ(§8.4.4)のスコープは、型パラメータ・セクションを含むメソッドの宣言全体ですが、メソッド修飾子は除外されます。

コンストラクタの型パラメータ(§8.8.4)のスコープは、型パラメータ・セクションを含むコンストラクタの宣言全体ですが、コンストラクタ修飾子は除外されます。

ブロック(§14.2)によって直ちに囲まれたローカル・クラスまたはインタフェース宣言のスコープは、ローカル・クラスまたはインタフェース宣言自体を含む、直ちに包含されるブロックの残りです。

switchブロック文グループ(§14.11)によって直ちに囲まれたローカル・クラスまたはインタフェース宣言のスコープは、ローカル・クラスまたはインタフェース宣言自体を含む、直ちに囲むswitchブロック文グループの範囲です。

ローカル変数宣言文(§14.4.2)によってブロック内で宣言されたローカル変数のスコープは、宣言独自のイニシャライザから始まり、ローカル変数宣言文の右側にさらに宣言子を含めたブロックのrestです。

基本的なfor文(§14.14.1)のForInit部分で宣言されたローカル変数のスコープには、次のすべてが含まれます。

拡張for文のヘッダーで宣言されたローカル変数のスコープ(§14.14.2)は、含まれている文です。

try-with-resources文(§14.20.3)のリソース指定で宣言されたローカル変数のスコープは、リソース指定の残りの部分およびtry-with-resources文に関連付けられたtryブロック全体に対する宣言のものです。

try-with-resources文の変換は、前述のルールを意味します。

try文のcatch句(§14.20)で宣言されている例外ハンドラのパラメータのスコープは、catchに関連付けられたブロック全体です。

package points;
class Point {
    int x, y;
    PointList list;
    Point next;
}

class PointList {
    Point first;
}

class Test1 {
    static int x;
    public static void main(String[] args) {
        int x = x;
    }
}

class Test2 {
    static int x;
    public static void main(String[] args) {
        int x = (x=2)*2;
        System.out.println(x);
    }
}

4

class Test3 {
    public static void main(String[] args) {
        System.out.print("2+1=");
        int two = 2, three = two + 1;
        System.out.println(three);
    }
}

2+1=3

パターン変数宣言のスコープ(つまり、パターンによって宣言されたローカル変数)は、パターンに対する値の照合が成功した後に実行される可能性があるプログラムの一部です(§14.30.2)。 これは、パターン変数を宣言するパターンで始まる領域で、パターン変数が完全に一致するプログラム・ポイントを考慮して決定されます。

このセクションの残りの部分は、「絶対一致」という単語の正確な説明に捧げられています。 分析では、文と式の構造が考慮され、ブール式の演算子と特定の文のフォームに関する特別な処理が行われます。

パターン変数宣言のスコープは、明確な代入(§16 (Definite Assignment))に似たフロー依存の概念であることがわかります。 このセクションの最後に定義されたルールは、意図的に明確な割当てのルールと同様の形式です。

分析は、次の形式の「導入者」の技術用語に依存します。

最も簡単な例は、パターン変数sがtrueの場合に式a instanceof String sによって導入されることです。 つまり、式の値がtrueの場合、パターン一致は成功している必要があるため、パターン変数に値が割り当てられている必要があります。

対照的に、パターン変数tは、falseの場合、式!(b instanceof Integer t)によって導入されます。 これは、式の値がfalseの場合にのみパターン一致が成功できたためです。

Object o = ...
if (o instanceof String s)
    // s in scope for this substatement; no cast of o needed
    System.out.println(s.replace('*', '_'));
else
    // s not in scope for this substatement (hence, error)
    System.out.println(s);

void test(Object o) {
    if (!(o instanceof String s)) {
        throw new IllegalArgumentException();
    }
    // This point is only reachable if the pattern match succeeded
    // Thus, s is in scope for the rest of the block
    ...
    System.out.println(s.repeat(5));
    ...
}

if (e instanceof String s) {
    counter += s.length();
} else {
    System.out.println(e);  // s not in scope
}

if (!(e instanceof String s)) {
    System.out.println(e);  // s not in scope
} else {
    counter += s.length();
}

if (!!(e instanceof String s)) {
    counter += s.length();
} else {
    System.out.println(e);  // s not in scope
}

ローカル変数(§14.4)、仮パラメータ(§8.4.1、§8.8.1、§15.27.1)、例外パラメータ(§14.20)、ローカル・クラスまたはローカル・インタフェース(§14.3)は、修飾名(§6.2)ではなく単純名を使用してのみ参照できます。

ローカル変数宣言、仮パラメータ宣言、例外パラメータ宣言、ローカル・クラス宣言またはローカル・インタフェース宣言のスコープ内では、一部の宣言は許可されません。これは、単純名のみを使用して宣言されたエンティティを区別できないためです。

たとえば、メソッド本文の局所変数の名前として、メソッドの仮パラメータの名前を再宣言できる場合、局所変数によって仮パラメータがシャドウ化されますが、仮パラメータを参照する方法はありません - 望ましくない結果。

仮パラメータの名前を使用してメソッド、コンストラクタまたはラムダ式の本体内で新しい変数が宣言される場合、コンパイル時にエラーが発生します。ただし、この新しい変数が、メソッド、コンストラクタまたはラムダ式に含まれるクラスまたはインタフェース宣言で宣言される場合は除きます。

ローカル変数vの名前を使用してvのスコープ内で新しい変数を宣言する場合は、vのスコープ内に出現するクラスまたはインタフェース宣言内で新しい変数が宣言されていないかぎり、コンパイル時にエラーが発生します。

catch句のBlockに含まれるクラスまたはインタフェース宣言内で新しい変数が宣言されていないかぎり、catch句のBlock内で例外パラメータの名前を使用して新しい変数を宣言すると、コンパイル時にエラーが発生します。

ローカルクラスまたはインタフェース Cの名前を使用して Cのスコープ内で新しいローカルクラスまたはインタフェースを宣言する場合、コンパイル時にエラーが発生します。ただし、新しいローカルクラスまたはインタフェースが Cのスコープ内に出現するクラスまたはインタフェース宣言内で宣言されている場合を除きます。

これらのルールにより、変数、ローカル・クラスまたはローカル・インタフェースの範囲内で発生するネストされたクラスまたはインタフェース宣言内の変数、ローカル・クラスまたはローカル・インタフェースを再宣言できます。このようなネストされたクラスまたはインタフェース宣言は、ローカル・クラスまたはインタフェース宣言(§14.3)または匿名クラス宣言(§15.9.5)です。 したがって、仮パラメータ、ローカル変数、ローカル・クラスまたはローカル・インタフェースの宣言は、メソッド、コンストラクタまたはラムダ式内にネストされたクラスまたはインタフェース宣言でシャドウ化できます。また、例外パラメータの宣言は、catch句のブロック内にネストされたクラスまたはインタフェース宣言でシャドウ化できます。

ラムダ・パラメータで作成された名前宣言とラムダ式で宣言されたその他の変数を処理するには、2つの設計方法があります。 1つは、クラス宣言を模倣することです: ローカル・クラスのように、ラムダ式は名前の新しい"level"を導入し、式の外側にあるすべての変数名を再宣言できます。 また、catch句、forループおよびブロックと同様に、ラムダ式は包含コンテキストと同じレベルで動作し、式外のローカル変数はシャドウ化できません。 上記のルールはローカル戦略を使用します。ラムダ式で宣言された変数を、囲んでいるメソッドで宣言された変数のシャドウを作成できる特別な違反はありません。

class Test1 {
    public static void main(String[] args) {
        int i;
        for (int i = 0; i < 10; i++)
            System.out.println(i);
    }
}

class Test2 {
    public static void main(String[] args) {
        int i;
        class Local {
            {
                for (int i = 0; i < 10; i++)
                    System.out.println(i);
            }
        }
        new Local();
    }
}

class Test3 {
    public static void main(String[] args) {
        for (int i = 0; i < 10; i++)
            System.out.print(i + " ");
        for (int i = 10; i > 0; i--)
            System.out.print(i + " ");
        System.out.println();
    }
}

0 1 2 3 4 5 6 7 8 9 10 9 8 7 6 5 4 3 2 1

class Point {
    int x, y;
    Point(int x, int y) { this.x = x; this.y = y; }
}

class Test4 {
    static void test(Object a, Object b, Object c) {
        if (a instanceof Point p) {
            System.out.println("a is a point ("+p.x+","+p.y+")");
        }
        if (b instanceof Point p){
            System.out.println("b is a point ("+p.x+","+p.y+")");
        } else if (c instanceof Point p) {
            System.out.println("c is a point ("+p.x+","+p.y+")");
        }
    }

    public static void main(String[] args) {
        Point p = new Point(2,3);
        Point q = new Point(4,5);
        Point r = new Point(6,7);
        test(p, q, r);
    }
}

class Point {
    int x, y;
    Point(int x, int y) { this.x = x; this.y = y; }
}

class Test5 {
    static void test(Object a, Object b, Object c) {
        if (a instanceof Point p) {
            System.out.println("a is a point ("+p.x+","+p.y+")");

            if (b instanceof Point p) {  // compile-time error
                System.out.println("b is a point ("+p.x+","+p.y+")");
            }
        }
    }

    public static void main(String[] args) {
        Point p = new Point(2,3);
        Point q = new Point(4,5);
        Point r = new Point(6,7);
        test(p, q, r);

        if (new Object() instanceof Point q)  // compile-time error
            System.out.println("I get your point");
    }
}

class Test {
    static int x = 1;
    public static void main(String[] args) {
        int x = 0;
        System.out.print("x=" + x);
        System.out.println(", Test.x=" + Test.x);
    }
}

x=0, Test.x=1

class Pair {
    Object first, second;
    public Pair(Object first, Object second) {
        this.first = first;
        this.second = second;
    }
}

import java.util.*;

class Vector {
    int[] val = { 1 , 2 };
}

class Test {
    public static void main(String[] args) {
        Vector v = new Vector();
        System.out.println(v.val[0]);
    }
}

1

名前の意味は、使用されるコンテキストに依存します。 名前の意味の決定には、次の3つのステップが必要です。

コンテキストの使用は、異なる種類のエンティティ間での名前の競合を最小化するために役立ちます。 このような競合は、§6.1に記載されている命名規則に従えばまれです。 それでも、別のプログラマや別の組織が開発した型が展開されると、意図せずに競合が発生する場合があります。 たとえば、型、メソッドおよびフィールドが同じ名前になる場合があります。 使用されるコンテキストから、メソッドを意図しているかどうかが常にわかるため、同じ名前のメソッドとフィールドを常に区別できます。

package org.rpgpoet;
import java.util.Random;
public interface Music { Random[] wizards = new Random[4]; }

package bazola;
class Gabriel {
    static int n = org.rpgpoet.Music.wizards.length;
}

org.rpgpoet.Music.wizards
org.rpgpoet.Music
org.rpgpoet
org

class Box<T> {
    T val;
    Box(T t) { val = t; }

    static Box<T> empty() {  // compile-time error
        return new Box<>(null);
    }

    static <U> Box<U> make(U val) {
        interface Checker {
            void check(U val);  // compile-time error
        }

        class NullChecker implements Checker {
            public void check(U val) {
                if (val == null) {
                    throw new IllegalArgumentException();
                }
            }
        }

        new NullChecker().check(val);
        return new Box<U>(val);
    }
}

class Test {
    public static void main(String[] args) {
        java.util.Date date =
            new java.util.Date(System.currentTimeMillis());
        System.out.println(date.toLocaleString());
    }
}

Sun Jan 21 22:56:29 1996

class Test {
    static int v;
    static final int f = 3;
    public static void main(String[] args) {
        int i;
        i = 1;
        v = 2;
        f = 33;  // compile-time error
        System.out.println(i + " " + v + " " + f);
    }
}

1 2 3

class Test {
    static String a;
    String b;

    String concat1() {
        return a + b;
    }

    static String concat2() {
        return a + b;  // compile-time error
    }

    int index() {
        interface I {
            class Matcher {
                void check() {
                    if (a == null ||
                        b == null) {  // compile-time error
                        throw new IllegalArgumentException();
                    }
                }
                int match(String s, String t) {
                    return s.indexOf(t);
                }
            }
        }

        I.Matcher matcher = new I.Matcher();
        matcher.check();
        return matcher.match(a, b);
    }
}

class Test {
    public static void main(String[] args) {
        String first = args[0];

        class Checker {
            void checkWhitespace(int x) {
                String arg = args[x];
                if (!arg.trim().equals(arg)) {
                    throw new IllegalArgumentException();
                }
            }

            static void checkFlag(int x) {
                String arg = args[x];  // compile-time error
                if (!arg.startsWith("-")) {
                    throw new IllegalArgumentException();
                }
            }

            static void checkFirst() {
                Runnable r = new Runnable() {
                    public void run() {
                        if (first == null) {  // compile-time error
                            throw new IllegalArgumentException();
                        }
                    }
                };
                r.run();
            }
        }

        final Checker c = new Checker();
        c.checkFirst();
        for (int i = 1; i < args.length; i++) {
            Runnable r = () -> {
                c.checkWhitespace(i);  // compile-time error
                c.checkFlag(i);  // compile-time error
            };
        }
    }
}

class Point {
    int x, y;
    static int nPoints;
}

class Test {
    public static void main(String[] args) {
        int i = 0;
        i.x++;        // compile-time error
        Point p = new Point();
        p.nPoints();  // compile-time error
    }
}

class Foo<T> {
    public static int classVar = 42;
}

Foo<String>.classVar = 91; // illegal

Foo.classVar = 91;

class Super {
    void f2(String s)       {}
    void f3(String s)       {}
    void f3(int i1, int i2) {}
}

class Test {
    void f1(int i) {}
    void f2(int i) {}
    void f3(int i) {}

    void m() {
        new Super() {
            {
                f1(0);  // OK, resolves to Test.f1(int)
                f2(0);  // compile-time error
                f3(0);  // compile-time error
            }
        };
    }
}

Javaプログラミング言語は、アクセス制御のメカニズムを提供し、パッケージまたはクラスのユーザーが、そのパッケージまたはクラスの実装の不要な詳細に依存しないようにします。 アクセスが許可されている場合、アクセスされたエンティティはアクセス可能であるとみなされます。

アクセス可能性は、コンパイル時に判断される静的プロパティです。これは、型および宣言の修飾子にのみ依存します。

修飾名は、パッケージ、クラス、インタフェース、型パラメータおよび参照型のメンバーにアクセスする手段です。 このようなメンバーの名前がコンテキスト(§6.5.1)から修飾型名(パッケージ、クラス、インタフェースまたは型パラメータのメンバーを示す)または修飾式名(参照型のメンバーを示す)として分類される場合、アクセス制御が適用されます。

たとえば、単一型インポート宣言では修飾型名(§7.5.1)が使用されるため、import宣言を含むコンパイル・ユニットから名前付きクラスまたはインタフェースにアクセスできる必要があります。 別の例として、クラス宣言ではスーパークラス型(§8.1.5)の修飾型名が使用される可能性があるため、名前付きクラスにはアクセス可能である必要があります。

いくつかの明らかな式は、§6.5.1のコンテキスト分類から「欠落」しています: Primaryでのフィールド・アクセス(§15.11.1)、Primaryでのメソッド呼出し(§15.12)、Primaryを介したメソッド参照(§15.13)、および修飾クラス・インスタンス作成でのインスタンス化されたクラス(§15.9)。 これらの各式は、§6.2の理由により、名前ではなく識別子を使用します。 したがって、メンバー(フィールド、メソッド、クラスまたはインタフェース)に対するアクセス制御は、フィールド・アクセス式、メソッド呼出し式、メソッド参照式および修飾クラス・インスタンス作成式によって明示的に適用されます。 (フィールドに対するアクセスは、接尾辞式として出現する修飾名で示される場合もあります。)

また、多くの文および式では、型名のみで表現されない型を使用できます。 たとえば、クラス宣言では、パラメータ化された型(§4.5)を使用してスーパークラス型を示すことができます。 パラメータ化された型は修飾された型名ではないため、クラス宣言では、示されたスーパークラスに対してアクセス制御を明示的に実行する必要があります。 したがって、§6.5.1でTypeNameを分類するためのコンテキストを提供する文および式のほとんどは、独自のアクセス制御チェックを実行します。

パッケージ、クラス、インタフェースまたは型パラメータのメンバーにアクセスする以外に、クラスのコンストラクタへのアクセスの問題があります。 コンストラクタが明示的または暗黙的に呼び出されたときに、アクセス制御をチェックする必要があります。 したがって、アクセス制御は、コンストラクタ呼出し(§8.8.7.1)およびクラス・インスタンス作成式(§15.9.3)によってチェックされます。 このようなチェックが必要となるのは、§6.5.1には、(名前ではなく、間接的にコンストラクタを参照する)コンストラクタ呼出しの記述がなく、修飾されていないクラス・インスタンス作成式によって示されるクラスと、そのクラスのコンストラクタの違いが認識されないためです。 また、コンストラクタには修飾名がないため、修飾された型名の分類中にチェックされたアクセス制御を信頼することはできません。

アクセシビリティは、非表示およびメソッドのオーバーライド(§8.4.8.1)を含む、クラス・メンバーの継承(§8.2)に影響します。

package points;
class PointVec { Point[] vec; }

package points;
public class Point {
    protected int x, y;
    public void move(int dx, int dy) { x += dx; y += dy; }
    public int getX() { return x; }
    public int getY() { return y; }
}

package points;
public class Point {
    int x, y;
    public void move(int dx, int dy) {
        x += dx; y += dy;
        moves++;
    }
    public static int moves = 0;
}

package points;
public class Point {
    public int x, y;
    public void move(int dx, int dy) { x += dx; y += dy; }
}
class PointList {
    Point next, prev;
}

package pointsUser;
class Test1 {
    public static void main(String[] args) {
        points.Point p = new points.Point();
        System.out.println(p.x + " " + p.y);
    }
}

package pointsUser;
import points.Point;
class Test2 {
    public static void main(String[] args) {
        Point p = new Point();
        System.out.println(p.x + " " + p.y);
    }
}

package points;
public class Point {
    public int x, y;
    void move(int dx, int dy) { x += dx; y += dy; }
    public void moveAlso(int dx, int dy) { move(dx, dy); }
}

package morepoints;
public class PlusPoint extends points.Point {
    public void move(int dx, int dy) {
        super.move(dx, dy);  // compile-time error
        moveAlso(dx, dy);
    }
}

import points.Point;
import morepoints.PlusPoint;
class Test {
    public static void main(String[] args) {
        PlusPoint pp = new PlusPoint();
        pp.move(1, 1);
    }
}

class Point {
    Point() { setMasterID(); }
    int x, y;
    private int ID;
    private static int masterID = 0;
    private void setMasterID() { ID = masterID++; }
}

package points;
public class Point {
    protected int x, y;
    void warp(threePoint.Point3d a) {
        if (a.z > 0)  // compile-time error: cannot access a.z
            a.delta(this);
    }
}

package threePoint;
import points.Point;
public class Point3d extends Point {
    protected int z;
    public void delta(Point p) {
        p.x += this.x;  // compile-time error: cannot access p.x
        p.y += this.y;  // compile-time error: cannot access p.y
    }
    public void delta3d(Point3d q) {
        q.x += this.x;
        q.y += this.y;
        q.z += this.z;
    }
}

すべてのプリミティブ型、名前付きパッケージ、トップ・レベル・クラスおよびトップ・レベル・インタフェースには、完全修飾名があります。

各メンバー・クラス、メンバー・インタフェースおよび配列型には、完全修飾名がある可能性があります。

ローカル・クラス、ローカル・インタフェース、または匿名クラスに完全修飾名は付けられません。

すべてのプリミティブ型(名前付きパッケージ、トップ・レベル・クラスおよびトップ・レベル・インタフェース)には、正規名があります。

各メンバー・クラス、メンバー・インタフェースおよび配列型は、正規名を持つ可能性があります。

ローカル・クラス、ローカル・インタフェース、または匿名クラスに正規名はありません。

package points;
class Point    { int x, y; }
class PointVec { Point[] vec; }

package p;
class O1 { class I {} }
class O2 extends O1 {}