Detailed explanation of the content of package package and package object specifications in Java programming

Package content
The contents of the package should be carefully designed so that they only include functionally relevant classes and interfaces. Classes in the package can freely access non-private members of other classes in the package, and some classes may even have sufficient permissions to access internal details of other classes. In order to avoid such classes from misoperating class members, we need to protect class members. Any member not declared as private can be accessed by all other types in the same package, so any unrelated classes may be more likely to be more coordinated than we would expect.

Packages also provide logical grouping for programmers looking for useful interfaces and classes. Packages composed of irrelevant classes make it difficult for programmers to tell which interfaces and classes are useful, and logical grouping of classes can help programmers reuse code because programmers can find what they need more easily through logical grouping. If the package only contains related, tightly coupled type sets, it means that we can give the type some more intuitive names to avoid name conflicts.

Packages can be nested. For example, java.lang is a nested package where the package Lang is nested in larger package java, while the package j ava also contains some other packages. Nesting makes the related packages form a naming system with hierarchical structure.

For example, to create a set of packages for adaptive systems such as neural networks and genetic algorithms, we can name packages with dot-separated names to create nested packages:

 package adaptive. neural Net;

The source file containing the above declaration statement is located in the adaptive.neuralNet package, and the adaptive.neuralNet package itself is a subpackage of the adaptive package. The adaptive package may contain some classes related to general adaptive algorithms, such as generalization problem statement classes or benchmark classes. Packages that are in a deeper position in the hierarchy (eg adaptive.neu-ralNet or adaptive.genetic) contain classes related to a specific type of adaptive algorithm.

The nesting of packages is just a tool for organizing related packages, and it does not provide any special access rights between packages.

The class code in the adaptive.genetic package cannot access the members in the adaptive or adaptive.neuralNet package that have package access rights, and the package scope is only applicable to specific packages. The nesting of packages can group relevant packages and help programmers find the desired class in the logical level more conveniently, but beyond that, it does not bring any other benefits.

Package notes

The package can also have annotations. But the problem is that since packages are an organizational structure and do not have source code entities and they have no actual definition, they cannot be annotated like classes or methods. Therefore, package annotation can only be achieved by annotating the package's declaration statement in the source file. However, there can only be one package declaration in each package that can have annotations that act on it.

So how do you annotate packages? In fact, Java does not force programmers to use some way to deal with the "single annotated package statement" rule. The recommended way is to create a file named package-i nfo.java in the package directory, in which only the package statements and the annotations of the package are stored without placing anything else. For example, the package info.java file for the attr package looks like this:

 @PackageSpec(name two"Attr Project", version="1.0" @DevelopmentSite("attr.project.org") @DevelopmentModel("open-source") package attr;

Packagespec, Developmentsite and Development opmentmodel are used to modify annotation types. Of course, they have runtime saving strategies. package-info.java file should be compiled with other source files in the package.

We recommend placing all package-related information in the package-info.java file. If you do this, you can place document comments at the beginning of the file, so that these documents are annotated as package documents.

Package Objects and Specifications
Packages usually implement some specification, and are usually from an organization. Package objects are different from other reflection types and cannot be used to create or operate packages, but can only serve as a knowledge base for providing information, which provides information about the specifications implemented by the package (the title, vendor and version number of the specification) and information about the implementation of the package itself (the title, vendor and version number of the package). Although packages usually come from individual organizations, the specifications it implements (such as statistical analysis libraries) may be defined by other organizations. Programs using packages may need to know the version of the specification implemented by the package, so that functions defined only in a certain version can be used. Similarly, these programs may also need to know which implementation version is provided to it, mainly to deal with possible flaws in different versions. Some of the main methods of the Package class allow access to this information:

• ・public Stri ng getName (): Returns the name of the package.
• .public string getspecificationTitle p: Returns the title of the specification implemented by the package. If the title is unknown, return null,
• .public string getspecificationversion(): Returns a string describing the version information of the specification implemented by the package. If the version information is unknown, return null,
• .public string getspecificationvendor Q: Returns the name of the supplier, which owns and maintains the specifications implemented by the package. If the supplier is unknown, return null,
• .public string getImplerentationTitle(): Returns the title of the implementation provided by the package. If the title is unknown, it returns null, ・public string getImplementationversion(): Returns a string describing the version information of the implementation provided by the package. If the version information is unknown, it returns null,
• ・public string getImplementationvendor(): Returns the name of the organization (vendor) that provides the implementation. If the organization is unknown, return null,

For example, if you extract this information from the java.lang package in our system, you will get the following results:'

 Specification Title: Java Platform API Specification Specification Version: 1.4 Specification Vendor:Sun Microsystems, Inc. Implementation Title:Java Runtime Environment Implementation Version:1.5.0_02 Implementation Vendor: Sun Microsystems, Inc.

The canonical version number consists of non-negative numbers separated by period delimiters, such as ''2.0'' or '11.0.12'. This pattern allows us to call the iscompatiblewith method to compare the version number that follows this pattern with the version number of the package. If the version number of the package is greater than or equal to the version number of the successor, then the method returns true. This comparison only compares a period-separated number at a time. If any of these numbers is smaller than the corresponding position in the passed version number, then the two versions are incompatible. If one of the version numbers is longer than the other, the missing part in the short version numbers will be considered zero. For example, if the package's canonical version number is "1.4" and we compare it with "1.2", "1.3.1'. or ".1.81., then true will be returned; but if compared with "1.4.2'. or ".5", then false will be returned. This conclusion is drawn because this comparison mechanism assumes that the specification version is backward compatible.

There is no specified format for the implementation version number, because different organizations that provide the implementation will define the implementation version differently. The only comparison that can be made between implementation versions is to test whether the version is the same, where there is no assumption of backward compatibility.

The package can be sealed, which means that classes can no longer be added to the package. Unsealed packages can contain classes from multiple different locations in the class search path, while the contents of the sealed package must come from the same location—either a specific archive or a location specified by a URL. There are two ways to determine if a package is sealed:

.public boolean issealed p: Return trueo if the package is sealed

.public boolean issealed(URL url): Return true if the package is sealed for the given URL, that is, the classes in the package can be loaded from this given URL. If the class in the package cannot be loaded from the given URL, or the package is not sealed, then false is returned, and the specification and implementation information of the package are usually provided as part of the manifest file stored with the package - for example as part of the manifest file in a Java archive (jar), as described in Section 25.9.2, “Archive file java.util.jar”. When a class in a package is loaded, this information is read by the person. A ClassLoader can dynamically define a Package object for the class it wants to load:

We can call the getPackage method of the Class object of the given class to get the Package object of this class. We can also call the static Package.getPackage with the given package name to get the Package object, or call the static Package.getPackages, which will return the Package array composed of all packages currently known to the class loader. Both methods are related to the class loader that calls their code, because these codes will call the get-Package or getPackages methods of their class loader. These class loaders' methods will search for a specific class loader and all its parent class loaders, and if no settings are made for the current class loader, the system class loader will be used at this time. Note that if the package is unknown, the classloader method will return null because no type in the package has been loaded at this time.