Javaパッケージ構造とフォルダ構造

Question

私が見たすべてのJavaプロジェクトは、パッケージ構造に従ったフォルダ構造を使用しています。これにより、ファイルが含まれていない多数のフォルダが作成されます。

したがって、パッケージはcom.mydomain.mysystem.myutilityで始まります。これにより、ファイルが含まれていないsrc\com、src\com\mydomain、src\com\mydomain\mysystemというフォルダが作成されます。ほとんどの場合、myutilityにはフォルダのみが含まれます。また、名前myutilityが含まれているプロジェクトフォルダが存在しますほとんどの

ので、完全なフォルダパスがmyutility\src\main\java\com\mydomain\mysystem\myutility\otherfolder

可能性があり、この練習は非常に一般的ですが、それは、我々はそれがどのように役に立つ思ってしまいます。これらの余分なフォルダが作成されない状況と比較した場合の利点は何ですか？たとえば、myutility\src\main\java\otherfolder

これはちょうど有効であるように見えますが、余分なナビゲーションステップをすべて節約できます。両方のアプローチでJavaソースファイルをコンパイルできます。

プロジェクトでは、通常、すべてのソースはcom\mydomain\mysystemです。これらの「空の」フォルダをすべてのプロジェクトに入れる利点は何ですか？

私はパッケージ構造の有用性に疑問を呈していません。またMavenも明らかです。

質問は、組織のリポジトリ全体で通常は同じ空のフォルダを使用する理由です。

Answer 1

ソース（およびクラス）ファイルは、Javaコンパイラ（および実行時環境）がそれらを見つけることができるように編成されています。

Javaコンパイラがクラスをコンパイルするとき、そのクラスが依存する各クラスのソースファイルまたはクラスファイルが必要です。クラスが存在するかどうか、すべてのメソッドが正しい引数などで呼び出されるかどうかを確認できます。また、ソースファイルがクラスファイルではなく、クラスファイルがソースファイルよりも古い場合は、使用するクラスのソースファイルをコンパイルします。

もちろん、コンパイラはクラスパスのすべてのサブフォルダやディスク全体をチェックすることもできますが、それには時間がかかります。この規約のため、コンパイラはクラスパスエントリごとに1つのサブフォルダのみをチェックする必要があります。もちろん、この問題のさまざまな解決策について考えることができますが、（当時の）Sunの人々はこれが最良の選択だと考えました。

もちろん、上記は実行時に読み込まれるクラスファイルにも適用されるため、クラスファイルも同様のフォルダ構造に格納されます。

Javaアプリケーションとライブラリは、多くの場合、ファイルシステム内で単一のファイルとして表示されるため、Jarファイル（基本的には同じフォルダ構造のZIPファイル）としてパッケージ化されることがあります。

Answer 2

このようにしたのは、競合を防ぎ、クラスを一意に識別できるようにするためです。つまり、2つのクラスが同じ名前を持つ場合でも、異なるインポートによってロードできます。例えば

com.google.<classname>：

これを行うための最も安全な方法は、固有の性質により、あるドメイン名を使用することです。

あなたのアプローチは機能し、いくつかの空のフォルダを保存しますが、スケーラビリティはありません。