Create a unique package name

You may have noticed the fact that because a package never really "encapsulates" into a single file, it can be composed of multiple. class files, so the situation may be slightly confusing. The most reasonable way to avoid this problem is to place all the. class files used by a particular package into a single directory. In other words, we want to use the operating system's hierarchical file structure to avoid confusion. This is the approach that Java takes.
It also solves two other problems: creating unique package names and finding classes that might be hidden somewhere in the directory structure. As we explained in chapter 2nd, to achieve this, the location path of the. class file needs to be encoded into package's name. However, according to the Convention, the compiler forces the first part of the package name to be the Internet domain name of the creator of the class. Because the Internet domain name is certainly unique (by InterNIC guarantee--annotation ②, it controls the allocation of domain name), so if according to this agreement, package name will certainly not repeat, so never encounter name conflict problem. In other words, unless you transfer your domain name to someone else, and the other person writes Java code in the same path name, the name conflict is never going to happen. Of course, if you do not have your own domain name, then you must create a very uncommon package name (such as your own English name), so as to maximize the possibility of creating a unique package name. If you decide to issue your own Java code, it is highly recommended to apply for your own domain name, and the cost is very low.

②:ftp://ftp.internic.net

Another part of this technique is to parse the package name into a directory on its own machine. As a result, the Java program runs and needs to load the. class file (This is dynamic, when the program needs to create an object belonging to that class, or when it first accesses a static member of that class), it can find the directory where the. class file resides.
The Java interpreter works as follows: First, it finds the environment variable classpath (set by the operating system when installing Java or Java-capable tools such as browsers) into the machine. Classpath contains one or more directories, which are used as a special "root" to expand the search for. class files from here. Starting with that root, the interpreter looks for the package name and replaces each point number (period) with a slash to generate a pathname starting from the Classpath root (so package Foo.bar.baz becomes foo\bar\baz or Foo/bar/baz , whether a forward slash or a backslash is determined by the operating system). They are then connected together to become entries (portals) within the classpath. When you search for the. class file later, you can start looking for the name of the class name that you want to create. In addition, it searches for standard directories that are related to where the Java interpreter resides.
To further understand this issue, take my own domain name for example, which is bruceeckel.com. Turning it upside down, Com.bruceeckel created a unique global name for my class (Com,edu,org,net extensions were previously capitalized in the Java package, but this has changed since Java 1.2). The entire package name is now lowercase. As I decided to create a library called Util, I could split it further, so the last package was the following name:
Package com.bruceeckel.util;
You can now use this package name as a "namespace" for the following two files:

: Vector.java
//Creating a package
package com.bruceeckel.util;

public class Vector {public
  vector () {
    System.out.println (
      "Com.bruceeckel.util.Vector");
  }
/ //:~

When you create your own package, you require that the package statement be the first "non-annotated" code in the file. The second file looks similar on the surface:

: List.java
//Creating a package 
package com.bruceeckel.util;

public class List {public
  list () {
    System.out.println (
      "com.bruceeckel.util.List");
  }
// /:~

These two files are placed in a subdirectory of my own system:
C:\DOC\JavaT\com\bruceeckel\util
If you go back through it, you will find the package name Com.bruceeckel.util, but what is the first part of the path? This is determined by the CLASSPATH environment variable. On my machine, it is:
classpath=.;D: \ Java\lib; C:\DOC\JavaT
As you can see, classpath can contain a large number of alternate search paths. However, when using a jar file, be aware of the problem: you must place the name of the jar file in the classpath, not just the path where it resides. So for a jar file called Grape.jar, our classpath needs to include:
classpath=.;D: \ Java\lib; C:\flavors\grape.jar
Once you have set the classpath correctly, you can place the following file in any directory (see the 3.1.2 section of chapter 3rd "assigning") when you run the program:

//: Libtest.java//Uses the library package c05; import com.bruceeckel.util.*;
    public class Libtest {public static void main (string[] args) {vector v = new vector ();
  List L = new list (); }
} ///:~

When the

compiler encounters an import statement, it searches for the directory specified by classpath, looking for subdirectories com\bruceeckel\util, Then look for the compiled file with the appropriate name (for vector is vector.class, for list is List.class). Note that both vectors and lists must be set to public, regardless of the class or required method.

1. When you automatically compile
the first time an object is created for an imported class (or when you access a static member of a Class), the compiler looks in the appropriate directory for the. class file of the same name (so if you create an object of Class X, it should be x.class). If you only find X.class, it is the class that must be used. However, if it finds a X.java in the same directory, the compiler compares the date tags of the two files. If the X.java is newer than X.class, the X.java is automatically compiled and a new x.class is generated. The
does this for a particular class, or if it is not found in a. java file with the same name as it.

2. Conflict
If two libraries are imported by * and they include the same name, what will happen? For example, suppose a program uses the following import statement:
import com.bruceeckel.util.*;
Import java.util.*
Because java.util.* also contains a vector class, So this could create a potential conflict. However, as long as the conflict does not really occur, there will be no problem-which is, of course, the ideal scenario, because otherwise there will be a lot of programming to prevent conflicts that may never happen.
If you try to generate a vector now, there is a certain conflict. as follows:
vector v = new vector ();
which vector is it referring to? The compiler has no answer to this question, nor can the reader know. So the compiler will report an error and force us to make a clear statement. For example, suppose I want to use a standard Java Vector, then I have to program like this:
Java.util.Vector v = new Java.util.Vector ();
Because it (together with classpath) specifies the position of the vector, the import java.util.* statement is no longer needed unless you want to use something else from java.util.