Why Is Each Public Class in a Separate File

Why is each public class in a separate file?

According to the Java Language Specification, Third Edition:

This restriction implies that there must be at most one such type per compilation unit. This restriction makes it easy for a compiler for the Java programming language or an implementation of the Java virtual machine to find a named class within a package; for example, the source code for a public type wet.sprocket.Toad would be found in a file Toad.java in the directory wet/sprocket, and the corresponding object code would be found in the file Toad.class in the same directory.

Emphasis is mine.

It seems like basically they wanted to translate the OS's directory separator into dots for namespaces, and vice versa.

So yes, it was a design consideration of some sort.

Do different classes need to be in different java files?

It's possible to place multiple classes in one .java file. However, this is a bad idea. Here's why:

package foo.bar;

public class Foo { }

public class Bar { }

A source file that contains the above code as-is won't compile, as each .java file can contain only one public class/interface/enum (btw, these are called "type"s). As a result you have to do this to keep them in the same file:

package foo.bar;

public class Foo { }

class Bar { } // Not public

Or this:

package foo.bar;

class Foo { } // Not public

public class Bar { }

Now here comes the drawback: If the non-public type(s) contain something useful to everything (such as a method for generating random numbers over a normal distribution), it won't be accessible to anything that is not in the package called foo.bar!

Besides, it's easier to manage small source files.

---

Moreover, is there a distinction about where the files should be stored—e.g. in the same directory

Yes - this depends on the package names. For example, the packages foo.bar, foo.baz, foo.qux, bar.foo, bar.baz and bar.qux would look like these subfolders of a common source folder (let's call it src):

./src/
L___ ./src/foo/
|    L__ ./src/foo/bar/
|    L__ ./src/foo/baz/
|    L__ ./src/foo/qux/
L___ ./src/bar/
|    L__ ./src/bar/foo/
|    L__ ./src/bar/baz/
|    L__ ./src/bar/qux/

When you apply this logic to java.lang.Object (assuming the source folder is still called src), you'd get this:

./src/
L___ ./src/java/
|    L___ ./src/java/lang/
|    |    L___ ./src/java/lang/Object.java

Can a java file have more than one class?

Yes, it can. However, there can only be one public top-level class per .java file, and public top-level classes must have the same name as the source file.

The purpose of including multiple classes in one source file is to bundle related support functionality (internal data structures, support classes, etc) together with the main public class. Note that it is always OK not to do this--the only effect is on the readability (or not) of your code.

Why can't two public classes be defined in one file in java?

As per java language specification, there can be only one public class in a file (.java) and file name should be same as public class name.

If you want class B accessible in other placs, you may create a separate B.java file and move your Class B code to that file.

This thread may give you some more information.

Why is an enum declared in a separate file, in Java?

Why is an enum declared in a separate file, in Java?

You don't have to declare an enum in a separate file. You could do this:

public class Temperature {
    public enum ScaleName {celsius, fahrenheit, kelvin, rankine};
    
    private double number;
    private ScaleName scale;

    public Temperature() {
        number = 0.0;
        scale = ScaleName.fahrenheit;
    }
    ...
}

The only difference between this and making the enum a top level class is that you now need to qualify the name of the enum when you use it in a different class.

But what is going on in my example is no different to what happens if the enum was any other static nested class. (A nested enum is implicitly static, so we don't need a static keyword. See JLS 8.9.)

---

Why is this enum declared in its own file.

Because the code author chose to do it this way¹.

Is there an advantage to this?

Yes. It means that don't have to qualify the enum to use it ... in some circumstances where you would have to if the enum was nested as above.

---

Actually, Java does allow you to put multiple top-level classes into the same source file provided that all but one of the classes is "package private". However, doing that is generally thought to be bad style, and it can be problematic for some tool chains ... I have heard.

---

^{1 - If you want to know the real reason why the authors of the textbook chose to do it that way, you would need to ask them!}

Is it a good practise to create a seperate java file for each class in Eclipse?

It is not only good practice, it is the way Java was intended to be written.

Why is each public class in a separate file?

Multiple classes in the same file is possible, with nested classes and anonymous classes and so on, but you should really have a good reason to do such a thing. There is nothing wrong with a small class, and it greatly improves readability when you are not searching through large files looking for internal classes.

Should I put a public interface in a separate file?

You should put it in a separate file. That way it's easier to swap in a different implementation, or make the interfaces (the API of your system) available for others to code against without knowing the details of your implementation, or having to drag in related dependencies.

e.g. implementations of common Java APIs - e.g. servlets - will have an implementation coded against the package of interfaces provided by Sun (in this case javax.servlet)

How can you use it from your implementation ? By importing it. This is unnecessary if it's in the same package and you're compiling all your interfaces/implementations at once.

Note that an interface compiles down to a .class file in the same way as an implementation (what you define using class).

---

Related Topics