7.4 Package Declarations
7.4 包聲明
A package declaration appears within an ordinary compilation unit to indicate the package to which the compilation unit belongs.
出現在普通編譯單元中的package聲明表示該編譯單元歸屬的包。
7.4.1 Named Packages
7.4.1 具名包
A package declaration in an ordinary compilation unit specifies the name (§6.2) of the package to which the compilation unit belongs.
在普通編譯單元中的包聲明指定了該編譯單元所歸屬的包的名字（第6.2節）。
PackageDeclaration:
{PackageModifier} package Identifier {. Identifier} ;
PackageModifier: Annotation
The package name mentioned in a package declaration must be the fully qualified name of the package (§6.7).
在package聲明中提及的包名必須是該包的完全限定名（第6.7節）。
The scope and shadowing of a package declaration is specified in §6.3 and §6.4.
包聲明的作用域和遮蔽規則在第6.3節和第6.4節中進行了說明。
The rules for annotation modifiers on a package declaration are specified in §9.7.4 and §9.7.5.
針對包聲明上的註解修飾符的規則在第9.7.4節和第9.7.5節中進行了說明。
At most one annotated package declaration is permitted for a given package.
在給定的包上，最多隻允許有一個被註解的package聲明。
The manner in which this restriction is enforced must, of necessity, vary from implementation to implementation. The following scheme is strongly recommended for file-system-based implementations: The sole annotated package declaration, if it exists, is placed in a source file called package-info.java in the directory containing the source files for the package. This file does not contain the source for a class called package-info; indeed it would be illegal for it to do so, as package-info is not a legal identifier. Typically package-info.java contains only a package declaration, preceded immediately by the annotations on the package. While the file could technically contain the source code for one or more classes with package access, it would be very bad form.
強制遵循這個限制的方式必然會隨不同的實現而不同。下面的模式強烈推薦適用於基於文件系統的實現：單個被註解的package聲明，應置於名字爲package-info.java的文件中，而該文件在包含這個包的源文件的目錄中。這個文件並不包含被稱爲package-info的類的源代碼；實際上它並不是類的合法名字，因爲package-info不是合法的標識符。通常package-info.java只包含package聲明，其前面緊挨着這個包上的註解。儘管從技術上講，該文件可以包含一個或多個具有包訪問權限的類的源代碼，但是這是一種非常不好的形式。
It is recommended that package-info.java, if it is present, take the place of package.html for javadoc and other similar documentation generation systems. If this file is present, the documentation generation tool should look for the package documentation comment immediately preceding the (possibly annotated) package declaration in package-info.java. In this way, package-info.java becomes the sole repository for package-level annotations and documentation. If, in future, it becomes desirable to add any other package-level information, this file should prove a convenient home for this information.
推薦使用package-info.java來代替javadoc以及其他類似的文檔生成系統中的package.html。如果有該文件，那麼文檔生成工具就應該在package-info.java中查找緊挨着（可能被註解的）package聲明之前的包文檔註釋。在這種方式中，package-info.java變成了包級別的註解和文件的單一存儲池。如果將來它需要增加其他的包級別信息，那麼這個文件必須證明它是適合存儲這些信息的載體。
7.4.2 Unnamed Packages
7.4.2 不具名包
An ordinary compilation unit that has no package declaration is part of an unnamed package.
沒有任何package聲明的普通編譯單元是不具名包的一部分。
Unnamed packages are provided by the Java SE Platform principally for convenience when developing small or temporary applications or when just beginning development.
不具名包是Java SE平臺提供的一種機制，主要是爲了在開發小型或臨時應用，或者在剛剛開始開發時提供便捷方式。
An unnamed package cannot have subpackages, since the syntax of a package
declaration always includes a reference to a named top level package.
不具名包不能有子包，因爲package聲明的語法總是要包含對具名的頂層包的引用。
An implementation of the Java SE Platform must support at least one unnamed package. An implementation may support more than one unnamed package, but is not required to do so. Which ordinary compilation units are in each unnamed package is determined by the host system.
Java SE 平臺的實現必須至少支持一個不具名包，它也可以支持多個不具名包，但是這並不是強制要求的。在每個不具名包中包含哪些普通編譯單元是由主機系統決定的。
The host system must associate ordinary compilation units in an unnamed package with an unnamed module (§7.7.5), not a named module.
主機系統必須將不具名包中的普通編譯單元與不具名模塊（第7.7.5節）而不是具名模塊關聯。
Example 7.4.2-1. Unnamed Package
例子 7.4.2-1. 不具名包
The compilation unit:
編譯單元：
class FirstCall {
public static void main(String[] args) {
System.out.println("Mr. Watson, come here. "
+ "I want you.");
}
}defines a very simple compilation unit as part of an unnamed package.
定義了一個非常簡單的編譯單元，作爲不具名包的一部分。
In implementations of the Java SE Platform that use a hierarchical file system for storing packages, one typical strategy is to associate an unnamed package with each directory; only one unnamed package is observable at a time, namely the one that is associated with the “current working directory”. The precise meaning of “current working directory” depends on the host system.
在使用層次結構的文件系統來存儲包的Java SE平臺的實現中，一種典型的策略是將不具名包與每個目錄相關聯，在任意時刻，只有一個不具名包是可觀察的，即與“當前工作目錄”相關聯的包。“當前工作目錄”的準確含義依賴於主機系統。
7.4.3 Package Observability and Visibility
7.4.3 包的可觀察性和可見性
A package is observable if and only if at least one of the following is true:
當且僅當以下至少一種情況爲真時，包是可觀察的：
• An ordinary compilation unit containing a declaration of the package is observable (§7.3).
• 包含包的聲明的某個普通編譯單元是可觀察的（第7.3節）。
• A subpackage of the package is observable.
• 包的某個子包是可觀察的。
The packages java, java.lang, and java.io are always observable.
包java、java.lang和java.io總是可觀察的。
One can conclude this from the rule above and from the rules of observable compilation units, as follows. The predefined package java.lang declares the class Object, so the compilation unit for Object is always observable (§7.3). Hence, the java.lang package is observable, and the java package also. Furthermore, since Object is observable, the array type Object[] implicitly exists. Its superinterface java.io.Serializable (§10.1) also exists, hence the java.io package is observable.
我們可以從上述規則以及可觀察編譯單元的規則中得出下面的結論。預定義包java.lang聲明瞭類Object，因此Object的編譯單元總是可觀察的（第7.3節），因此，java.lang包是可觀察的，而java包也是如此。更進一步，由於Object是可觀察的，因此數組類型Object[]隱式地也是如此，它的超接口java.io.Serializable（第10.1節）也是如此，因此java.io包也是可觀察的。
A package is visible to a module M if and only if an ordinary compilation unit containing a declaration of the package is visible to M.
當且僅當一個包含對包的聲明的普通編譯單元對模塊M是可見的時，包纔對模塊M可見。
Package visibility is meant to imply that a package is “really” observable in some module on the system. It is not useful to think that package P is “technically” observable just because a subpackage P.Q is “technically” observable in some module. For example, suppose P.Q is “technically” observable in module M1 and P.R is “technically” observable in module M2; then, P is “technically” observable, but in M1 or M2 or both? During the compilation of some module N that requires M1 only, it matters that P.Q is “really” observable, and it does not matter that P is “technically” observable.
包的可見性意味着包在系統的某些模塊上是“真實”可觀察的。但這不助於理解包P是“技術上”可觀察的，僅僅是因爲P的子包P.Q在某些模塊中是“技術上”可觀察的。例如，假設P.Q在模塊M1上是“技術上”可觀察的，而P.R在模塊M2上是“技術上”可觀察的；那麼，P是“技術上”可觀察的，但是是在M1還是M2還是兩者上呢？在編譯某些只需要M1的模塊N時，重要的是P.Q是“真實”可觀察的，而P是“技術上”可觀察的並不重要。
A package is uniquely visible to a module M if and only if one of the following holds:
當且僅當以下情況之一成立時，包對模塊M是唯一可見的：
• An ordinary compilation unit associated with M contains a declaration of the package, and M does not read any other module that exports the package to M.
• 與模塊M相關聯的普通編譯單元包含包的聲明時，模塊M不會讀取將包指定爲導出到M的任何其他模塊。
• No ordinary compilation unit associated with M contains a declaration of the package, and M reads exactly one other module that exports the package to M.
• 沒有與模塊M相關聯的普通編譯單元包含包的聲明時，模塊M會完全讀取將包指定爲導出到M的其他模塊。