Java Packages: library units

When we import a complete library with the Import keyword, we get a "package" (Package). For example:
Import java.util.*;
Its role is to import the complete utility (Utility) library, which is part of the standard Java Development Toolkit. Because the Vector is in Java.util, you can now either specify the full name "Java.util.Vector" (omit the import statement), or simply specify a "Vector" (because import is the default).
To import a single class, you can specify the name of the class in the import statement:
Import Java.util.Vector;
Now we are free to use the vector. However, any other class in the Java.util is still not available.
The reason for this import is to provide a special mechanism for managing "namespaces" (name space). The names of all our class members will be isolated from each other. A method F () in Class A does not conflict with F () in class B that has the same signature (the argument list). But will the class name conflict? What happens if you create a stack class and install it on a machine that already has a stack class (written by someone else)? For Java applications on the Internet, this happens when the user does not know, because the class is automatically downloaded when running a Java program.
Because of the potential conflict of names, it is particularly necessary to have complete control over the namespaces in Java and to create a completely unique name, regardless of the limitations of the Internet.
To date, most examples of this book exist only in a single file and are designed locally (locally) and do not conflict with the package name (in which case the class name is placed in the "default package"). This is an effective approach and, given the simplification of the problem, the remainder of the book will use it as much as possible. However, if you plan to create a program that is "internet friendly" or "suitable for use on the Internet", you must consider how to prevent duplication of class names.
When creating a source file for Java, it is often called an "edit unit" (sometimes called a "translation Unit"). Each compilation unit must have a name that ends with a. java. And within the compilation unit, there can be a public class, which must have the same name as the file (including capitalization, but excluding the. java file extension). If you do not do so, the compiler will report an error. There can be only one public class in each compilation unit (likewise, the compiler will report an error). The remaining classes in that compilation unit, if any, can be hidden in front of the world outside that package because they are not "public" (Non-public), and they are made up of "support" classes that are used by the primary public class.
When compiling a. java file, we get an output file with exactly the same name, but for each class in the. java file, they have a. class extension. So we end up with the possibility of getting a large number of. class files from a few. java files. As previously written in an assembly language, then it may be customary for the compiler to split a transition form (usually an. obj file), encapsulate it with something else with a linker (generate an executable file), or encapsulate it together with a library (build a library). But that's not how Java works. An effective program is a series of. class files that can be encapsulated and compressed into a jar file (using the jar tools provided by Java 1.1). The Java interpreter is responsible for finding, loading, and interpreting these files (note ①).

①:java is not obligated to use an interpreter. Some Java compilers with intrinsic code can generate separate executables.

The library is also composed of a series of class files. Each file has a public class (it is not forced to use a public class, but this is the most typical), so each file has a component. If you want all of these components to be grouped together in separate. Java and. class files, then the Package keyword works.
If you use the following code at the beginning of a file:
Package mypackage;
Then the package statement must appear as the first non-annotated statement of the file. The purpose of this statement is to indicate that the compilation unit is part of a library named MyPackage. Or in other words, it indicates that the public class within the compilation unit is fame under the name MyPackage. If someone else wants to use the name, either point to the full name, or use the Import keyword in conjunction with mypackage (using the options given earlier). Note that according to the Java Package (encapsulation) Convention, all letters in the name should be lowercase, even in the middle words.
For example, suppose the filename is Myclass.java. It means that there is one and only one public class in that file. And the name of that class must be MyClass (including the case):

Package mypackage;
public class MyClass {
// . . .

Now, if someone wants to use MyClass, or if they want to use any of the other public classes in MyPackage, they must activate the name within the mypackage with the Import keyword so that they can use it. Another option would be to specify the full name:

MyPackage. MyClass m = new MyPackage. MyClass ();

The Import keyword makes it much simpler:

Import mypackage.*;
// . . .
MyClass m = new MyClass ();

As a library designer, be sure to remember that what package and import keywords allow us to do is split a single global namespace so that we don't encounter names-no matter how many people use the Internet or how many people write their own classes in Java.