JAR 文件规范详解
奇技 · 指南
JAR文件是基于ZIP文件格式的一种文件格式，用来将许多文件整合成一个文件。一个JAR文件本质上是包含可选目录META-INF的zip文件，可以通过命令行jar工具或者在Java平台上使用java.util.jar中的API来创建。JAR文件的命名没有严格的要求，可以是特定平台上的任意合法文件名称。
在很多场景中，JAR文件不仅仅用来对java class文件和资源文件进行归档，还被用来作应用程序及其扩展的构建块。如果包含META-INF目录，则是用来存储包信息和扩展配置数据，配置数据包括安全信息，版本控制信息，扩展信息和服务信息等。
META-INF目录
在Java 2平台会识别和解释META-INF目录下面的文件和目录，以配置应用程序、扩展、类加载器和服务。
MANIFEST.MF是用来定义扩展和包相关数据的清单文件。
INDEX.LIST通过jar工具的-i选项来生成，它包含应用程序及其扩展程序中的包的位置信息，同时它是JarIndex实现的一部分，类加载器使用它来提高类的加载速度。
x.SF 是JAR文件的签名文件，x表示基本文件名称。
x.DSA 是于x.SF关联的签名块文件，它们有相同的基本文件名。此文件存储相应签名文件的数字签名。
services/ 该目录存储所有服务提供程序配置文件。
名称-值对和节
在我们深入每个配置文件的细节之前，需要定义一些格式约定。
在大部分场景中，包含在清单文件和签名文件中的信息表示为受RFC822标准启发的所谓的“名称:值”对。“名称:值”对也被称为头和属性。名称-值对组称为“节”，每一“节”通过空行分离。
任何形式的二进制数据都表示为base64。行的长度超过72字节的二进制数据需要延续。摘要和签名就是二进制数据的例子。
实现应该最多支持65535字节的头值。
本文档中的所有规范使用相同的语法，其中终端符号以固定宽度字体显示，非终端符号以斜体字体显示。
节规范：
p: *header +newline
nonempty-p: +header +newline
newline: CR LF | LF | CR (not followed by LF)
header: name : value
name: alphanum *headerchar
value: SPACE *otherchar newline *continuation
continuation: SPACE *otherchar newline
alphanum: {A-Z} | {a-z} | {0-9}
headerchar: alphanum | - | _
otherchar: any UTF-8 character except NUL, CR and LF
;Also: To prevent mangling of files sent via straight e-mail, no
;header will start with the four letters "From".
上述规范中定义的非终端符号将在以下规范中引用。
JAR Manifest
概述
JAR文件的清单由主节和拥有多个私有JAR文件条目的单独节列表，每行通过换行符分隔。主节和单独节都遵循上面指定的节语法。它们都有自己特定的限制和规则。
主节包括包括JAR文件自身的安全和配置信息，以及此JAR文件所属应用程序及扩展。清单文件同样定义了每个单独清单条目的主属性。每节中没有属性可以使用“Name”作为名称。每一节通过空行结束。
单独节定义了JAR文件中包和文件的各种属性。不是所有在JAR文件中的文件都需要被作为条目列在清单中，但是所有被签名的文件必须被列出。清单文件自身不需要被列出。每节必须以名称“Name”的属性作为开始，并且值必须是该文件的的相对路径或者是应用存档外部数据的绝对URL。
如果相同条目有多个单独节，则这些单独节中的属性会被合并。如果不同节中的相同属性有不同的值，则识别最后一个。
不理解的属性会被忽略。这些属性可能包含应用程序使用的实现特定信息。
清单文件规范
manifest-file: main-p newline *individual-p
main-p: version-info newline *main-attribute
version-info: Manifest-Version : version-number
version-number : digit+{.digit+}*
main-attribute: (any legitimate main attribute) newline
individual-p: Name : value newline *perentry-attribute
perentry-attribute: (any legitimate perentry attribute) newline
newline : CR LF | LF | CR (not followed by LF)
digit: {0-9}
在上面的规范中，可以出现在主节中的属性称为主属性，而可以出现在单独部分的属性称为每个条目的属性。某些属性可以同时出现在主节和单独节中，在这种情况下，每个条目的属性值会覆盖指定条目的主属性值。这两种类型的属性定义如下。
主属性
主属性是清单中出现在主节中的属性。他们可以分为以下几类：
① 一般主属性
Manifest-Version： 定义清单版本。如上面规范所述，值是何方的版本号
Create-By： 定义生成此清单文件的java实现版本和供应商。该属性由jar工具生成。
Signature-Version： 定义jar文件的签名版本。该值应该是一个有效的版本号字符串。
Class-Path： 此属性的值指定此应用程序或扩展所需的扩展名或依赖库的相对url。url由一个或多个空格分隔。应用程序或扩展类加载器使用此属性的值来构造其内部搜索路径。参见Class-Path属性。
② 为独立应用程序定义的属性
这个属性被捆绑到可执行jar文件中的独立应用程序使用，java运行时可以通过运行“java -jar x.jar”直接调用这些可执行jar文件。
Main-class：此属性的值是启动程序在启动时加载的主应用程序类的类名。该值不能将.class扩展追加到类名。
③ 为applet定义的属性
弃用:这些属性和实现它的机制可能会在未来的版本中被删除。这些属性被绑定到JAR文件中的applet使用，以定义该applet所依赖的扩展的需求、版本和位置信息。
Extension-List: 此属性指示applet需要的扩展。此属性中列出的每个扩展都有一组附加属性，applet使用这些属性来指定需要的扩展的版本和供应商。
-Extension-Name： 此属性是扩展的唯一名称。Java插件将此属性的值与已安装扩展清单中的extension - name属性进行比较，以确定是否安装了该扩展。
-Specification-Version： 该属性指定了applet所需的最小扩展规范版本。Java插件将比较此属性的值与已安装扩展的Specification-Version属性，以确定该扩展是否是最新的。
-Implementation-Version： 这个属性指定了applet所需要的最小扩展实现版本号。Java插件将比较此属性的值与已安装扩展的实现版本属性，以查看是否需要下载更近期的实现。
-Implementation-Vendor-Id: 如果applet需要来自特定厂商的实现，则此属性可用于标识扩展实现的厂商。Java插件将此属性的值与已安装扩展的Implementation-Vendor-Id属性进行比较。
-Implementation-URL: 此属性指定一个URL，如果尚未安装所需的扩展版本，则可以使用该URL获取扩展的最新版本。
④ 为扩展标识定义的属性
扩展使用此属性定义其惟一标识。
Extension-Name: 此属性指定Jar文件中包含的扩展名的名称。名称应该是唯一的标识符，如包含扩展的主包的名称。
⑤ 为扩展、包版本和封装信息定义的属性
这些属性定义了JAR文件所属的扩展的特性。这些属性的值适用于JAR文件中的所有包，但是可以被每个条目的属性覆盖。
Implementation-Title： 值是定义扩展实现标题的字符串。
Implementation-Version： 值是定义扩展实现版本的字符串。
Implementation-Vendor： 值定义维护扩展实现的供应商。
Implementation-Vendor-Id: 值是一个字符串id，惟一地定义了维护扩展实现的供应商。这个属性可能在将来的版本中被忽略。
Implementation-URL: 此属性定义可从其中下载扩展实现的URL。这个属性可能在将来的版本中被忽略。
Specification-Title： 值是定义扩展规范标题的字符串。
Specification-Version: 值是定义扩展规范版本的字符串。
Specification-Vendor: 值是一个字符串，它定义维护扩展规范的供应商。
Sealed： 这个属性定义了这个JAR文件是否是密封的。值可以是“true”或“false”，大小写被忽略。如果它被设置为“true”，那么JAR文件中的所有包默认都是密封的，除非它们分别被定义。
每个条目的属性
每个条目的属性只应用于与清单条目相关联的单个JAR文件条目。如果同一属性也出现在主节中，那么每个条目属性的值将覆盖主属性的值。例如，如果JAR文件a.jar有以下清单内容:
Manifest-Version: 1.0
Created-By: 1.2 (Sun Microsystems Inc.)
Sealed: true
Name: foo/bar/
Sealed: false
这意味着归档在a.jar中的所有包都是密封的，除了包foo.bar不是。
每个条目的属性分为以下几组:
① 定义文件内容的属性
Content-Type：此属性可用于指定JAR文件中特定文件条目的MIME类型和数据子类型。值应该是type/subtype形式的字符串。
例如，“image/bmp”是一个带有bmp(表示位图)子类型的图像类型。这将把文件条目指示为图像，并将数据存储为位图。RFC 1521和1522讨论并定义MIME类型。
② 定义版本和封装信息的属性
这些属性与上面定义的用于定义扩展包版本控制和封装信息的主属性相同。当作为每个条目属性使用时，这些属性将覆盖主属性，但仅应用于清单条目指定的单个文件。
③ 定义bean对象的属性
Java-Bean: 定义特定的jar文件条目是否是Java bean对象。值应该是“true”或“false”，大小写被忽略。
④ 定义签名的属性
这些属性用于签名和验证目的。更多细节在这里。
x-Digest-y:此属性的名称指定用于计算对应jar文件条目的摘要值的摘要算法的名称。此属性的值存储实际的摘要值。前缀'x'指定算法名称，可选后缀'y'表示应该根据哪种语言验证摘要值。
Magic: 这是一个可选属性，应用程序可以使用它来指示verifier应该如何计算清单项中包含的摘要值。这个属性的值是一组逗号分隔的上下文特定字符串。
签名的JAR文件
概述
可以使用命令行jarsigner工具或直接通过 java.security API对JAR文件进行签名。如果JAR文件是由jarsigner工具签名的，那么每个文件条目(包括META-INF目录中与非签名相关的文件)都将被签名。签名的相关文件有:
META-INF/MANIFEST.MF
META-INF/*.SF
META-INF/*.DSA
META-INF/*.RSA
META-INF/SIG-*
注意，如果这些文件位于META-INF子目录中，则不认为它们与签名相关。这些文件名（不区分大小写）的版本会被保留，也不会被签名。
可以使用java.security API对JAR文件的子集进行签名。签名JAR文件与原始JAR文件完全相同，除了它的清单被更新和两个附加文件被添加到META-INF目录:一个签名文件和一个签名块文件。如果不使用jarsigner，签名程序必须同时构造签名文件和签名块文件。
对于签名JAR文件中的每个文件条目，会在清单文件中为它创建一个单独的清单条目。每个清单条目列出一个或多个摘要属性和一个可选的Magic属性。
签名文件
每个签名者都由一个扩展名为. sf的签名文件表示。该文件的主要部分与清单文件类似。它由一个主要节组成，其中包含签名者提供的信息，但并不特定于任何特定的jar文件条目。除了签名版本（Signature-Version）和创建属性（Created-By，参见主属性)，主节还可以包括以下安全属性:
x-Digest-Manifest-Main-Attributes： 其中x是java.security.MessageDigest算法的标准名称，此属性的值是清单文件的主属性的摘要值。
x-Digest-Manifest ： 其中x是java.security.MessageDigest算法的标准名称，此属性的值是整个清单的摘要值。
主节后面是单个条目的列表，这些条目的名称也必须出现在清单文件中。每个单独的条目必须至少包含清单文件中对应条目的摘要。出现在清单文件但没有出现在签名文件中的路径或url不会在计算中使用。
1
签名验证
如果签名是有效的，并且在签名生成之后，JAR文件中的任何文件都没有被更改，那么就会发生成功的JAR文件验证。JAR文件验证包括以下步骤:
① 在第一次解析清单时，验证在签名文件上的签名。为了提高效率，这种验证应该被记忆。注意，此验证仅验证签名说明本身，而不是实际的归档文件。
② 如果签名文件中存在x-Digest-Manifest属性，则根据根据整个清单计算的摘要验证该值。如果签名文件中存在多个x-Digest-Manifest属性，验证其中至少有一个与计算的摘要值匹配。
③ 如果签名文件中不存在x-Digest-Manifest属性，或者在前面的步骤中计算的摘要值都不匹配，那么将执行优化较少的验证:
Ⅰ.如果签名文件中存在x-Digest-Manifest-Main-Attributes条目，则根据根据清单文件中的主要属性计算的摘要验证该值。如果计算失败，则JAR文件验证失败。这项决定可以因其效率而被记忆。如果签名文件中不存在x-Digest-Manifest-Main-Attributes条目，那么它的不存在不会影响JAR文件验证，并且清单的主属性也不会被验证。
Ⅱ.根据根据清单文件中相应条目计算的摘要值，验证签名文件中每个源文件信息部分中的摘要值。如果任何摘要值不匹配，则JAR文件验证失败。
④ 对于清单中的每个条目，根据根据在“Name:”属性中引用的实际数据计算的摘要验证清单文件中的摘要值，该属性指定一个相对文件路径或URL。如果任何摘要值不匹配，则JAR文件验证失败。
清单文件示例:
Manifest-Version: 1.0
Created-By: 1.7.0 (Sun Microsystems Inc.)
Name: common/class1.class
SHA-256-Digest: (base64 representation of SHA-256 digest)
Name: common/class2.class
SHA1-Digest: (base64 representation of SHA1 digest)
SHA-256-Digest: (base64 representation of SHA-256 digest)
相应的签名文件示例：
Signature-Version: 1.0
SHA-256-Digest-Manifest: (base64 representation of SHA-256 digest)
SHA-256-Digest-Manifest-Main-Attributes: (base64 representation of SHA-256 digest)
Name: common/class1.class
SHA-256-Digest: (base64 representation of SHA-256 digest)
Name: common/class2.class
SHA-256-Digest: (base64 representation of SHA-256 digest)2
Magic属性
验证给定清单条目上签名的另一个要求是验证者理解该条目的清单条目中Magic键对值的值。Magic属性是可选的，但如果解析器正在验证条目的签名，则必须理解该条目的Magic key的值。
Magic属性的值是一组逗号分隔的特定于上下文的字符串。逗号之前和之后的空格将被忽略。大小写被忽略，magic属性的确切含义是依赖于具体的应用程序。这些值指示如何计算清单条目中包含的散列值，因此对于签名的正确验证至关重要。关键字可以用于动态或嵌入式内容，可以用于多语言文档的多个散列，等等。
下面是清单文件中使用Magic属性的两个例子:
Name: http://www.example-scripts.com/index#script1
SHA-256-Digest: (base64 representation of SHA-256 hash)
Magic: JavaScript, Dynamic
Name: http://www.example-tourist.com/guide.html
SHA-256-Digest: (base64 representation of SHA-256 hash)
SHA-256-Digest-French: (base64 representation of SHA-256 hash)
SHA-256-Digest-German: (base64 representation of SHA-256 hash)
Magic: Multilingual
在第一个示例中，这些Magic的值可能表明http查询的结果是嵌入到文档的脚本中(而不是文档本身)，而且脚本是动态生成的。这两个信息说明了如何计算哈希值来比较清单的摘要值，从而比较有效签名。
在第二个示例中，这个值表示检索到的文档可能是针对特定语言进行内容协商的，而要验证的摘要取决于所检索到的文档是用哪种语言编写的。
3
数字签名
数字签名是. sf签名文件的已签名版本。这些是二进制文件，人类无法解释。
数字签名文件的文件名与.sf文件相同，但扩展名不同。扩展取决于数字签名的类型。例如：
.RSA (PKCS7 signature, SHA-256 + RSA)
.DSA (PKCS7 signature, DSA)
包括上面没有列出的签名算法的数字签名文件必须在META-INF目录和前缀“SIG-”。相应的签名文件(.sf文件)也必须具有相同的前缀。
对于那些不支持外部签名数据的格式，该文件应由. sf文件的签名副本组成。因此，有些数据可能是重复的，验证者应该比较两个文件。
支持外部数据的格式要么引用. sf文件，要么使用隐式引用对其执行计算。
每个. sf文件可以有多个数字签名，但是这些签名应该由同一法律实体生成。
文件扩展名可以是1到3个字母数字字符。未识别的扩展将被忽略。
Manifest和签名文件的说明
下面是应用于清单和签名文件的附加限制和规则列表。
① 解析前：如果文件的最后一个字符是EOF字符(代码26)，则EOF被视为空格。附加了两个新行(一个用于编辑器，编辑器不会在最后一行的末尾放一个新行，另一个用于语法不必对最后一个条目进行特殊处理，因为它后面可能没有空行)。
② 属性：在所有情况下，对于所有部分，不理解的属性将被忽略；属性名称不区分大小写，然而，生成清单和签名文件的程序应该使用本规范中所示的情况；属性名不能在节中重复。
③ 版本：Manifest-Version和Signature-Version必须是第一个，除此之外，主节中属性的顺序并不重要。
④ 顺序：单个清单条目的顺序不重要；单个签名条目的顺序并不重要，除非被签名的摘要按此顺序。
⑤ 行长度：以utf8编码的形式，行长度不能超过72字节(不是字符)。如果一个值使初始行比这个长，那么它应该在额外的行上继续(每个行以一个空格开始)。
⑥ 错误：如果不能根据此规范解析文件，则应该输出一个警告，并且所有签名都不可信。
⑦ 限制：因为头名称不能换行，头名称的最大长度是70字节(名称后面必须有冒号和空格)；NUL、CR和LF不能嵌入header值中，NUL、CR、LF和":"不能嵌入header名称中；实现应该支持65535字节(不是字符)的头值，以及每个文件65535个头，它们可能会耗尽内存，但不应该在这些值以下硬编码限制。
⑧ 签名者：不同的实体可以使用不同的签名算法来共享单个签名文件，这在技术上是可能的。但是这违反了标准，额外的签名可能会被忽略。
⑨ 算法：本标准不强制或限制摘要或签名算法；必须支持至少一种摘要算法；如果摘要算法、签名算法或密钥大小受到jdk.jar.disabledAlgorithms安全属性的限制，JAR将被视为未签名的。注意，jdk.jar.disabledAlgorithms安全属性被JDK引用实现，它不能保证被其他实现检查和使用。
JAR索引
概述
从1.3开始，引入JarIndex来优化网络应用程序，特别是applet的类加载器的类搜索过程。最初，applet类加载器使用一个简单的线性搜索算法来搜索其内部搜索路径上的每个元素，内部搜索路径是由“ARCHIVE”标签或“class - path”主属性构造的。类加载器加载并在其搜索路径中打开每个元素，直到找到类或资源为止。如果类加载器试图找到一个不存在的资源，那么必须下载应用程序或applet中的所有jar文件。对于大型网络应用程序和applet，这可能导致启动缓慢、响应迟缓和浪费网络带宽。JarIndex机制收集applet中定义的所有jar文件的内容，并将信息存储在索引文件中，该索引文件位于applet类路径的第一个jar文件中。加载第一个jar文件后，applet类加载器将使用收集到的内容信息来高效地加载jar文件。
现有的jar工具被增强，使其能够检查jar文件列表并生成关于哪些类和资源驻留在哪些jar文件中的目录信息。这个目录信息存储在根jar文件的META-INF目录中的一个名为INDEX.LIST的简单文本文件中。当类加载器加载根jar文件时，它读取INDEX.LIST文件，并使用它构造哈希表，哈希表是从文件和包名称到jar文件名列表的映射。为了找到类或资源，类装入器查询散列表以查找适当的jar文件，然后在必要时加载它。
索引文件规范
INDEX.LIST文件包含一个或多个节，每节由一个空行分隔。每节定义一个特定jar文件的内容，头文件定义jar文件路径名，后面是一个包或文件名列表，每行一个。所有jar文件路径都相对于根jar文件的代码基。这些路径名的解析方式与当前扩展机制对绑定扩展的解析方式相同。
UTF-8编码用于支持索引文件中的文件或包名称中的非ASCII字符。
具体规范如下：
index file : version-info blankline p*
version-info : JarIndex-Version: version-number
version-number : digit+{.digit+}*
p : body blankline
body : header name*
header : char+.jar newline
name : char+ newline
char : any valid Unicode character except NULL, CR andLF
blankline: newline newline
newline : CR LF | LF | CR (not followed by LF)
digit: {0-9}
INDEX.LIST文件是运行jar -i生成的。有关更多细节，请参阅jar手册。
向后兼容
新的类加载方案完全向后兼容在当前扩展机制之上开发的应用程序。当类加载器加载第一个jar文件，并在META-INF目录中找到INDEX.LIST文件，它将构造索引哈希表并为扩展使用新的加载方案，否则，类加载器将只使用原始的线性搜索算法。
服务提供者
概述
在META-INF/services目录中的文件是服务提供者配置文件。服务是一组众所周知的接口和(通常是抽象的)类。服务提供者是服务的特定实现。提供程序中的类通常实现在服务本身中定义的接口和类的子类。服务提供者可以以扩展的形式安装在Java平台的实现中，也就是说，将jar文件放在任何通常的扩展目录中。提供程序还可以通过将它们添加到applet或应用程序类路径，或者通过其他特定于平台的方法来提供。
服务由抽象类表示。给定服务的提供程序包含一个或多个具体类，这些类使用数据和具体的代码逻辑扩展此服务类。这个provider类通常不是整个provider本身，而是一个代理，它包含足够的信息来决定provider是否能够满足特定的请求，以及可以根据需要创建实际provider的代码。提供者类的细节往往是高度订制服务的;没有一个类或接口可以统一它们，因此没有定义这样的类。这里强制执行的唯一要求是，提供程序类必须有一个零参数的构造函数，以便在查找期间可以实例化它们。
提供者配置文件
服务提供者通过在资源目录META-INF/services中放置一个提供者配置文件来标识自己。文件的名称应该由抽象服务类的完全限定名组成。该文件应该包含一个以换行符分隔的惟一具体提供程序类名称列表。空格和制表符以及空白行都将被忽略。注释字符是'#' (0x23);在每行中，第一个注释字符之后的所有字符都将被忽略。该文件必须用UTF-8编码。
例子
假设我们有一个名为java.io. si . charcodec的服务类。它有两种抽象的方法:
public abstract CharEncoder getEncoder(String encodingName);
public abstract CharDecoder getDecoder(String encodingName);
每个方法都返回一个适当的对象，如果它不能转换给定的编码，则返回null。典型的CharCodec提供程序将支持多种编码。如果sun.io.StandardCodec是CharCodec服务的提供者，那么它的jar文件将包含文件META-INF/services/java.io.spi.CharCodec。该文件将包含一行:
sun.io.StandardCodec # Standard codecs for the platform
为一个给定的编码名称定位编码器，内部的I/O代码会做这样的事情:
CharEncoder getEncoder(String encodingName) {
Iterator ps = Service.providers(CharCodec.class);
while (ps.hasNext()) {
CharCodec cc = (CharCodec)ps.next();
CharEncoder ce = cc.getEncoder(encodingName);
if (ce != null)
return ce;
}
return null;
}
提供程序查找机制总是在调用者的安全上下文中执行。受信任的系统代码通常应该从权限安全上下文中调用该类中的方法。
Class-Path属性
应用程序的清单可以指定一个或多个相对url，引用它需要的其他库的JAR文件和目录。这些相对url被当作相对于加载应用程序的代码基进行处理。
应用程序(或者更常见的是JAR文件)通过manifest属性Class-Path指定它需要的库的相对url。如果在宿主Java虚拟机上找不到其他库的实现，系统将根据此属性搜索它们的url。这些相对url可能包括应用程序所需的任何库或资源的JAR文件和目录。不以斜杠(/)结尾的相对url被认为引用JAR文件。例如：
Class-Path: servlet.jar infobus.jar acme/beans.jar images/
在JAR文件的清单中最多只能指定一个类路径头。目前，出于安全考虑，url必须相对于JAR文件的代码库。因此，远程可选包将源自与应用程序相同的代码库。
每个相对URL都根据加载包含应用程序或库的代码库解析。如果结果URL无效或引用了无法找到的资源，则将忽略它。
生成的URL用于扩展应用程序、applet或servlet的类路径，方法是在类路径中紧跟着包含JAR文件的URL插入URL。省略任何重复的url。例如，给定以下类路径:
a.jar b.jar
假设b.jar包含以下类路径清单属性:
Class-Path: x.jar a.jar
结果是应用程序类路径如下：
a.jar b.jar x.jar
如果x.jar有自己的依赖项，那么将根据后续每个URL的相同规则添加这些依赖项。在实际的实现中，JAR文件依赖项被延迟处理，因此JAR文件直到需要时才打开。
包封装
JAR文件和包可以选择密封，以便包可以在版本中强制一致性。封装在JAR中的包指定在该包中定义的所有类必须来自同一JAR，否则，抛出SecurityException。密封的JAR指定由该JAR定义的所有包都是密封的，除非为特定的包重写。密封的包是通过manifest属性sealed来指定的，它的值是true或者false(大小写无关)。例如：
Name: javax/servlet/internal/
Sealed: true
这指定了javax.servlet.internal包是密封的，并且包中的所有类都必须从同一个JAR文件加载。
如果缺少这个属性，那么包密封属性就是包含JAR文件的属性。
密封的JAR是通过相同的清单头密封指定的，其值同样为true或false。例如:
Sealed: true
这指定此归档中的所有包都是密封的，除非为清单项中具有sealed属性的特定包显式重写。
如果缺少这个属性，为了向后兼容，假设JAR文件不是密封的。然后，系统默认检查包头的密封信息。
包密封对于安全性也很重要，因为它将对受包保护的成员的访问限制为仅对来自同一JAR文件的包中定义的类的访问。
未命名的包是不可密封的，因此要密封的类必须放在它们自己的包中。
往期精彩回顾
Tensorflow 2.x 模型-部署与实践
实习招聘|360云平台火热招聘中
360Stack裸金属服务器部署实践
360技术公众号
技术干货|一手资讯|精彩活动
扫码关注我们