4 ms·
No, the file names of compilation units do matter to javac. To quote the Java Language Specification, section 7.6: > If and only if packages are stored in a fi
by teraflop 4y ago
No, the file names of compilation units do matter to javac. To quote the Java Language Specification, section 7.6:
> If and only if packages are stored in a file system (§7.2), the host system may choose to enforce the restriction that it is a compile-time error if a class or interface is not found in a file under a name composed of the class or interface name plus an extension (such as .java or .jav) if either of the following is true:
> * The class or interface is referred to by code in other ordinary compilation units of the package in which the class or interface is declared.
> * The class or interface is declared public (and therefore is potentially accessible from code in other packages).
and javac does indeed enforce this restriction, at least for public classes. It's an error to declare a public class called Foo in a file that's called anything except Foo.java.
- rowls66 4y agoI stand corrected. However, I don't believe that the class source file needs to be in a directory (or hierarchy of directories) that matches the package name. Many IDE's enforce this as well, which I believe is not correct.
- brabel 4y agoEvery class file contains the full information about the class name, package and everything needed to instantiate the class... it even includes the source class file name usually and other attributes like statement line numbers. However, for performance reasons, the JVM loads classes lazily and will only try to find classes in the directory it would be expected to be (either in the directories included in the classpth or in jars). Because you can write your own class loader, you can implement something different (like OSGi does for example - it has much more metadata so it can even load multiple classes with the same name from different jars) but this is the default behaviour.