Detailed Java programming package package content and package object specification

  • 2020-04-01 04:32:40
  • OfStack

The contents of the package
The contents of a package should be carefully designed to contain only functionally relevant classes and interfaces. Classes in the package are free to access non-private members of other classes in the package, and some classes may even have sufficient permissions to access the internal details of other classes. In order to prevent such classes from mistakenly manipulating class members, we need to protect class members. Any member that is not declared private can be accessed by all other types in the same package, so the degree of coupling between any unrelated classes is likely to be higher than expected.

Packages also provide logical grouping for programmers looking for useful interfaces and classes. Packages of unrelated classes make it difficult for programmers to tell which interfaces and classes are useful, and logical grouping of classes helps programmers reuse code because programmers can find what they need more easily through logical grouping. If the package contains only a set of related, compactly coupled types, that means we can give the types more intuitive names to avoid name collisions.

Packages can be nested. For example, java.lang is a nested package, where the package lang is nested in the larger package Java, while the package java contains several other packages. Nesting causes related packages to form a hierarchical naming system.

For example, to create a set of packages for adaptive systems such as neural networks and genetic algorithms, we can create nested packages by naming packages with polka-dotted names:


  package adaptive. neural Net;

The source file containing the above declaration is in the adaptive. NeuralNet package, which is itself a child of the adaptive package. The adaptive package may contain classes related to generic adaptive algorithms, such as the generalization problem statement class or benchmark class. Packages that are deeper in the hierarchy (such as adaptive. Neu-ralnet or adaptive. Genetic) contain classes related to a particular type of adaptive algorithm.

Package nesting is simply a tool for organizing related packages and does not provide any special access between packages.

The class code in the adaptive. Genetic package cannot access adaptive or the members of the adaptive. NeuralNet package that have package access, and the package scope only applies to specific packages. The nesting of packages provides no benefit beyond the ability to group related packages and help the programmer find the desired class more easily at the logical level.

Package of annotation

Packages can also be annotated. The problem, however, is that because packages are an organizational structure, there are no source code entities, and they have no actual definition, they cannot be annotated like classes or methods, so they can only be annotated by annotating the package's declaration statements in the source file. However, only one package declaration in each package can have annotations that act on it.

So how exactly do you annotate packages? In fact, the Java language does not force programmers to handle the "single-annotated package statement" rule in a certain way. The recommended approach is to create a file called package-i nfo.java in the package directory, where you store only the package statements and annotations for the package, and nothing 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 one source")

  package attr;

One Packagespec Developmentsite and Devel opmentmodel used to modify annotation types, of course, they have the runtime of the strategy. The package-info.java file should be compiled with the other source files in the package.

We recommend that all package-related information be placed in the package-info.java file. If you do this, then you can place a document comment at the beginning of the file so that the document is commented into a package document.

Package objects and specifications
Packages usually implement some specification and are usually from an organization. Unlike other reflection types, the Package object cannot be used to create or manipulate packages, but can only serve as a repository for information about the specification the Package implements (the specification title, vendor, and version number) and about the Package implementation itself (the Package title, vendor, and version number). Although a package usually comes from a single organization, it may implement specifications (such as a statistical analysis library) that have been defined by other organizations. A program that USES a package may need to know the version of the specification that the package implements so that it can use functionality that is defined only in one version. Similarly, these programs may also need to know which implementation version is being provided to them, primarily to address possible defects 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, or null if the title is unknown, .public string getspecificationversion(): returns a string describing the version information of the specification implemented by the package, or null if the version information is unknown. .public string getspecificationvendor Q: returns the name of the vendor that owns and maintains the specification implemented by the package, returns null if the vendor is unknown, .public string getImplerentationTitle(): returns the title of the implementation provided by the package, null if the title is unknown. , public string getImplementationvendor(): returns the name of the organization (vendor) that provided the implementation, or null if the organization is unknown,

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


  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 specification version number consists of non-negative digits separated by a period separator, such as' '2.0 "or" 11.0.12". This pattern allows us to call the iscompatiblewith method to compare the version number that follows the pattern with the version number of the package. This method returns true if the package version number is greater than or equal to the propagator version number. This comparison compares only one number separated by a period at a time, and if any of these Numbers is less than the value of the corresponding position in the version number passed in, the two versions are incompatible. If one version number is longer than the other, the missing part of the short version number is considered to be zero. For example, if the package's specification version number is "1.4" and we use the iscompatiblewith method to compare it with" 1.2","1.3.1'. Or "1.81. However, if compared to "1.4.2" or ".5", false is returned. This is because the comparison mechanism assumes that the specification version is backward compatible.

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

Packages can be sealed, which means you can't add classes to the package. An unsealed package can contain classes from several different locations in the class search path, and 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: returns trueo if the package issealed

.public Boolean issealed(URL URL): returns true if the package issealed for a given URL, that is, the classes in the package can be loaded from the given URL. If the class in the package can't from the given URL to load, or package is not sealed, it returns false, the specification and implementation of the package information is usually as stored together with the package part of the listing of files and provide - for example as a Java archive (jar) part of the listing of files, like 25.9.2 section "archive Java. Util. Jar" described in it. This information is read when the classes in the package are loaded. ClassLoader can dynamically define a Package object for the class it loads:

We can call the getPackage method of the Class object of a given Class to obtain the Package object of that Class. We can also call the static package.getpackage with the given Package name to get the Package object, or the static package.getpackages, which will return an array of packages that are currently known to the class loader. Both of these methods are related to the classloader that calls their code, because the code will call the get-package or getPackages methods of its classloader. The methods of these classloaders search for a particular classloader and all of its superloaders, and if nothing is set for the current classloader, then the system classloader is used. Note that if the package is unknown, the classloader method returns null because no type in the package has been loaded yet.


Related articles: