Why Only One Public Class Per Java File

This is one of the most popular Java interview questions, and most people answer it wrong because they only memorize the rule without understanding the reasoning behind it. Once you understand the "why," the rule becomes completely obvious and you will never forget it. You will also be able to answer every follow up question an interviewer throws at you.

Let us build the understanding from scratch, the same way you would think through it yourself if you had to design Java from scratch.

The Setup: What the JVM Does When You Run a Program

Before you can understand the one public class rule, you need to understand what happens when you run a Java program.

You write your code in a .java file. The compiler turns it into a .class file. Then the JVM takes over. The JVM needs a starting point, a place to begin executing your code. That starting point is the main method.

You have seen this before:

public static void main(String[] args) {
    // your program starts here
}

The JVM will look for this exact signature and call it to start your program. Everything else in your program gets called from here, either directly or through a chain of method calls. This method is called the entry point.

Now here is the key question: how does the JVM actually find and call this main method?

The JVM calls it using the class name. If your class is called Employee, the JVM internally does something equivalent to Employee.main(args). That is why main is declared as static as well, since a static method belongs to the class itself, not to any particular object. The JVM does not need to create an Employee object first. It just calls the method directly on the class.

But to call a method on a class, the JVM needs to be able to access that class. And this brings us to the first of the two rules.

Rule One: The Main Method Must Live Inside a Public Class

Think about where the JVM is when it tries to call your main method. The JVM is the launcher. It sits outside your code, outside your package. It is trying to reach into your program from the outside and kick it off.

For the JVM to access a class from outside the package that class lives in, the class must be declared as public. A class without the public keyword is package private, which means only code inside the same package can see it. The JVM launcher, running from outside, cannot reach a package private class.

So the rule is: the main method must live inside a public class, because the JVM needs to access that class from outside, and only a public class is visible from outside its package.

// This works. The JVM can reach this class from outside.
public class Employee {
    public static void main(String[] args) {
        System.out.println("Program starts here");
    }
}

// This would be a problem. The JVM cannot reach a package-private class from outside.
class Employee {
    public static void main(String[] args) {
        System.out.println("The JVM cannot start from here across package boundaries");
    }
}

Alright, that is rule one. Now for rule two.

Rule Two: The Public Class Name Must Match the File Name Exactly

This is where the second rule comes in. Java enforces a strict constraint: if a file contains a public class, the name of that public class must be exactly the same as the name of the file.

If your file is called Employee.java, the only public class allowed in that file must be named Employee. You cannot write public class Manager inside a file called Employee.java. The compiler will refuse to compile it.

// File name: Employee.java

public class Manager {  // COMPILE ERROR
    // The compiler says: class Manager is public, should be declared in a file named Manager.java
}

You will get an error message that looks exactly like this:

error: class Manager is public, should be declared in a file named Manager.java

The compiler itself tells you the rule. The public class name must match the file name.

Why Does This File Name Rule Exist?

Let us think through this carefully, because this is the real answer to the interview question.

Imagine you have a file called Employee.java and inside it you have written one hundred classes. Class A, class B, class C, all the way to class Z and beyond. Now the JVM needs to find the main method. It knows main must be in a public class. But which of these one hundred classes is public? The JVM would have to open the file and scan through all one hundred classes to find the public one that contains main. That is slow, that is wasteful, and in a large program with thousands of classes it becomes completely impractical.

Java's designers solved this elegantly. They made a rule: the public class name must match the file name. Now when the JVM needs to run the class called Employee, it knows immediately to look in Employee.java. It does not have to search. The file name is a direct pointer to the public class. One lookup, done.

This is the efficiency and clarity the rule provides. The file name is a guarantee. It tells anyone reading the project, and tells the JVM itself, exactly where to find the public class.

How the Two Rules Lock Together

Here is where it gets satisfying. Look at how the two rules combine:

Rule one says the main method must be inside a public class.

Rule two says a public class name must match the file name.

Since the public class must match the file name, and there can only be one file name per file, there can only be one public class per file. The two rules together make the one public class limit completely inevitable. It is not an arbitrary restriction. It follows logically from the two rules.

Now imagine Java allowed two public classes in one file. Say the file is called Employee.java and it contains public class Employee and public class Manager. Rule two says the public class must match the file name. But there are two public classes. Which one gets to match the file name? They cannot both be called Employee. The rule falls apart immediately. The only way rule two can work is if there is at most one public class in any given file.

Walking Through a Full Example

Let us look at a file with multiple classes to see exactly how this works in practice.

// File: Employee.java

public class Employee {
    // This is the public class. Its name matches the file name. This is correct.
    
    public static void main(String[] args) {
        System.out.println("Program starts from Employee");
        
        // We can use the other classes in this file
        Helper helper = new Helper();
        helper.doWork();
        
        Manager manager = new Manager();
        manager.manage();
    }
}

// This class has no access modifier. That makes it package-private.
// It is completely valid to have this here.
class Helper {
    void doWork() {
        System.out.println("Helper is doing work");
    }
}

// Another package-private class. Also completely valid.
class Manager {
    void manage() {
        System.out.println("Manager is managing");
    }
}

// public class Director { }  // This would be a COMPILE ERROR.
// You cannot have a second public class in Employee.java.

This file compiles and runs perfectly. You have one public class named Employee that matches the file name. You also have two additional classes, Helper and Manager, but neither of them is public. They are package private. The rule does not restrict package private classes at all. You can have as many of them as you want in a single file.

What Package Private Actually Means

When you write a class without any access modifier, like this:

class Helper {
    void doWork() { }
}

That class is package private. It is visible to all other classes within the same package, but it is invisible to code outside the package. This is a completely valid and useful visibility level. It is perfect for helper classes that support the public class but are not meant to be used directly by anyone outside the package.

The JVM's file name lookup problem only applies to public classes. Package private classes are not accessible from outside the package anyway, so the JVM does not need to look them up by file name. They can safely live alongside the public class in the same file, and Java has no issue with that arrangement.

The Quiz Walkthrough: Testing Your Understanding

The transcript frames this as a quiz question, so let us walk through it exactly like one.

Question: Why can a Java file only have one public class?

The wrong answer is: "Because Java says so." That tells you nothing.

The right answer walks through the reasoning:

Step one: The JVM calls the main method to start a program. It does this by using the class name, so the class must be accessible to the JVM. The JVM runs from outside the package, so the class must be public.

Step two: Java requires that a public class's name must match the file name. This gives the JVM a guaranteed, fast lookup. Instead of scanning through all the classes in a file, the JVM goes straight to the right file using the file name as a pointer.

Step three: Since the public class name must equal the file name, and there is only one file name per file, there can only be one public class per file. If you tried to have two public classes, they would both need to match the file name, which is impossible.

Conclusion: Both rules exist because the JVM needs them. The public access is needed for visibility. The file name match is needed for efficient lookup. The one public class limit falls out of those two rules automatically.

Follow up question: Can a file have zero public classes?

Yes. A file can contain only package private classes. In that case the file name does not technically need to match any particular class name, though by convention it is named after the main class in the file. There is no rule being violated because there are no public classes to enforce the name matching rule against.

Follow up question: How many package private classes can be in one file?

As many as you want. There is no limit on package private classes. The restriction is only on public classes.

Follow up question: What error do you get if you put two public classes in one file?

You get a compile time error, not a runtime error. The compiler catches this before the JVM is ever involved:

error: class Manager is public, should be declared in a file named Manager.java

The compiler is telling you exactly what to do. It is not confused about what you intended. It knows you wrote public class Manager and it knows the file is not called Manager.java. It tells you the fix directly.

Follow up question: Does the main method technically require a public class by the Java specification?

This is the nuanced version of the question. Strictly speaking, the Java Language Specification says that a public class must have a name matching the file name. It does not explicitly say that main must be in a public class. You can actually run a program where the class containing main is package private, as long as you are running it from within the same package or using a tool that can access it. However, the design intent and the practical convention is that main lives in a public class. For the JVM to find and run the entry point reliably from outside, the class must be public. In an interview, explain the design motivation while noting the technical nuance if pressed.

The Complete Picture

Let us put everything together in one final summary.

The JVM starts your program by calling main. To call main, the JVM needs the class that contains it. To access a class from outside its package, that class must be public. Java requires a public class to have the same name as its file. Since a file has one name, it can contain only one public class. This is not an arbitrary rule. It is the logical outcome of two design decisions that together make Java programs reliable and efficiently loadable.

Package private classes are not subject to the name matching rule because they are not accessible from outside the package anyway. You can have as many of them as you want alongside your single public class in any given file.

// File: Employee.java

// One public class, named exactly as the file. Correct.
public class Employee {
    public static void main(String[] args) {
        System.out.println("JVM finds this class instantly via the file name");
    }
}

// Unlimited package-private classes are fine.
class EmployeeValidator {
    boolean isValid(String name) {
        return name != null && !name.isEmpty();
    }
}

class EmployeeRepository {
    void save(Employee e) {
        System.out.println("Saving employee...");
    }
}

// Adding 'public' to any of these would be a compile error.
// public class EmployeeValidator { }  // ERROR: must be in EmployeeValidator.java

When an interviewer asks you this question, walk through the two rules and show how they combine to produce the restriction. That answer demonstrates that you actually understand Java's design rather than just memorizing a fact. That is the difference between a candidate who studied for the interview and one who genuinely understands the language.