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

Question

I came accros following Question: Why only 1 public class in Java file

and there was this Answer:

To understand the basic reason behind these restrictions, let's suppose compiler doesn't give compile error for not naming file name same as public class name.

Suppose there is a package A

        A
      /   \
file1.java   file2.java

file1.java

package A;

class file1
{
  public static void main(String args[])
  {

  }
}

public class file3
{
 public static void main(String args[])
 {

 }
}

Now as we know that a public class can also be accessed outside the package, now it will become the responsibility of a developer to make it accessible to the outside world. Let's see how:

Suppose package A is containing only Java files(no class files) and some class outside the package A tries to access public class file3, compiler will first try to find file3.class ( not available ), then it will try to find file3.java ( not available ). So even though file3 class is public in nature, it is not visible to the outside world. So if a compiler puts the restriction that if a file is containing public class, it should be named same as the public class name, then above issue can be resolved and the developer won't have to think of exposing public class to the outside world.

Compiler also puts the restriction that there should be atmost one public class per Java file, so that every public class can be accessed by the outside world.

But wouldn't we use something like import folder.packagename.filenameofclassfile3; so it would still technically work?

if .class-file would not exist at the time of compilation

we would basically tell the compiler where to find the class file3 by using the full qualified name.

Answer 1

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.