Package info java для чего она нужна
Table of Contents
Programs are organized as sets of packages. Each package has its own set of names for types, which helps to prevent name conflicts.
A top level type is accessible (§6.6) outside the package that declares it only if the type is declared public .
The naming structure for packages is hierarchical (§7.1). The members of a package are class and interface types (§7.6), which are declared in compilation units of the package, and subpackages, which may contain compilation units and subpackages of their own.
A package can be stored in a file system or in a database (§7.2). Packages that are stored in a file system may have certain constraints on the organization of their compilation units to allow a simple implementation to find classes easily.
A package consists of a number of compilation units (§7.3). A compilation unit automatically has access to all types declared in its package and also automatically imports all of the public types declared in the predefined package java.lang .
For small programs and casual development, a package can be unnamed (§7.4.2) or have a simple name, but if code is to be widely distributed, unique package names should be chosen using qualified names. This can prevent the conflicts that would otherwise occur if two development groups happened to pick the same package name and these packages were later to be used in a single program.
7.1. Package Members
The members of a package are its subpackages and all the top level class types (§7.6, §8 (Classes)) and top level interface types (§9 (Interfaces)) declared in all the compilation units (§7.3) of the package.
For example, in the Java SE platform API:
The package java has subpackages awt , applet , io , lang , net , and util , but no compilation units.
The package java.awt has a subpackage named image , as well as a number of compilation units containing declarations of class and interface types.
If the fully qualified name (§6.7) of a package is P , and Q is a subpackage of P , then P.Q is the fully qualified name of the subpackage, and furthermore denotes a package.
A package may not contain two members of the same name, or a compile-time error results.
Here are some examples:
Because the package java.awt has a subpackage image , it cannot (and does not) contain a declaration of a class or interface type named image .
If there is a package named mouse and a member type Button in that package (which then might be referred to as mouse.Button ), then there cannot be any package with the fully qualified name mouse.Button or mouse.Button.Click .
If com.nighthacks.java.jag is the fully qualified name of a type, then there cannot be any package whose fully qualified name is either com.nighthacks.java.jag or com.nighthacks.java.jag.scrabble .
It is however possible for members of different packages to have the same simple name. For example, it is possible to declare a package:
that has as a member a public class named Vector , even though the package java.util also declares a class named Vector . These two class types are different, reflected by the fact that they have different fully qualified names (§6.7). The fully qualified name of this example Vector is vector.Vector , whereas java.util.Vector is the fully qualified name of the Vector class included in the Java SE platform. Because the package vector contains a class named Vector , it cannot also have a subpackage named Vector .
The hierarchical naming structure for packages is intended to be convenient for organizing related packages in a conventional manner, but has no significance in itself other than the prohibition against a package having a subpackage with the same simple name as a top level type (§7.6) declared in that package.
For example, there is no special access relationship between a package named oliver and another package named oliver.twist , or between packages named evelyn.wood and evelyn.waugh . That is, the code in a package named oliver.twist has no better access to the types declared within package oliver than code in any other package.
7.2. Host Support for Packages
Each host system determines how packages and compilation units are created and stored.
Each host system also determines which compilation units are observable (§7.3) in a particular compilation. The observability of compilation units in turn determines which packages are observable, and which packages are in scope.
In simple implementations of the Java SE platform, packages and compilation units may be stored in a local file system. Other implementations may store them using a distributed file system or some form of database.
If a host system stores packages and compilation units in a database, then the database must not impose the optional restrictions (§7.6) on compilation units permissible in file-based implementations.
For example, a system that uses a database to store packages may not enforce a maximum of one public class or interface per compilation unit.
Systems that use a database must, however, provide an option to convert a program to a form that obeys the restrictions, for purposes of export to file-based implementations.
As an extremely simple example of storing packages in a file system, all the packages and source and binary code in a project might be stored in a single directory and its subdirectories. Each immediate subdirectory of this directory would represent a top level package, that is, one whose fully qualified name consists of a single simple name. Each further level of subdirectory would represent a subpackage of the package represented by the containing directory, and so on.
The directory might contain the following immediate subdirectories:
where directory java would contain the Java SE platform packages; the directories jag , gls , and wnj might contain packages that three of the authors of this specification created for their personal use and to share with each other within this small group; and the directory com would contain packages procured from companies that used the conventions described in §6.1 to generate unique names for their packages.
Continuing the example, the directory java would contain, among others, the following subdirectories:
corresponding to the packages java.applet , java.awt , java.io , java.lang , java.net , and java.util that are defined as part of the Java SE platform API.
Still continuing the example, if we were to look inside the directory util , we might see the following files:
where each of the .java files contains the source for a compilation unit (§7.3) that contains the definition of a class or interface whose binary compiled form is contained in the corresponding .class file.
Under this simple organization of packages, an implementation of the Java SE platform would transform a package name into a pathname by concatenating the components of the package name, placing a file name separator (directory indicator) between adjacent components.
For example, if this simple organization were used on an operating system where the file name separator is / , the package name:
would be transformed into the directory name:
A package name component or class name might contain a character that cannot correctly appear in a host file system’s ordinary directory name, such as a Unicode character on a system that allows only ASCII characters in file names. As a convention, the character can be escaped by using, say, the @ character followed by four hexadecimal digits giving the numeric value of the character, as in the \u xxxx escape (§3.3).
Under this convention, the package name:
which can also be written using full Unicode as:
might be mapped to the directory name:
If the @ character is not a valid character in a file name for some given host file system, then some other character that is not valid in a identifier could be used instead.
Scenes
Learn spring-kafka When opening source code, I found that each directory has a package-info.java File, find its usage, and sort it out.
surroundings
| software | version |
|---|---|
| spring-boot | 2.1.8.RELEASE |
| spring-kafka | 2.2.8.RELEASE |
| JDK | 8 |
| intellij idea | 2019.1 |
Introduction
package-info.java Is an Java File, you can put it in any Java Source code package execution. However, the content inside has specific requirements, and its main purpose is to provide package-level related operations, such as package-level annotations, comments, and public variables.
1. Provide package-level annotations
Introduction
Provide package-level annotations in the corresponding source code package
Sample
Create package annotation
in package-info.java Add comment
View the comments of the corresponding package
The result is as follows. Only the annotation of the corresponding package is output, and the class inside the package does not have the annotation.
Use of Deprecated annotations
If an entire package is out of date, you can directly package-info.java Next, add a comment @Deprecated , Which means that the source code package is out of date. As shown: 
Two, provide package-level variables
Introduction
If you want to use the corresponding variable in the package, but don’t want other packages to use it, you can put the variable in package-info.java Below, realize Subcontract for own use Concept.
Sample
in package-info.java Add the following content:
Call the package constant in any class in the package without error:
Screenshot below: 
Call package constants in any class outside the package, prompting an error:
Screenshot below: 
Three, provide package-level notes
Introduction
use JavaDoc When, through package-info.java Add comments, generate JavaDoc Implement the annotation description of the corresponding package.
Sample
Add a comment for the corresponding package
Generate corresponding JavaDoc The document, the screenshot is as follows:
click component The link, the screenshot is as follows: 
to sum up
When learning open source code, I saw package-info.java , I don’t know why, I deliberately find materials to learn and summarize. When we are learning open source source code, we can learn a lot of things, and we are constantly supplementing our knowledge blind spots. However, you should also take more notes and ask yourself why, so as to "know the reason" and fight steadily.
Ask for praise
If my article is helpful to everyone, you can click like or favorite at the bottom of the article;
If there is a good discussion, you can leave a message;
If you want to continue to view my future articles, you can click Follow in the upper left corner 
The package-info.java File
Navigating the complexities of Spring can be difficult, even for seasoned developers.
If you need direct, practical help and guidance with your own Spring work, Trifork’s CTO, Joris Kuipers, is running a closed-door call.
It’s free, but it’s limited to only 3 seats, so if you need it, I would join quickly and be sure to attend:
With more than 15 years of leading custom software development projects involving Spring, Joris has gained a lot of real-world experience, and this call is about sharing and helping the community.
Building or modernizing a Java enterprise web app has always been a long process, historically. Not even remotely quick.
That’s the main goal of Jmix is to make the process quick without losing flexibility — with the open-source RAD platform enabling fast development of business applications.
Critically, it has very minimal impact on your server’s performance, with most of the profiling work done separately — so it needs no server changes, agents or separate services.
Simply put, a single Java or Kotlin developer can now quickly implement an entire modular feature, from DB schema, data model, fine-grained access control, business logic, BPM, all the way to the UI.
Jmix supports both developer experiences – visual tools and coding, and a host of super useful plugins as well:
Slow MySQL query performance is all too common. Of course it is. A good way to go is, naturally, a dedicated profiler that actually understands the ins and outs of MySQL.
The Jet Profiler was built for MySQL only, so it can do things like real-time query performance, focus on most used tables or most frequent queries, quickly identify performance issues and basically help you optimize your queries.
Critically, it has very minimal impact on your server’s performance, with most of the profiling work done separately — so it needs no server changes, agents or separate services.
Basically, you install the desktop application, connect to your MySQL server, hit the record button, and you’ll have results within minutes:
The Kubernetes ecosystem is huge and quite complex, so it’s easy to forget about costs when trying out all of the exciting tools.
To avoid overspending on your Kubernetes cluster, definitely have a look at the free K8s cost monitoring tool from the automation platform CAST AI. You can view your costs in real time, allocate them, calculate burn rates for projects, spot anomalies or spikes, and get insightful reports you can share with your team.
Connect your cluster and start monitoring your K8s costs right away:
Why is package-info.java useful?
When I run CheckStyle over my Java project it says Missing package-info.java file. for some classes, but not all of them. I can’t really figure out why this message appears only sometimes. Furthermore my project runs perfectly fine without the package-info.java.
What does the package-info.java do? Do I really need it for my Java projects?
5 Answers 5
It is used to generate javadocs for a package.
Will generate package info for com.domain package:
Annotations
Another good reason to use package-info.java is to add default annotations for use by FindBugs. For instance, if you put this in your package-info file:
then when findbugs runs on the code in that package, all methods and fields are assumed to be non-null unless you annotate them with @CheckForNull . This is much nicer and more foolproof than requiring developers to add @NonNull annotations to each method and field.
Not only some findbugs annotations, but a lot of java annotations in common libraries have the java.lang.annotation.ElementType.PACKAGE type as one of the possible values of their own java.lang.annotation.Target annotation, e.g.:
This package-info.java file would be the file, where you can place such annotations (along with the javadoc).
A package-info.java file allows adding javadoc to document a whole package. See http://docs.oracle.com/javase/7/docs/api/java/applet/package-summary.html for example.
If you don’t care about missing package documentation, then ignore the warning or disable the JavadocPackage check.
The package-info.java is a Java file that can be added to any Java source package. It is used to provide info at a «package» level as per its name. It contains documentation and annotations used in the package.
javadoc example is already provided in the answer, the below part explains how it works incase of annotations.