Why would you ever want a Java file with no public classes declared in it?

There is a statement in the book I'm reading for the SCJP qualification, it says :

Files with no public classes have no naming restrictions

That has made me ask, why would you ever want to do this?

If there are no public classes, then how could other classes ever import and use the开发者_如何学Python file? The only purpose I can see is if the file runs standalone in itself, which could also be odd, such as have an entire application in one file

This is valid for package-private classes as well. And you can use package-private classes within the same package. (And in that case you don't have to import it, because it's in the same package.)

For example, the JapaneseImperialCalendar class is package-private, because it is only used from Calendar.createCalendar(..) - it is not part of the public API. You can't directly instantiate the japanese calendar, but you can still use it by its interface. Same goes for all unmodifiable collections that are obtained by methods like Collections.unmodifiableList(..) - they are package-private.

So the .java file of JapaneseImperialCalendar could've been arbitrary. However, it is advisable not to diverge from the established practice of naming even package-private files after the class name.

You can create a file named package-info.java, which contains only a package statement. The javadoc 1.5+ tool treats a javadoc comment on this package statement exactly like a package.html file. In addition, you can add package-level annotations such as @Generated to this statement, which you can't do in package.html.

Because package-info is not a valid Java identifier, there is no risk of this file ever clashing with an existing Java class (i.e. backwards compatibility).

From Java Classes, you have public classes and package classes. Package classes are considered "private" so that you can only use them within the package itself. This is the default, i.e. no public is specified.

Public classes are, of course, classes that you can create anywhere.

Even though I am very late in answering the question, but this will surely help a lot. If I am not wrong, your concrete question boils down to this - What is the significance of a class declared with no no explicit modifier?

Have a look at this class present in java.util package-

class JumboEnumSet<E extends Enum<E>> extends EnumSet<E>

Also see within the same package-

class RegularEnumSet<E extends Enum<E>> extends EnumSet<E>

You see both of them are declared with no explicit modifier. Have you wondered why the package private restriction? Here's the reason from the amazing book Effective Java 2nd Edition by Joshua Bloch #Item1

The class java.util.EnumSet (Item 32), introduced in release 1.5, has no public constructors, only static factories. They return one of two implementations, depending on the size of the underlying enum type: if it has sixty-four or fewer elements, as most enum types do, the static factories return a RegularEnumSet instance, which is backed by a single long; if the enum type has sixty-five or more elements, the factories return a JumboEnumSet instance, backed by a long array.

Move swiftly on, he further adds-

The existence of these two implementation classes is invisible to clients. If RegularEnumSet ceased to offer performance advantages for small enum types, it could be eliminated from a future release with no ill effects. Similarly, a future release could add a third or fourth implementation of EnumSet if it proved beneficial for performance. Clients neither know nor care about the class of the object they get back from the factory; they care only that it is some subclass of EnumSet.

I don't agree with the non-restriction. Each java file should contain only one top level class, and the file name should be the same as the class name, public or not. I don't think javac would like this very much (or any human being)

A.java
    class B

B.java
    class A

http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.3

7.2 Host Support for Packages

Each host determines how packages, compilation units, and subpackages are created and stored, and which compilation units are observable (§7.3) in a particular compilation.

7.2.1 Storing Packages in a File System

As an extremely simple example,

http://download.oracle.com/javase/6/docs/technotes/tools/windows/javac.html

both source and class files must have root names that identify the class. For example, a class called MyClass would be written in a source file called MyClass.java and compiled into a bytecode class file called MyClass.class.