Cosmic Module

J

Qubits of DPK

March 15, 2026

Core Java

Layman Explanation

Every building has ONE name board outside. If two departments put their names on the same building, the postal system gets confused — nobody knows which one is the real entrance. Java enforces the same rule.

The Rule

In Java, a single .java file can have only ONE public class, and the filename must exactly match that public class name.

Why This Rule Exists

JVM's ClassLoader finds classes by filename.
javascript
QUBITS OF DPK
1Program needs class "Engine"
23ClassLoader looks for "Engine.class"
45Finds it → loads → runs ✅
If two public classes were in one file:
javascript
QUBITS OF DPK
1File: Car.java
2public class Car { }      ← file named Car.java3public class Engine { }   ← should be Engine.javaCONFLICT!
ClassLoader cannot map Engine to Engine.class reliably. Compile error.

What IS Allowed

java
QUBITS OF DPK
1// File: Student.java
2public class Student {    // ✅ public — matches filename
3    Address address;
4}
5
6class Address {           // ✅ non-public — no restriction
7    String city;
8}
9
10class Grade {             // ✅ non-public — allowed
11    double cgpa;
12}

Summary Table

️ Interview Traps

javascript
QUBITS OF DPK
1Trap 1: "Only one class allowed per file"WRONG
2        Multiple classes allowed, only ONE PUBLIC
3
4Trap 2: Filename rule only applies to PUBLIC class
5        Non-public classes have no filename restriction
6
7Trap 3: Inner classes can be public inside public outer class
8        Not a violation

Interview Answer (SDE-2)

"Java allows only one public class per file because the JVM's ClassLoader uses the filename to locate and load classes. Public means accessible from everywhere, so it must be reliably findable via filename. Two public classes in one file creates a naming conflict — ClassLoader can't map class name to filename. Non-public classes don't need this guarantee since they're only accessible within the same package."

Interview Questions & MAANG-Level Answers

Q1. Why can't you have two public classes in one Java file?
Because the JVM's ClassLoader finds classes by filename. When ClassLoader needs class Engine, it looks for Engine.class, which was compiled from Engine.java. If Engine is public inside Car.java, the mapping breaks — Engine.class exists but no Engine.java. Compile error: class Engine is public, should be in a file named Engine.java. This rule ensures: one public class = one file = predictable, reliable ClassLoader behavior across all environments, build tools, and IDEs.
Q2. Can a file have multiple non-public classes?
Yes. A single .java file can contain any number of non-public (package-private) classes. Only the public class must match the filename. Example: Student.java can have public class Student, class Address, class Grade — compiler produces Student.class, Address.class, Grade.class. Non-public classes are only accessible within the same package, so they don't need the same discoverability guarantee as public classes.
Q3. What is ClassLoader and how does it find classes?
ClassLoader is the JVM component that loads .class files into memory on demand — lazily (only when first referenced). It searches: (1) Bootstrap ClassLoader — loads core Java classes from JDK's rt.jar/modules. (2) Extension/Platform ClassLoader — loads JDK extension classes. (3) Application ClassLoader — loads your application classes from classpath. Search order is hierarchical (parent-first). For Car class: looks for Car.class in classpath directories and JARs. Custom ClassLoaders enable dynamic class loading (plugin systems, hot reload in Spring DevTools).
Q4. Does the filename rule apply to non-public classes?
No. Non-public (package-private) classes have no filename restriction. Helper.java can contain class DatabaseHelper, class FileHelper — no errors. However, best practice is to name the file after the main/most important class for readability and maintainability. IDEs and build tools expect one class per file even for non-public classes. The rule is technically about the PUBLIC class only.
Q5. How do inner classes fit into this rule?
Inner classes (non-static nested, static nested, local, anonymous) are part of their enclosing class — they don't violate the rule. public class Car { public class Engine {} } is valid — Engine is accessed as Car.Engine, not as a standalone class. The compiler produces Car.class and Car$Engine.class (dollar sign notation for inner classes). Public inner classes are fine because they're only accessible through the outer class, maintaining the one-entry-point-per-file principle.