To allow the compiler found easily the class definition. Its easier to compile that way. I don't have a reference ( that's why this is a comment ) but I think the answers below point to that.
–
OscarRyzAug 26 '10 at 19:01

1

In other words, invent your own programming language if you disagree :)
–
BalusCAug 26 '10 at 19:01

+1, totally agree, hell I miss this in C#. Even if I always use a separate file for each class/enum/struct I have seen horrible things :-)
–
Darin DimitrovAug 26 '10 at 19:01

3

It should be even more strict and also apply to non-public classes. Most people do it the right way, but some still manage to make a mess by putting many default visible classes in one file.
–
starblueAug 26 '10 at 21:34

Do you have a citation to support the claim that code readability was the reason why the designers chose this restriction?
–
RohitDec 21 '11 at 13:39

@starblue Don't get private classes and inner classes mixed up. Inner classes (that are not static; which, I agree, should be in their own file) allow direct access of the parent object, and all instances must be instantiated with an object.Class instead of just a Class. In contrast, they are functionally very different.
–
QixJan 16 '13 at 7:48

In the sidebar it explains why: "This
restriction is not yet enforced by the
compiler, although it's necessary for
efficient package importation"

It's pretty obvious - like most things
are once you know the design reasons -
the compiler would have to make an
additional pass through all the
compilation units (.java files) to
figure out what classes were where,
and that would make the compilation
even slower.

The same applies also for imports of source files in IDEs. Another reason would be reasonable source sizes.

Java utilizes this convention to find class/interface bytecode by starting at the classpath and scanning for the package hierarchy in subdirectories. Filesystem representation of this hierarchy also enforces some basic rules.

Any two Java classes or interfaces
in the same package cannot have the
same name. File names would
conflict.

Any two Java packages in
the same parent package could not
have the same name. Folder paths
would conflict.

A class has visibility to all classes in the same package without modification
to the classpath.

This is a question that I have
frequently been asked during my
courses. Up to now I have not had a
good answer to this question. In
section 1, we read: "Although each Oak
compilation unit can contain multiple
classes or interfaces, at most one
class or interface per compilation
unit can be public".

In the sidebar it explains why: "This
restriction is not yet enforced by the
compiler, although it's necessary for
efficient package importation"

It's pretty obvious - like most things
are once you know the design reasons -
the compiler would have to make an
additional pass through all the
compilation units (.java files) to
figure out what classes were where,
and that would make the compilation
even slower.

It enables a more efficient lookup of source (.java) and compiled (.class) files during compilation (import directive) and a more efficient classloading during execution. The idea being: if you know the name of a class, you know where it should be found for each classpath entry. No indexing required.

Wrong about the runtime class-loading. If I have a file X.java that contains public class X and non-public class Y, then the compiler will create two files, X.class and Y.class. The class loader doesn't care whether the classes are public, and it has no way of telling whether they came from the same file.
–
Mike BaranczakAug 26 '10 at 19:15

This does not impact the class loader lookup performance. Once compiled, it's not relevant to know from which source file the class comes from. For the compiler however, a reference to the not-yet-compiled class Y will force the compiler to examine each *.java files within the current package (typically, all the source files of the directory of the package). That's rather a minor detail.
–
gawiAug 26 '10 at 20:11

We can have only one top level public either class or interface in any java compilation unit ( .java source file ).

But there can be any number of default classes/interfaces per src file.

why:

JLS leaves the option to the java compiler. And most of the compiler implementations force to have file name same as :

(1) the public class/interface name

(2) if there is a main method and no public class then any name

(3) If there is main method and public class then main method should be in that public class

(4) if there is no public class and no main method then any valid name which may or may not be matching with the class/interface names in the file.

From (2): If two public classes allowed, we should give the file two names which is terribly meaningless to file system.
From (3): If two public classes allowed, we should have two main methods which is terribly meaningless to java

Hence a Java source file can have one only public class.

I think the above 4 points are forced by compiler to make the job of both compiler and jvm to find particular java source file or class file easy-so-quick for the compilation/loading/linking. Java has such built in restrictions which developers should follow to have better programming.