javacが正しくないツリー構造を持つパッケージ宣言を持つクラスをコンパイルするのを受け入れる理由

Question

なぜ次のステップが動作しているのだろうと思いました。

のは、実際のファイル構造であることを言ってみましょう：

- src 
    - Toto.java 

ファイルToto.javaが

package myPackage; 
class Toto{} 

official javac specification状態

が自分を反映したディレクトリツリー内のソースファイルを配置含まれていパッケージ ツリー。たとえば、すべてのソースファイルが\ workspaceにある場合、 は、/ workspace内のcom.mysoft.mypack.MyClassのソースコードを \ workspace \ com \ mysoft \ mypack \ MyClass.javaに置きます。

私は

$ cd src 
$ javac Toto.java 

は意志出力誤差と思いました。 代わりに、コンパイラはエラーを生成せず、適切なファイルをコンパイルします。

もちろん、

cd src 
javac PokerQ/Affichage.java 

または

javac PokerQ/Affichage.java 

コンパイルされません。

Answer 1

原則として、ソースファイルをパッケージ階層に一致するツリーに配置する必要はありません。コンパイラは各クラスをコンパイルし、内部的にパッケージ名を格納します。ソースディレクトリをどのように編成するかに関係なく、生成された各ファイルは対応するパッケージを知ることになります。

潜在的な問題は、複数のクラスをコンパイルしている場合、それらのクラスのいくつかはお互いを参照する可能性が高いことです。コンパイラとJREは、ディレクトリ階層をの手段として使用して、あるクラスが別のクラスを参照するときにクラスを検索します。デフォルトでは、コンパイラはコンパイルされた.classファイルをJavaソースと同じディレクトリに配置します。ソースディレクトリがhiggledy-piggledyの場合、パッケージに応じて構造化されていないファイルセット.classで終わってしまい、見つからなくなります。 javacまたはjavaコマンドラインのクラス検索パスを慎重に設定することで、問題を回避することができます。

-d <path>を使用してコンパイラにディレクトリを指定すると、パッケージ階層に一致するコンパイル済みクラスのツリーが作成されますが、ソースは混乱します。誰かがデフォルトのアプローチを使用しているかどうかは確かではありません。コンパイルされたクラスをソースと同じディレクトリに入れ、原則として、かなり複雑なマルチパッケージのJavaアプリケーションを構築できます同じディレクトリ - それらをすべて追跡できると仮定します。

ソースツリーがパッケージ階層にマッチするという考え方は、必ずしも厳密に必要かどうかにかかわらず、Java開発方法論にしっかりと定着しています。IDEツールとAntやMavenのようなビルドツールはすべてこの組織を前提としているので、他の方法で作業するにはちょっと気になる必要があります。