When you create a source-code file for Java, it’s commonly called a compilation unit (sometimes a translation unit). Each compilation unit must have a name ending in .java, and inside the compilation unit there can be a public class that must have the same name as the file (including capitalization, but excluding the .java file name extension). There can be only one public class in each compilation unit; otherwise, the compiler will complain. If there are additional classes in that compilation unit, they are hidden from the world outside that package because they’re not public, and they comprise “support” classes for the main public class.
Code organization
When you compile a .java file, you get an output file for each class in the .java file. Each output file has the name of a class in the .java file, but with an extension of .class. Thus you can end up with quite a few .class files from a small number of .java files. If you’ve programmed with a compiled language, you might be used to the compiler spitting out an intermediate form (usually an “obj” file) that is then packaged together with others of its kind using a linker (to create an executable file) or a librarian (to create a library). That’s not how Java works. A working program is a bunch of .class files, which can be packaged and compressed into a Java ARchive (JAR) file (using Java’s jar archiver). The Java interpreter is responsible for finding, loading, and interpreting these files.
A library is a group of these class files. Each source file usually has a public class and any number of non-public classes, so there’s one public component for each source file. If you want to say that all these components (each in its own separate .java and .class files) belong together, that’s where the package keyword comes in.
If you use a package statement, it must appear as the first non-comment in the file. When you say:
package access;
you’re stating that this compilation unit is part of a library named access. Put another way, you’re saying that the public class name within this compilation unit is under the umbrella of the name access, and anyone who wants to use that name must either fully specify the name or use the import keyword in combination with access, using the choices given previously. (Note that the convention for Java package names is to use all lowercase letters, even for intermediate words.)
For example, suppose the name of the file is MyClass.java. This means there can be one and only one public class in that file, and the name of that class must be MyClass (including the capitalization):
//: access/mypackage/MyClass.java
package access.mypackage;
public class MyClass {
// ...
} ///:~
Now, if someone wants to use MyClass or, for that matter, any of the other public classes in access, they must use the import keyword to make the name or names in access available. The alternative is to give the fully qualified name:
//: access/QualifiedMyClass.java
public class QualifiedMyClass {
public static void main(String[] args) {
access.mypackage.MyClass m =
new access.mypackage.MyClass();
}
} ///:~
The import keyword can make this much cleaner:
//: access/ImportedMyClass.java
import access.mypackage.*;
public class ImportedMyClass {
public static void main(String[] args) {
MyClass m = new MyClass();
}
} ///:~
It’s worth keeping in mind that what the package and import keywords allow you to do, as a library designer, is to divide up the single global namespace so you won’t have clashing names, no matter how many people get on the Internet and start writing classes in Java. [Thinking in Java, 146~]
