Why Only 1 Public Class in Java File

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.

Questions about given answer on topic of why only one public class per file

That explanation is more or less bogus. The real reason that the source file name of a public class file must be the same as the classname is because the spec says so. Simple as that.

import statements don't do anything special; you can import a class file that isn't used at all, and this will result in literal NOTHING whatsoever in the class file; if that imported class isn't even around when you run the code, it won't matter. This isn't python or a scripting language; import doesn't load it. at all. All import com.foo.Bar; does is say: "Anytime Bar shows up in this file as a type name, imagine it read com.foo.Bar instead" (and as a consequence, you can remove the import statement, and replace all occurrences of Bar with com.foo.Bar and the file works just the same.

As a consequence, putting the file name in an import statement isn't legal java.

Note also that if you put a non public class inside a file, even that file does NOT have the same name as that class, that is fine, and still results in that class existing on its own, in its own file, if you compile it (compiling 1 java file may produce more than 1 class file!)

If we'd have to guess at why whomever wrote in the java spec that public classes must be in a file named the same... who knows, really. There is no real reason for it. What the bogus answer you found is trying to drive at, is that if you use javac's very limited ability to find source files that must also be compiled (using the -sourcepath option, I guess this might indeed be easier, but note that there's nothing stopping you from writing code that refers to another non-public, not-yet-compiled class in the same package and run just javac ThatFile.java resulting in the same 'now the source file that needs to be compiled is hard to find' problem. Hence, why the answer you found, is bogus.

Should a java package have only one public class?

Yes, a package can have multiple public classes.

Creating a new package for every public class would be extremely cumbersome and provide no overview at all.

java. are just the standard libraries that come with the JDK/JRE.

Packages are really just like folders on your system. You can have multiple files in a folder without a problem.

Typically packages are structured in a way that they combine related classes to make it easier for the developer. If you want to have no packages at all, or you want a new package for every class: it doesn't matter. You'll be your own worst enemy, but it is surely possible.

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

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.