フォルダ構造に基づいてJavaがそれを理解できないのはなぜですか?
パッケージへのマッピングは、ルート ソース フォルダーとその特定のファイルへのパスによって既に指定されているようです。
それは完全に結合されており、IDE なしでリファクタリングを行うのは非常に面倒です。そのファイルへの参照を更新するのはとにかく面倒ですが、ファイル レベルでパッケージを指定するのではなく、コンパイラによって少なくとも部分的に把握される可能性があります。
フォルダ構造に基づいてJavaがそれを理解できないのはなぜですか?
パッケージへのマッピングは、ルート ソース フォルダーとその特定のファイルへのパスによって既に指定されているようです。
それは完全に結合されており、IDE なしでリファクタリングを行うのは非常に面倒です。そのファイルへの参照を更新するのはとにかく面倒ですが、ファイル レベルでパッケージを指定するのではなく、コンパイラによって少なくとも部分的に把握される可能性があります。
JLS 7.2から
各ホスト システムは、パッケージとコンパイル ユニットの作成方法と保存方法を決定します。
また、各ホスト システムは、特定のコンパイルでどのコンパイル ユニットが監視可能かを判断します (§7.3)。次に、コンパイル単位の可観測性によって、どのパッケージが観測可能で、どのパッケージがスコープ内にあるかが決まります。
Java SE プラットフォームの単純な実装では、パッケージとコンパイル ユニットをローカル ファイル システムに格納できます。他の実装では、分散ファイル システムまたは何らかの形式のデータベースを使用してそれらを格納できます。
ホスト システムがパッケージとコンパイル ユニットをデータベースに格納する場合、データベースは、ファイルベースの実装で許容されるコンパイル ユニットにオプションの制限 (§7.6) を課してはなりません。
パッケージをファイル システムに格納する非常に単純な例として、プロジェクト内のすべてのパッケージとソースおよびバイナリ コードを単一のディレクトリとそのサブディレクトリに格納する場合があります。このディレクトリのすぐ下にある各サブディレクトリは、最上位のパッケージ、つまり、完全修飾名が 1 つの単純な名前で構成されるパッケージを表します。サブディレクトリの各レベルは、それを含むディレクトリによって表されるパッケージのサブパッケージを表します。
また、質問に密接に関連するCompilation Unitsについてもお読みください。
注:コマンド ラインからコンパイルする場合、デフォルトでは、各クラスは対応するソース ファイルと同じ場所に置かれますが、「-d」オプションを使用すると、コンパイラは適切な出力ディレクトリを構築します。
このディレクトリ構造とパッケージ名宣言の結合は、Java 言語の要件ではありません。これは、コンパイラの実装によって課されます。Java 言語仕様 の第 7 章で説明されているように、コンパイル単位をファイル システムに格納する必要はまったくありません。それらはデータベースに簡単に入れることができます。また、この言語では、パッケージ名に、基礎となるファイル システムのディレクトリ名では使用できない可能性のある文字を含めることができます。
JLS から:
パッケージをファイル システムに格納する非常に単純な例として、プロジェクト内のすべてのパッケージとソースおよびバイナリ コードを単一のディレクトリとそのサブディレクトリに格納する場合があります。このディレクトリのすぐ下にある各サブディレクトリは、最上位のパッケージ、つまり、完全修飾名が 1 つの単純な名前で構成されるパッケージを表します。サブディレクトリの各レベルは、それを含むディレクトリによって表されるパッケージのサブパッケージを表します。
私たちのコンパイラのほとんどは、この「非常に単純な」アプローチのバリエーションを使用していることは明らかです。これにより、ソース コードとバイナリ コードが並列階層に格納されます。しかし、言語については何もこれを必要としません。
パッケージを持つ主な理由は、名前の衝突を避けることです..
したがって、コンパイラにArrayList
クラスを自動的に認識させたい場合は、それを行うことができません。これは、独自のクラスに名前をArrayList
付けることができるためです。コンパイラは、使用するクラスをどのように知るのでしょうか。