第7章 パッケージとモジュール

通常のコンパイル・ユニットのパッケージ宣言は、コンパイル・ユニットが属するパッケージの名前(§6.2)を指定します。

package宣言に記載されているパッケージ名は、パッケージの完全修飾名(§6.7)である必要があります。

パッケージ宣言のスコープとシャドウ化は、§6.3および §6.4で規定されています。

パッケージ宣言の注釈修飾子に関する規則は、§9.7.4および§9.7.5で指定されています。

指定されたパッケージには、注釈付きpackage宣言が最大1つ許可されます。

この制限を適用する方法は、実装によって異なります。 ファイルシステムベースの実装では、次のスキームを強くお薦めします。package宣言が存在する場合は、package-info.javaというソース・ファイルに、パッケージのソース・ファイルを含むディレクトリに配置します。 このファイルには、package-infoというクラスのソースは含まれていません。package-infoは有効な識別子ではないため、実際にはそうすることは不正です。 通常、package-info.javaにはpackage宣言のみが含まれ、パッケージ上の注釈が直前に付きます。 パッケージ・アクセスを持つ1つ以上のクラスのソース・コードがファイルに技術的に含まれている可能性がありますが、非常に不適切な形式になります。

package-info.javaが存在する場合は、javadocおよびその他の類似のドキュメント生成システムに対してpackage.htmlのかわりにpackage-info.javaを使用することをお薦めします。 このファイルが存在する場合、ドキュメント生成ツールでは、package-info.javaのpackage宣言の直前のパッケージ・ドキュメント・コメントを検索する必要があります。 このようにして、package-info.javaはパッケージ・レベルの注釈およびドキュメントの唯一のリポジトリになります。 将来、ほかのパッケージレベルの情報を追加することが望ましい場合、このファイルはこの情報に便利なホームであることが証明されるはずです。

コンパクト・コンパイル・ユニット、またはpackage宣言を持たないが、少なくとも1つの他の種類の宣言を持つ通常のコンパイル・ユニットは、名前のないパッケージの一部です。

名前のないパッケージは、Java SEプラットフォームによって主に、小規模または一時アプリケーションの開発時または開発開始時に便宜上提供されます。

名前のないパッケージにはサブパッケージを含めることはできません。package宣言の構文には、常に名前付きの最上位パッケージへの参照が含まれているためです。

Java SEプラットフォームの実装では、少なくとも1つの名前のないパッケージをサポートする必要があります。 実装では、複数の名前のないパッケージをサポートできますが、必須ではありません。 名前のない各パッケージ内の通常のコンパイル・ユニットは、ホスト・システムによって判断されます。

ホストシステムは、無名パッケージ内の通常のコンパイルユニットを、名前付きモジュールではなく無名モジュール(§7.7.5)に関連付ける必要があります。

class FirstCall {
    public static void main(String[] args) {
        System.out.println("Mr. Watson, come here. "
                           + "I want you.");
    }
}

パッケージの格納に階層ファイル・システムを使用するJava SEプラットフォームの実装では、一般的な戦略の1つは、名前のないパッケージを各ディレクトリに関連付けることです。一度に識別できる名前のないパッケージは1つのみで、つまり「現在の作業ディレクトリ」に関連付けられているパッケージです。 「現在の作業ディレクトリ」の正確な意味は、ホスト・システムによって異なります。

次のうち少なくとも1つに該当する場合にのみ、パッケージは監視可能です。

パッケージjava、java.langおよびjava.ioは常に監視可能です。

これは、前述のルールおよび監視可能なコンパイル・ユニットのルールから、次のように結論付けることができます。 事前定義済パッケージjava.langはクラスObjectを宣言するため、Objectのコンパイル・ユニットは常に監視可能です(§7.3)。 したがって、java.langパッケージは監視可能で、javaパッケージも監視可能です。 さらに、Objectは監視可能であるため、配列型Object[]は暗黙的に存在します。 そのスーパーインタフェースjava.io.Serializable (§10.1)も存在するため、java.ioパッケージは監視可能です。

パッケージの宣言を含む通常のコンパイル・ユニットがMから参照可能である場合のみ、パッケージはモジュールMから参照可能です。

パッケージの可視性は、パッケージが特定のモジュールにとって有用な方法で観察可能であることを意味します。 サブパッケージP.Qが観察可能であるため、パッケージPが観察可能であることを知ることは一般に有用ではありません。 たとえば、P.Qが(モジュールM1で)観察可能であり、P.Rが(モジュールM2で)観察可能であるとします。その後、Pは観察可能ですが、どこですか。 M1、M2、または両方で 質問は冗長です。M1のみを必要とするモジュールNのコンパイル時には、P.Qが観察可能であることは重要ですが、Pが観察可能であることは重要ではありません。

パッケージは、次のいずれかが保持されている場合にのみ、モジュールMから一意に参照できます。

単一タイプ・インポート宣言は、標準名を指定して単一のクラスまたはインタフェースをインポートし、単一タイプ・インポート宣言が表示されるコンパイル・ユニットのモジュール、クラスおよびインタフェース宣言の単純な名前で使用できるようにします。

TypeNameは、クラスまたはインタフェースの正規名(§6.7)である必要があります。

クラスまたはインタフェースは、名前付きパッケージのメンバー、または最も外側の字句で包含するクラスまたはインタフェース宣言(§8.1.3)が名前付きパッケージのメンバーであるクラスまたはインタフェースのメンバーである必要があります。そうでない場合、コンパイル時にエラーが発生します。

指定されたクラスまたはインタフェースにアクセスできない場合、コンパイル時にエラーが発生します(§6.6)。

同じコンパイル・ユニット内の2つの単一タイプ・インポート宣言が、同じ単純名を持つクラスまたはインタフェースをインポートしようとすると、2つのクラスまたはインタフェースが同じでないかぎり、コンパイル時にエラーが発生し、その場合は重複する宣言が無視されます。

単一型インポート宣言によってインポートされたクラスまたはインタフェースが、import宣言を含むコンパイル・ユニットで最上位のクラスまたはインタフェース(§7.6)として宣言されている場合、import宣言は無視されます。

単一型インポート宣言が単純名がxのクラスまたはインタフェースをインポートし、コンパイル・ユニットが単純名がxのトップ・レベル・クラスまたはインタフェースも宣言すると、コンパイル時にエラーが発生します。

コンパイル・ユニットに、単純名がxのクラスまたはインタフェースをインポートする単一型インポート宣言と、単純名がxのクラスまたはインタフェースをインポートする単一静的インポート宣言(§7.5.3)の両方が含まれている場合、2つのクラスまたはインタフェースが同じでないかぎりコンパイル時にエラーが発生し、その場合、重複する宣言は無視されます。

import java.util.Vector;

import java.util.Vector;
class Vector { Object[] vec; }

import java.util.Vector;
import myVector.Vector;

package myVector;
public class Vector { Object[] vec; }

import java.util;
class Test { util.Random generator; }
  // incorrect: compile-time error

package Vector;
public class Mosquito { int capacity; }

package strange;
import java.util.Vector;
import Vector.Mosquito;
class Test {
    public static void main(String[] args) {
        System.out.println(new Vector().getClass());
        System.out.println(new Mosquito().getClass());
    }
}

class java.util.Vector
class Vector.Mosquito

type-import-on-demand宣言を使用すると、名前付きパッケージ、クラスまたはインタフェースのアクセス可能なすべてのクラスおよびインタフェースを必要に応じてインポートできます。

PackageOrTypeNameは、パッケージ、クラスまたはインタフェースの正規名(§6.7)である必要があります。

PackageOrTypeNameがクラスまたはインタフェース(§6.5.4)を示す場合、そのクラスまたはインタフェースは、指定されたパッケージのメンバーであるか、クラスまたはインタフェース宣言(§8.1.3)が指定されたパッケージのメンバーであるクラスまたはインタフェースのメンバーであるか、コンパイル時にエラーが発生します。

指定されたパッケージが現在のモジュールに一意に見えない場合(§7.4.3)、または指定されたクラスまたはインタフェースにアクセスできない場合(§6.6)は、コンパイル時にエラーが発生します。

type-import-on-demand宣言で、java.langまたは現在のコンパイル・ユニットの名前付きパッケージに名前を付けるのはコンパイル時エラーではありません。 このような場合は、type-import-on-demand宣言は無視されます。

同じコンパイル・ユニット内の2つ以上のタイプ・インポート・オンデマンド宣言で、同じパッケージ、クラスまたはインタフェースに名前を付けることができます。 これらの宣言のいずれか以外はすべて重複しているとみなされ、その型が1回のみインポートされた場合と同じ結果になります。

コンパイル・ユニットに、同じクラスまたはインタフェースに名前を付ける型インポート・オンデマンド宣言と静的インポート・オンデマンド宣言(§7.5.4)の両方が含まれている場合、そのクラスまたはインタフェースのstaticメンバー・クラスおよびインタフェース(§8.5、§9.5)が1回のみインポートされるのと同じ効果があります。

import java.util.*;

単一静的インポート宣言は、クラスまたはインタフェースから、指定された単純名を持つアクセス可能なすべてのstaticメンバーをインポートします。 これにより、これらのstaticメンバーは、単一静的インポート宣言が出現するコンパイル・ユニットのモジュール、クラスおよびインタフェース宣言の単純な名前で使用できるようになります。

TypeNameは、クラスまたはインタフェースの正規名(§6.7)である必要があります。

クラスまたはインタフェースは、名前付きパッケージのメンバー、または最も外側の字句で包含するクラスまたはインタフェース宣言(§8.1.3)が名前付きパッケージのメンバーであるクラスまたはインタフェースのメンバーである必要があります。そうでない場合、コンパイル時にエラーが発生します。

指定されたクラスまたはインタフェースにアクセスできない場合、コンパイル時にエラーが発生します(§6.6)。

識別子は、指定されたクラスまたはインタフェースの少なくとも1つのstaticメンバーに名前を付ける必要があります。 その名前のstaticメンバーがない場合、または名前付きのすべてのメンバーにアクセスできない場合は、コンパイル時にエラーが発生します。

1つの単一静的インポート宣言で、同じ名前を持つ複数のフィールド、クラスまたはインタフェース、あるいは同じ名前とシグネチャを持つ複数のメソッドをインポートできます。 このことが発生するのは、名前付きクラスまたはインタフェースが、すべて同じ名前を持つ複数のフィールド、メンバー・クラス、メンバー・インタフェースまたはメソッドをそれ自体のスーパー・タイプから継承する場合です。

同じコンパイル・ユニット内の2つの単一静的インポート宣言が同じ単純名のクラスまたはインタフェースをインポートしようとすると、コンパイル時にエラーが発生します。ただし、2つのクラスまたはインタフェースが同じである場合は除きます(この場合、重複する宣言は無視されます)。

単一静的インポート宣言が単純名がxのクラスまたはインタフェースをインポートし、コンパイル・ユニットが単純名がxのトップ・レベル・クラスまたはインタフェース(§7.6)も宣言すると、コンパイル時にエラーが発生します。

コンパイル・ユニットに、単純名がxのクラスまたはインタフェースをインポートするsingle-static-import宣言と、単純名がxのクラスまたはインタフェースをインポートするsingle-type-import宣言(§7.5.1)の両方が含まれている場合は、2つのクラスまたはインタフェースが同じでないかぎり、コンパイル時にエラーが発生します。この場合、重複する宣言は無視されます。

static-import-on-demand宣言を使用すると、指定されたクラスまたはインタフェースのすべてのアクセス可能なstaticメンバーを必要に応じてインポートできます。

TypeNameは、クラスまたはインタフェースの正規名(§6.7)である必要があります。

クラスまたはインタフェースは、名前付きパッケージのメンバー、または最も外側の字句で包含するクラスまたはインタフェース宣言(§8.1.3)が名前付きパッケージのメンバーであるクラスまたはインタフェースのメンバーである必要があります。そうでない場合、コンパイル時にエラーが発生します。

指定されたクラスまたはインタフェースにアクセスできない場合、コンパイル時にエラーが発生します(§6.6)。

同じコンパイル・ユニット内の2つ以上のオンデマンド静的インポート宣言によって、同じクラスまたはインタフェースの名前が指定されることがあります。この場合、そのような宣言が1つのみ存在する場合と同様の結果になります。

同じコンパイル・ユニットの2つ以上のstatic-import-on-demand宣言が同じメンバーを指定している場合があります。実際は、メンバーが1回だけインポートされた場合と同じです。

1つのstatic-import-on-demand宣言で、同じ名前の複数のフィールド、クラスまたはインタフェース、または同じ名前と署名を持つ複数のメソッドをインポートできます。 このことが発生するのは、名前付きクラスまたはインタフェースが、すべて同じ名前を持つ複数のフィールド、メンバー・クラス、メンバー・インタフェースまたはメソッドをそれ自体のスーパー・タイプから継承する場合です。

コンパイル・ユニットに、同じクラスまたはインタフェースに名前を付けるstatic-import-on-demand宣言とtype-import-on-demand宣言(§7.5.2)の両方が含まれている場合、そのクラスまたはインタフェースのstaticメンバー・クラスおよびインタフェース(§8.5、§9.5)が1回のみインポートされるのと同じ効果があります。

単一モジュール・インポート宣言を使用すると、指定したモジュールによってエクスポートされたパッケージのすべてのpublicトップ・レベル・クラスおよびインタフェースを必要に応じてインポートできます。

単一モジュール・インポート宣言では、次のパッケージのすべてのpublic最上位クラスおよびインタフェースがオンデマンドでインポートされます。

モジュールModuleNameが現在のモジュール(§7.3)によって読み取られない場合、コンパイル時にエラーが発生します。

現在のモジュールによって読み取られるモジュールは、java.lang.moduleパッケージ仕様部(§7.3)で説明されているように、解決の結果によって与えられます。

同じコンパイル・ユニット内の複数の単一モジュール・インポート宣言は、同じモジュールを指名できます。 これらの宣言は1つを除いてすべてが重複しているとみなされます。この結果、そのモジュールは1回のみインポートされたものとして扱われます。

単一モジュール・インポート宣言は、どのソース・ファイルでも使用できます。 ソース・ファイルはモジュールの一部にする必要はありません。 たとえば、モジュールjava.baseおよびjava.sqlは、標準のJavaランタイムの一部であるため、それ自体がモジュールとして開発されていないプログラムによってインポートできます。

パッケージをエクスポートしないモジュールのインポートが役立つ場合があります。 これは、モジュールがパッケージをエクスポートする別のモジュールを間接的に必要とすることがあるためです。 たとえば、java.seモジュールではパッケージはエクスポートされませんが、複数のモジュールがトランジティブに必要になるため、単一モジュール・インポート宣言import module java.se;の効果は、それらのモジュールによってエクスポートされたパッケージを再帰的にインポートすることです。

import module java.xml;

package q;
import module M1;   // What does this import?
class C { ... }

module M0 { requires M1; }

module M1 {
    exports p1;
    exports p2 to M0;
    exports p3 to M3;
    requires transitive M4;
    requires M5;
}

module M3 { ... }

module M4 { exports p10; }

module M5 { exports p11; }

import module java.sql;
module com.myDB.core {
    exports ...
    requires transitive java.sql;
    provides Driver with com.myDB.greatDriver;
}

import module M;
module M {
    ...
    exports p;
    ...
    uses C;
    ...
}

package p;
class C { ... }

module M2 {
    requires java.se;
    exports p2;
    ...
}

package p2;
import module java.xml;
class MyClass {
    ...
}

import module java.base;
import module java.desktop;

...
List l = ...        // Error - Ambiguous name!
...

import module java.desktop;

...
Element e = ...     // Error - Ambiguous name!
...

import module java.base;
import module java.desktop;

import java.util.List;  // Resolving the ambiguity
                        // of the simple name List

...
List l = ...            // Ok - List is resolved to
                        // java.util.List
...

requiresディレクティブは、現在のモジュールが依存しているモジュールの名前を指定します。

requiresディレクティブは、java.baseモジュールの宣言には指定しないでください。指定しないと、コンパイル時にエラーが発生します。これは、これが原始モジュールであり、依存性がないためです(§8.1.4)。

モジュールの宣言がjava.baseモジュールへの依存を表現せず、モジュール自体がjava.baseでない場合、モジュールは暗黙的にjava.baseモジュールへの依存性を宣言します。

requiresキーワードの後に修飾子transitiveを付けることができます。 これにより、現在のモジュールrequiresが、requires transitiveディレクティブで指定されたモジュールへの暗黙的に宣言された依存性を保持するモジュールが発生します。

requiresキーワードの後に修飾子staticを付けることができます。 これは、コンパイル時に依存関係が必須であるのに対し、実行時にはオプションであることを指定します。

requiresキーワードの後に同じ修飾子が複数回出現すると、コンパイル時にエラーが発生します。

モジュールの宣言がjava.baseモジュールへの依存を表現しており、そのモジュール自体がjava.baseではない場合、static修飾子がrequiresキーワードの後に出現すると、コンパイル時にエラーが発生します。

モジュール宣言内の複数のrequiresディレクティブで同じモジュール名が指定されている場合、コンパイル時にエラーが発生します。

現在のモジュールが唯一のルート・モジュールであるjava.lang.moduleパッケージ仕様部で説明されているように、解決がjava.lang.moduleパッケージ仕様部で説明されているいずれかの理由で失敗した場合、コンパイル時にエラーが発生します。

たとえば、requiresディレクティブで、監視できないモジュールを指定する場合、または現在のモジュールが直接的または間接的に自身への依存を表現する場合です。

解決が成功すると、結果によって、現在のモジュールによって読み取られるモジュールが指定されます。 現在のモジュールによって読み取られるモジュールによって、現在のモジュールから参照できる通常のコンパイル単位が決まります(§7.3)。 これらの通常のコンパイル単位で宣言された型(およびそれらの通常のコンパイル単位のみ)は、現在のモジュール(§6.6)のコードからアクセスできる場合があります。

Java SEプラットフォームでは、明示的に宣言された名前付きモジュール(モジュール宣言付き)と、暗黙的に宣言された名前付きモジュール(自動モジュール)が区別されます。 ただし、Javaプログラミング言語では区別されません。requiresディレクティブは、明示的に宣言されたか暗黙的に宣言されたかに関係なく、名前付きモジュールを参照します。

自動モジュールは移行に便利ですが、作成者が明示的に宣言されたモジュールに変換した場合、名前とエクスポートされたパッケージが変更される可能性があるという意味で信頼性がありません。 Javaコンパイラは、requiresディレクティブが自動モジュールを参照する場合に警告を発行することをお薦めします。 ディレクティブにtransitive修飾子が含まれている場合は、特に強力な警告が推奨されます。

module m.A {
    requires m.B;
}

module m.B {
    requires transitive m.C;
}

module m.C {
    requires transitive m.D;
}

module m.D {
    exports p;
}

package p;
public class Point {}

package client;
import p.Point;
public class Test {
    public static void main(String[] args) {
        System.out.println(new Point());
    }
}

javac --module-source-path . -d . --module m.D
javac --module-source-path . -d . --module m.C
javac --module-source-path . -d . --module m.B
javac --module-source-path . -d . --module m.A

java --module-path . --module m.A/client.Test

exportsディレクティブは、現在のモジュールによってエクスポートされるパッケージの名前を指定します。 他のモジュールのコードの場合、コンパイル時および実行時に、パッケージ内のpublicおよびprotected型、およびそれらの型のpublicおよびprotectedメンバー(§6.6)にアクセス権を付与します。 また、他のモジュールのコードに対して、これらのタイプおよびメンバーへのリフレクティブ・アクセス権を付与します。

opensディレクティブは、現在のモジュールによってオープンされるパッケージの名前を指定します。 他のモジュールのコードの場合、これは実行時に、コンパイル時にではなく、パッケージ内のpublicおよびprotected型、およびそれらの型のpublicおよびprotectedメンバーにアクセス権を付与します。 また、パッケージ内のすべてのタイプ、およびそのすべてのメンバーに、他のモジュールのコードに対するリフレクティブ・アクセス権を付与します。

exportsで指定されたパッケージが、現在のモジュール(§7.3)に関連付けられたコンパイル・ユニットによって宣言されていない場合、コンパイル時にエラーが発生します。

opensでは、現在のモジュールに関連付けられたコンパイル・ユニットによって宣言されていないパッケージを指定できます。 (パッケージが別のモジュールに関連付けられた監視可能なコンパイル・ユニットによって宣言される必要がある場合、opensディレクティブはその他のモジュールには影響しません。)

モジュール宣言内の複数のexportsディレクティブで同じパッケージ名が指定されている場合、コンパイル時にエラーが発生します。

モジュール宣言内の複数のopensディレクティブで同じパッケージ名が指定されている場合、コンパイル時にエラーが発生します。

オープン・モジュールの宣言にopensディレクティブが含まれている場合、コンパイル時にエラーが発生します。

exportsまたはopensディレクティブにto句がある場合、ディレクティブは修飾されます。それ以外の場合、非修飾です。 修飾ディレクティブの場合、パッケージ内のpublicおよびprotected型と、そのpublicおよびprotectedメンバーには、to句で指定されたモジュール内のコードに対してのみアクセスできます。 to句で指定されるモジュールは、現在のモジュールの友人と呼ばれます。 修飾されていないディレクティブの場合、これらの型とそのメンバーには、どのモジュール内のコードでもアクセスできます。

exportsまたはopensディレクティブのto句で、監視できないモジュールを指定することが許可されています(§7.7.6)。

特定のexportsディレクティブのto句で同じモジュール名が複数回指定されている場合、コンパイル時にエラーが発生します。

特定のopensディレクティブのto句で同じモジュール名が複数回指定されている場合、コンパイル時にエラーが発生します。

usesディレクティブは、現在のモジュール内のコードがjava.util.ServiceLoaderを介してプロバイダを検出できるサービスを指定します。

usesディレクティブがenumクラス(§8.9)を指定した場合、コンパイル時にエラーが発生します。

サービスは、現在のモジュールまたは別のモジュールで宣言できます。 サービスが現在のモジュールで宣言されていない場合、サービスは現在のモジュール内のコードに対してアクセス可能である必要があります(§6.6)。そうしないと、コンパイル時にエラーが発生します。

モジュール宣言内の複数のusesディレクティブで同じサービスが指定されている場合、コンパイル時にエラーが発生します。

providesディレクティブは、with句が1つ以上のサービス・プロバイダをjava.util.ServiceLoaderに指定するサービスを指定します。

providesディレクティブがenumクラス(§8.9)をサービスとして指定すると、コンパイル時にエラーが発生します。

サービスは、現在のモジュールまたは別のモジュールで宣言できます。 サービスが現在のモジュールで宣言されていない場合、サービスは現在のモジュール内のコードに対してアクセス可能である必要があります(§6.6)。そうしないと、コンパイル時にエラーが発生します。

すべてのサービス・プロバイダは、最上位レベルまたはstaticのいずれかのpublicクラスまたはインタフェースである必要があります。そうしないと、コンパイル時にエラーが発生します。

すべてのサービス・プロバイダを現在のモジュールで宣言する必要があります。そうしないと、コンパイル時にエラーが発生します。

サービス・プロバイダが仮パラメータのないpublicコンストラクタを明示的に宣言する場合、またはpublicデフォルト・コンストラクタを暗黙的に宣言する場合(§8.8.9)、そのコンストラクタはプロバイダ・コンストラクタと呼ばれます。

サービス・プロバイダが仮パラメータなしでproviderというpublic staticメソッドを明示的に宣言した場合、そのメソッドはプロバイダ・メソッドと呼ばれます。

サービス・プロバイダにプロバイダ・メソッドがある場合、その戻り型は、(i)現在のモジュールで宣言されるか、別のモジュールで宣言され、現在のモジュール内のコードからアクセス可能である、(ii)providesディレクティブで指定されたサービスのサブタイプである必要があり、そうでない場合はコンパイル時にエラーが発生します。

providesディレクティブで指定されたサービス・プロバイダは現在のモジュールで宣言する必要がありますが、そのプロバイダ・メソッドには、anotherモジュールで宣言された戻り型がある場合があります。 また、サービス・プロバイダがプロバイダ・メソッドを宣言する場合、サービス・プロバイダ自体がサービスのサブタイプである必要はありません。

サービス・プロバイダにプロバイダ・メソッドがない場合、そのサービス・プロバイダはプロバイダ・コンストラクタを持ち、providesディレクティブで指定されたサービスのサブタイプである必要があります。そうしないと、コンパイル時にエラーが発生します。

モジュール宣言内の複数のprovidesディレクティブで同じサービスが指定されている場合、コンパイル時にエラーが発生します。

特定のprovidesディレクティブのwith句で同じサービス・プロバイダが複数回指定されている場合、コンパイル時にエラーが発生します。

ホスト・システムが名前付きモジュール(§7.3)に関連付けない監視可能な通常のコンパイル・ユニットは、名前なしモジュールに関連付けられています。

名前のないモジュールは、Java SE 9より前に開発されたプログラムが名前付きモジュールを宣言できなかったことを認識して、Java SEプラットフォームによって提供されます。 また、名前のないパッケージを提供するJava SE Platformの理由(§7.4.2)は、主に名前のないモジュールに適用できます。

Java SEプラットフォームの実装では、1つ以上の名前のないモジュールをサポートする必要があります。 実装では、複数の名前のないモジュールがサポートされる場合がありますが、サポートする必要はありません。 各名前のないモジュールに関連付けられている通常のコンパイル単位は、ホストシステムによって決定されます。

ホストシステムは、名前付きパッケージ内の通常のコンパイルユニットを名前なしモジュールに関連付けることができます。

名前のないモジュールのルールは、次のように、名前付きモジュールとの相互運用性を最大化するように設計されています。

モジュールは、次のうち少なくとも1つに当てはまる場合に監視可能です。