JAVAのファイルに関しての質問です。

「構造化設計」がキーワードでしょう。モジュール、つまりはクラスの結合度は小さいほどよいとされるので、「各クラスはそれぞれ独立したファイルにまとめられている」と考えれば納得できるかと。

ファイル単位にしてしまえばJVMからみて扱いやすいというところでしょうか？

また、publicでないクラスは、同じファイルにある唯一のpuclibクラスによって利用されるだけで、外部からの参照はできない、つまり「結合度は低いので存在できる」と考えられているのでは？

上記URLによると、

「コンパイルする段階で必要なクラスが見つからないときに、

Javaのコンパイラが、ファイル名を見て、必要なクラスがそこに定義されているか判断する」

からだそうです。

これが決定的な理由とは思えないですが、

ファイルの外から見た場合に、クラスとソースの関係が簡素になりますし、

その方がコンパイルの処理が簡単になりますよね。

A.java に class A と class B が、B.java に class B が定義されているとします。

今のjava実装ではこれらを一括でコンパイルしようとすると、B.classが2つ出来ることになるため、ファイルシステム上で衝突してしまいます。

これを避けるために「1ファイルに1publicクラス」という制約があると考えていいでしょう。

「The Java Language Specification」に以下の様な感じの文がありますね。

パッケージをファイルシステム上に保存するならば衝突を避けるために、コンパイル時にエラーを出す様な制約を課すという選択肢もある。

1つのコンパイル単位にpublicなclassをただ1つだけしか置けない、という制約を暗に示している。

・The type is referred to by code in other compilation units of the package in which the type is declared.

・The type is declared public (and therefore is potentially accessible from code in other packages).

という箇条書きの前後です。

文法上は1つのコンパイル単位(CompilationUnit)に複数の定義が許されているようですけど。

コンパイラの実装で楽をするための制約ということでしょうね。

CompilationUnit:

[package QualifiedIdentifier ; ]

{ImportDeclaration}

{TypeDeclaration}

Javaが未ロードのクラスを使用しようとした場合にクラスファイルをロードします。

その時にクラスパスからファイル名で探すためでは。

ファイル名を使わない実装も可能でしょうが、オーバーヘッドを考えてファイル名を使うことにしたのではないかと。

まあ、本来はいけない理由は仕様がそうだからとかしか言えないと思いますが。

なぜそうしたかというと、既に他の方の回答にあるような理由とか、いろいろとあると思います。

理由の一つとしては、１ファイルにつき１クラスとすると、クラスローダーの構造が単純になるということが挙げられます。Java のクラスライブラリーのヒエラルキーは、ご存知のようにファイルシステム（もしくは jar ファイル内部）の階層構造と一致しています。もし、一つのファイルに複数の public クラスを含むことを許すと（あるいは、ファイル名とクラス名が一致しないことを許すと）、ファイルとpublicクラスの関連を指示するためのメタ情報が必要となります。